draft-ietf-httpbis-semantics-18.txt   draft-ietf-httpbis-semantics-19.txt 
HTTP Working Group R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, M. Nottingham, Ed. Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, M. Nottingham, Ed.
7538, 7615, 7694 (if approved) Fastly 7538, 7615, 7694 (if approved) Fastly
Updates: 3864 (if approved) J. Reschke, Ed. Updates: 3864 (if approved) J. Reschke, Ed.
Intended status: Standards Track greenbytes Intended status: Standards Track greenbytes
Expires: 19 February 2022 18 August 2021 Expires: 14 March 2022 10 September 2021
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-18 draft-ietf-httpbis-semantics-19
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 describes the overall architecture of HTTP, systems. This document describes the overall architecture of HTTP,
establishes common terminology, and defines aspects of the protocol establishes common terminology, and defines aspects of the protocol
that are shared by all versions. In this definition are core that are shared by all versions. In this definition are core
protocol elements, extensibility mechanisms, and the "http" and protocol elements, extensibility mechanisms, and the "http" and
"https" Uniform Resource Identifier (URI) schemes. "https" Uniform Resource Identifier (URI) schemes.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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.19. The changes in this draft are summarized in Appendix C.20.
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 19 February 2022. This Internet-Draft will expire on 14 March 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 16 skipping to change at page 3, line 16
2.5. Protocol Version . . . . . . . . . . . . . . . . . . . . 15 2.5. Protocol Version . . . . . . . . . . . . . . . . . . . . 15
3. Terminology and Core Concepts . . . . . . . . . . . . . . . . 16 3. Terminology and Core Concepts . . . . . . . . . . . . . . . . 16
3.1. Resources . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Resources . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Representations . . . . . . . . . . . . . . . . . . . . . 17 3.2. Representations . . . . . . . . . . . . . . . . . . . . . 17
3.3. Connections, Clients and Servers . . . . . . . . . . . . 17 3.3. Connections, Clients and Servers . . . . . . . . . . . . 17
3.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5. User Agents . . . . . . . . . . . . . . . . . . . . . . . 18 3.5. User Agents . . . . . . . . . . . . . . . . . . . . . . . 18
3.6. Origin Server . . . . . . . . . . . . . . . . . . . . . . 19 3.6. Origin Server . . . . . . . . . . . . . . . . . . . . . . 19
3.7. Intermediaries . . . . . . . . . . . . . . . . . . . . . 20 3.7. Intermediaries . . . . . . . . . . . . . . . . . . . . . 20
3.8. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.8. Caches . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.9. Example Message Exchange . . . . . . . . . . . . . . . . 22 3.9. Example Message Exchange . . . . . . . . . . . . . . . . 23
4. Identifiers in HTTP . . . . . . . . . . . . . . . . . . . . . 23 4. Identifiers in HTTP . . . . . . . . . . . . . . . . . . . . . 23
4.1. URI References . . . . . . . . . . . . . . . . . . . . . 23 4.1. URI References . . . . . . . . . . . . . . . . . . . . . 23
4.2. HTTP-Related URI Schemes . . . . . . . . . . . . . . . . 24 4.2. HTTP-Related URI Schemes . . . . . . . . . . . . . . . . 24
4.2.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 25 4.2.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 25
4.2.2. https URI Scheme . . . . . . . . . . . . . . . . . . 25 4.2.2. https URI Scheme . . . . . . . . . . . . . . . . . . 25
4.2.3. http(s) Normalization and Comparison . . . . . . . . 26 4.2.3. http(s) Normalization and Comparison . . . . . . . . 26
4.2.4. Deprecation of userinfo in http(s) URIs . . . . . . . 27 4.2.4. Deprecation of userinfo in http(s) URIs . . . . . . . 27
4.2.5. http(s) References with Fragment Identifiers . . . . 28 4.2.5. http(s) References with Fragment Identifiers . . . . 28
4.3. Authoritative Access . . . . . . . . . . . . . . . . . . 28 4.3. Authoritative Access . . . . . . . . . . . . . . . . . . 28
4.3.1. URI Origin . . . . . . . . . . . . . . . . . . . . . 28 4.3.1. URI Origin . . . . . . . . . . . . . . . . . . . . . 28
skipping to change at page 7, line 13 skipping to change at page 7, line 13
15.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 161 15.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 161
15.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . 161 15.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . 161
15.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 162 15.4.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 162
15.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 163 15.4.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 163
15.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 163 15.4.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 163
15.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 163 15.4.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 163
15.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 163 15.4.9. 308 Permanent Redirect . . . . . . . . . . . . . . . 163
15.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 164 15.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 164
15.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 164 15.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 164
15.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 164 15.5.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 164
15.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 164 15.5.3. 402 Payment Required . . . . . . . . . . . . . . . . 165
15.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 164 15.5.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 165
15.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 165 15.5.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 165
15.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 165 15.5.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 165
15.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 165 15.5.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 166
15.5.8. 407 Proxy Authentication Required . . . . . . . . . 166 15.5.8. 407 Proxy Authentication Required . . . . . . . . . 166
15.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . 166 15.5.9. 408 Request Timeout . . . . . . . . . . . . . . . . 166
15.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 166 15.5.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 166
15.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 167 15.5.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 167
15.5.12. 411 Length Required . . . . . . . . . . . . . . . . 167 15.5.12. 411 Length Required . . . . . . . . . . . . . . . . 167
15.5.13. 412 Precondition Failed . . . . . . . . . . . . . . 167 15.5.13. 412 Precondition Failed . . . . . . . . . . . . . . 167
15.5.14. 413 Content Too Large . . . . . . . . . . . . . . . 167 15.5.14. 413 Content Too Large . . . . . . . . . . . . . . . 168
15.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 168 15.5.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . 168
15.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 168 15.5.16. 415 Unsupported Media Type . . . . . . . . . . . . . 168
15.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . 168 15.5.17. 416 Range Not Satisfiable . . . . . . . . . . . . . 169
15.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 169 15.5.18. 417 Expectation Failed . . . . . . . . . . . . . . . 169
15.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 169 15.5.19. 418 (Unused) . . . . . . . . . . . . . . . . . . . . 169
15.5.20. 421 Misdirected Request . . . . . . . . . . . . . . 170 15.5.20. 421 Misdirected Request . . . . . . . . . . . . . . 170
15.5.21. 422 Unprocessable Content . . . . . . . . . . . . . 170 15.5.21. 422 Unprocessable Content . . . . . . . . . . . . . 170
15.5.22. 426 Upgrade Required . . . . . . . . . . . . . . . . 170 15.5.22. 426 Upgrade Required . . . . . . . . . . . . . . . . 170
15.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 171 15.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 171
15.6.1. 500 Internal Server Error . . . . . . . . . . . . . 171 15.6.1. 500 Internal Server Error . . . . . . . . . . . . . 171
15.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . 171 15.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . 171
15.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 171 15.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 171
15.6.4. 503 Service Unavailable . . . . . . . . . . . . . . 171 15.6.4. 503 Service Unavailable . . . . . . . . . . . . . . 172
15.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 172 15.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 172
15.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 172 15.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 172
16. Extending HTTP . . . . . . . . . . . . . . . . . . . . . . . 172 16. Extending HTTP . . . . . . . . . . . . . . . . . . . . . . . 172
16.1. Method Extensibility . . . . . . . . . . . . . . . . . . 173 16.1. Method Extensibility . . . . . . . . . . . . . . . . . . 173
16.1.1. Method Registry . . . . . . . . . . . . . . . . . . 173 16.1.1. Method Registry . . . . . . . . . . . . . . . . . . 173
16.1.2. Considerations for New Methods . . . . . . . . . . . 173 16.1.2. Considerations for New Methods . . . . . . . . . . . 173
16.2. Status Code Extensibility . . . . . . . . . . . . . . . 174 16.2. Status Code Extensibility . . . . . . . . . . . . . . . 174
16.2.1. Status Code Registry . . . . . . . . . . . . . . . . 174 16.2.1. Status Code Registry . . . . . . . . . . . . . . . . 174
16.2.2. Considerations for New Status Codes . . . . . . . . 174 16.2.2. Considerations for New Status Codes . . . . . . . . 175
16.3. Field Extensibility . . . . . . . . . . . . . . . . . . 175 16.3. Field Extensibility . . . . . . . . . . . . . . . . . . 176
16.3.1. Field Name Registry . . . . . . . . . . . . . . . . 176 16.3.1. Field Name Registry . . . . . . . . . . . . . . . . 176
16.3.2. Considerations for New Fields . . . . . . . . . . . 177 16.3.2. Considerations for New Fields . . . . . . . . . . . 177
16.3.2.1. Considerations for New Field Names . . . . . . . 178 16.3.2.1. Considerations for New Field Names . . . . . . . 178
16.3.2.2. Considerations for New Field Values . . . . . . 179 16.3.2.2. Considerations for New Field Values . . . . . . 179
16.4. Authentication Scheme Extensibility . . . . . . . . . . 180 16.4. Authentication Scheme Extensibility . . . . . . . . . . 180
16.4.1. Authentication Scheme Registry . . . . . . . . . . . 180 16.4.1. Authentication Scheme Registry . . . . . . . . . . . 180
16.4.2. Considerations for New Authentication Schemes . . . 180 16.4.2. Considerations for New Authentication Schemes . . . 180
16.5. Range Unit Extensibility . . . . . . . . . . . . . . . . 181 16.5. Range Unit Extensibility . . . . . . . . . . . . . . . . 182
16.5.1. Range Unit Registry . . . . . . . . . . . . . . . . 182 16.5.1. Range Unit Registry . . . . . . . . . . . . . . . . 182
16.5.2. Considerations for New Range Units . . . . . . . . . 182 16.5.2. Considerations for New Range Units . . . . . . . . . 182
16.6. Content Coding Extensibility . . . . . . . . . . . . . . 182 16.6. Content Coding Extensibility . . . . . . . . . . . . . . 182
16.6.1. Content Coding Registry . . . . . . . . . . . . . . 182 16.6.1. Content Coding Registry . . . . . . . . . . . . . . 182
16.6.2. Considerations for New Content Codings . . . . . . . 183 16.6.2. Considerations for New Content Codings . . . . . . . 183
16.7. Upgrade Token Registry . . . . . . . . . . . . . . . . . 183 16.7. Upgrade Token Registry . . . . . . . . . . . . . . . . . 183
17. Security Considerations . . . . . . . . . . . . . . . . . . . 184 17. Security Considerations . . . . . . . . . . . . . . . . . . . 184
17.1. Establishing Authority . . . . . . . . . . . . . . . . . 184 17.1. Establishing Authority . . . . . . . . . . . . . . . . . 184
17.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 185 17.2. Risks of Intermediaries . . . . . . . . . . . . . . . . 185
17.3. Attacks Based on File and Path Names . . . . . . . . . . 186 17.3. Attacks Based on File and Path Names . . . . . . . . . . 186
17.4. Attacks Based on Command, Code, or Query Injection . . . 186 17.4. Attacks Based on Command, Code, or Query Injection . . . 186
17.5. Attacks via Protocol Element Length . . . . . . . . . . 187 17.5. Attacks via Protocol Element Length . . . . . . . . . . 187
17.6. Attacks using Shared-dictionary Compression . . . . . . 187 17.6. Attacks using Shared-dictionary Compression . . . . . . 188
17.7. Disclosure of Personal Information . . . . . . . . . . . 188 17.7. Disclosure of Personal Information . . . . . . . . . . . 188
17.8. Privacy of Server Log Information . . . . . . . . . . . 188 17.8. Privacy of Server Log Information . . . . . . . . . . . 188
17.9. Disclosure of Sensitive Information in URIs . . . . . . 189 17.9. Disclosure of Sensitive Information in URIs . . . . . . 189
17.10. Application Handling of Field Names . . . . . . . . . . 189 17.10. Application Handling of Field Names . . . . . . . . . . 189
17.11. Disclosure of Fragment after Redirects . . . . . . . . . 190 17.11. Disclosure of Fragment after Redirects . . . . . . . . . 190
17.12. Disclosure of Product Information . . . . . . . . . . . 191 17.12. Disclosure of Product Information . . . . . . . . . . . 191
17.13. Browser Fingerprinting . . . . . . . . . . . . . . . . . 191 17.13. Browser Fingerprinting . . . . . . . . . . . . . . . . . 191
17.14. Validator Retention . . . . . . . . . . . . . . . . . . 192 17.14. Validator Retention . . . . . . . . . . . . . . . . . . 192
17.15. Denial-of-Service Attacks Using Range . . . . . . . . . 192 17.15. Denial-of-Service Attacks Using Range . . . . . . . . . 192
17.16. Authentication Considerations . . . . . . . . . . . . . 193 17.16. Authentication Considerations . . . . . . . . . . . . . 193
skipping to change at page 9, line 32 skipping to change at page 9, line 32
C.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 228 C.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 228
C.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 229 C.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 229
C.12. Since draft-ietf-httpbis-semantics-10 . . . . . . . . . . 229 C.12. Since draft-ietf-httpbis-semantics-10 . . . . . . . . . . 229
C.13. Since draft-ietf-httpbis-semantics-11 . . . . . . . . . . 231 C.13. Since draft-ietf-httpbis-semantics-11 . . . . . . . . . . 231
C.14. Since draft-ietf-httpbis-semantics-12 . . . . . . . . . . 231 C.14. Since draft-ietf-httpbis-semantics-12 . . . . . . . . . . 231
C.15. Since draft-ietf-httpbis-semantics-13 . . . . . . . . . . 233 C.15. Since draft-ietf-httpbis-semantics-13 . . . . . . . . . . 233
C.16. Since draft-ietf-httpbis-semantics-14 . . . . . . . . . . 234 C.16. Since draft-ietf-httpbis-semantics-14 . . . . . . . . . . 234
C.17. Since draft-ietf-httpbis-semantics-15 . . . . . . . . . . 236 C.17. Since draft-ietf-httpbis-semantics-15 . . . . . . . . . . 236
C.18. Since draft-ietf-httpbis-semantics-16 . . . . . . . . . . 237 C.18. Since draft-ietf-httpbis-semantics-16 . . . . . . . . . . 237
C.19. Since draft-ietf-httpbis-semantics-17 . . . . . . . . . . 237 C.19. Since draft-ietf-httpbis-semantics-17 . . . . . . . . . . 237
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 239 C.20. Since draft-ietf-httpbis-semantics-18 . . . . . . . . . . 239
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 240
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 251 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 252
1. Introduction 1. Introduction
1.1. Purpose 1.1. Purpose
The Hypertext Transfer Protocol (HTTP) is a family of stateless, The Hypertext Transfer Protocol (HTTP) is a family of stateless,
application-level, request/response protocols that share a generic application-level, request/response protocols that share a generic
interface, extensible semantics, and self-descriptive messages to interface, extensible semantics, and self-descriptive messages to
enable flexible interaction with network-based hypertext information enable flexible interaction with network-based hypertext information
systems. systems.
skipping to change at page 21, line 5 skipping to change at page 21, line 5
_outbound_ means toward the user agent. _outbound_ means toward the user agent.
A _proxy_ is a message-forwarding agent that is chosen by the client, A _proxy_ is a message-forwarding agent that is chosen by the client,
usually via local configuration rules, to receive requests for some usually via local configuration rules, to receive requests for some
type(s) of absolute URI and attempt to satisfy those requests via type(s) of absolute URI and attempt to satisfy those requests via
translation through the HTTP interface. Some translations are translation through the HTTP interface. Some translations are
minimal, such as for proxy requests for "http" URIs, whereas other minimal, such as for proxy requests for "http" URIs, whereas other
requests might require translation to and from entirely different requests might require translation to and from entirely different
application-level protocols. Proxies are often used to group an application-level protocols. Proxies are often used to group an
organization's HTTP requests through a common intermediary for the organization's HTTP requests through a common intermediary for the
sake of security, annotation services, or shared caching. Some sake of security services, annotation services, or shared caching.
proxies are designed to apply transformations to selected messages or Some proxies are designed to apply transformations to selected
content while they are being forwarded, as described in Section 7.7. messages or content while they are being forwarded, as described in
Section 7.7.
A _gateway_ (a.k.a. _reverse proxy_) is an intermediary that acts as A _gateway_ (a.k.a. _reverse proxy_) is an intermediary that acts as
an origin server for the outbound connection but translates received an origin server for the outbound connection but translates received
requests and forwards them inbound to another server or servers. requests and forwards them inbound to another server or servers.
Gateways are often used to encapsulate legacy or untrusted Gateways are often used to encapsulate legacy or untrusted
information services, to improve server performance through information services, to improve server performance through
_accelerator_ caching, and to enable partitioning or load balancing _accelerator_ caching, and to enable partitioning or load balancing
of HTTP services across multiple machines. of HTTP services across multiple machines.
All HTTP requirements applicable to an origin server also apply to All HTTP requirements applicable to an origin server also apply to
skipping to change at page 116, line 25 skipping to change at page 116, line 25
when the origin server is unable to determine a user agent's when the origin server is unable to determine a user agent's
capabilities from examining the request, and generally when public capabilities from examining the request, and generally when public
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.
12.3. Request Content Negotiation 12.3. Request Content Negotiation
When content negotiation preferences are sent in a server's response, When content negotiation preferences are sent in a server's response,
the listed preferences are called _request content negotiation_ the listed preferences are called _request content negotiation_
because they intend to influence selection of an appropriate content because they intend to influence selection of an appropriate content
for subsequent requests to that resource. For example, the Accept for subsequent requests to that resource. For example, the Accept
(Section 12.5.1) and Accept-Encoding (Section 12.5.3) header fields (Section 12.5.1) and Accept-Encoding (Section 12.5.3) header fields
can be sent in a response to indicate preferred media types and can be sent in a response to indicate preferred media types and
content codings for subsequent requests to that resource. content codings for subsequent requests to that resource.
skipping to change at page 118, line 45 skipping to change at page 118, line 45
Previous specifications allowed additional extension parameters to Previous specifications allowed additional extension parameters to
appear after the weight parameter. The accept extension grammar appear after the weight parameter. The accept extension grammar
(accept-params, accept-ext) has been removed because it had a (accept-params, accept-ext) has been removed because it had a
complicated definition, was not being used in practice, and is more complicated definition, was not being used in practice, and is more
easily deployed through new header fields. Senders using weights easily deployed through new header fields. Senders using weights
SHOULD send "q" last (after all media-range parameters). Recipients SHOULD send "q" last (after all media-range parameters). Recipients
SHOULD process any parameter named "q" as weight, regardless of SHOULD process any parameter named "q" as weight, regardless of
parameter ordering. parameter ordering.
| *Note:* Use of the "q" parameter name to control content | *Note:* Use of the "q" parameter name to control content
| negotiation is due to historical practice. Although this | negotiation would interfere with any media type parameter
| prevents any media type parameter named "q" from being used | having the same name. Hence, the media type registry disallows
| with a media range, such an event is believed to be unlikely | parameters named "q".
| given the lack of any "q" parameters in the IANA media type
| registry and the rare usage of any media type parameters in
| Accept. Future media types are discouraged from registering
| any parameter named "q".
The example The example
Accept: audio/*; q=0.2, audio/basic Accept: audio/*; q=0.2, audio/basic
is interpreted as "I prefer audio/basic, but send me any audio type is interpreted as "I prefer audio/basic, but send me any audio type
if it is the best available after an 80% markdown in quality". if it is the best available after an 80% markdown in quality".
A more elaborate example is A more elaborate example is
Accept: text/plain; q=0.5, text/html, Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c text/x-dvi; q=0.8, text/x-c
Verbally, this would be interpreted as "text/html and text/x-c are Verbally, this would be interpreted as "text/html and text/x-c are
the equally preferred media types, but if they do not exist, then the equally preferred media types, but if they do not exist, then
skipping to change at page 160, line 42 skipping to change at page 160, line 42
| being dropped from this specification. It is possible to | being dropped from this specification. It is possible to
| communicate the list as a Link header field value [RFC8288] | communicate the list as a Link header field value [RFC8288]
| whose members have a relationship of "alternate", though | whose members have a relationship of "alternate", though
| deployment is a chicken-and-egg problem. | deployment is a chicken-and-egg problem.
15.4.2. 301 Moved Permanently 15.4.2. 301 Moved Permanently
The _301 (Moved Permanently)_ status code indicates that the target The _301 (Moved Permanently)_ status code indicates that the target
resource has been assigned a new permanent URI and any future resource has been assigned a new permanent URI and any future
references to this resource ought to use one of the enclosed URIs. references to this resource ought to use one of the enclosed URIs.
Clients with link-editing capabilities ought to automatically re-link The server is suggesting that a user agent with link-editing
references to the target URI to one or more of the new references capability can permanently replace references to the target URI with
sent by the server, where possible. one of the new references sent by the server. However, this
suggestion is usually ignored unless the user agent is actively
editing references (e.g., engaged in authoring content), the
connection is secured, and the origin server is a trusted authority
for the content being edited.
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
containing a preferred URI reference for the new permanent URI. The containing a preferred URI reference for the new permanent URI. The
user agent MAY use the Location field value for automatic user agent MAY use the Location field value for automatic
redirection. The server's response content usually contains a short redirection. The server's response content usually contains a short
hypertext note with a hyperlink to the new URI(s). hypertext note with a hyperlink to the new URI(s).
| *Note:* For historical reasons, a user agent MAY change the | *Note:* For historical reasons, a user agent MAY change the
| request method from POST to GET for the subsequent request. If | request method from POST to GET for the subsequent request. If
| this behavior is undesired, the 308 (Permanent Redirect) status | this behavior is undesired, the 308 (Permanent Redirect) status
skipping to change at page 163, line 36 skipping to change at page 163, line 45
containing a URI reference for the different URI. The user agent MAY containing a URI reference for the different URI. The user agent MAY
use the Location field value for automatic redirection. The server's use the Location field value for automatic redirection. The server's
response content usually contains a short hypertext note with a response content usually contains a short hypertext note with a
hyperlink to the different URI(s). hyperlink to the different URI(s).
15.4.9. 308 Permanent Redirect 15.4.9. 308 Permanent Redirect
The _308 (Permanent Redirect)_ status code indicates that the target The _308 (Permanent Redirect)_ status code indicates that the target
resource has been assigned a new permanent URI and any future resource has been assigned a new permanent URI and any future
references to this resource ought to use one of the enclosed URIs. references to this resource ought to use one of the enclosed URIs.
Clients with link editing capabilities ought to automatically re-link The server is suggesting that a user agent with link-editing
references to the target URI to one or more of the new references capability can permanently replace references to the target URI with
sent by the server, where possible. one of the new references sent by the server. However, this
suggestion is usually ignored unless the user agent is actively
editing references (e.g., engaged in authoring content), the
connection is secured, and the origin server is a trusted authority
for the content being edited.
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
containing a preferred URI reference for the new permanent URI. The containing a preferred URI reference for the new permanent URI. The
user agent MAY use the Location field value for automatic user agent MAY use the Location field value for automatic
redirection. The server's response content usually contains a short redirection. The server's response content usually contains a short
hypertext note with a hyperlink to the new URI(s). hypertext note with a hyperlink to the new URI(s).
A 308 response is heuristically cacheable; i.e., unless otherwise A 308 response is heuristically cacheable; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [CACHING]). Section 4.2.2 of [CACHING]).
skipping to change at page 184, line 18 skipping to change at page 184, line 26
and users of known security concerns relevant to HTTP semantics and and users of known security concerns relevant to HTTP semantics and
its use for transferring information over the Internet. its use for transferring information over the Internet.
Considerations related to caching are discussed in Section 7 of Considerations related to caching are discussed in Section 7 of
[CACHING] and considerations related to HTTP/1.1 message syntax and [CACHING] and considerations related to HTTP/1.1 message syntax and
parsing are discussed in Section 11 of [HTTP/1.1]. parsing are discussed in Section 11 of [HTTP/1.1].
The list of considerations below is not exhaustive. Most security The list of considerations below is not exhaustive. Most security
concerns related to HTTP semantics are about securing server-side concerns related to HTTP semantics are about securing server-side
applications (code behind the HTTP interface), securing user agent applications (code behind the HTTP interface), securing user agent
processing of content received via HTTP, or secure use of the processing of content received via HTTP, or secure use of the
Internet in general, rather than security of the protocol. Various Internet in general, rather than security of the protocol. The
security considerations for URIs, which are fundamental to HTTP
operation, are discussed in Section 7 of [URI]. Various
organizations maintain topical information and links to current organizations maintain topical information and links to current
research on Web application security (e.g., [OWASP]). research on Web application security (e.g., [OWASP]).
17.1. Establishing Authority 17.1. Establishing Authority
HTTP relies on the notion of an _authoritative response_: a response HTTP relies on the notion of an _authoritative response_: a response
that has been determined by (or at the direction of) the origin that has been determined by (or at the direction of) the origin
server identified within the target URI to be the most appropriate server identified within the target URI to be the most appropriate
response for that request given the state of the target resource at response for that request given the state of the target resource at
the time of response message origination. the time of response message origination.
skipping to change at page 198, line 10 skipping to change at page 198, line 10
| 504 | Gateway Timeout | 15.6.5 | | 504 | Gateway Timeout | 15.6.5 |
+-------+-------------------------------+---------+ +-------+-------------------------------+---------+
| 505 | HTTP Version Not Supported | 15.6.6 | | 505 | HTTP Version Not Supported | 15.6.6 |
+-------+-------------------------------+---------+ +-------+-------------------------------+---------+
Table 8 Table 8
18.4. Field Name Registration 18.4. Field Name Registration
This specification updates the HTTP related aspects of the existing This specification updates the HTTP related aspects of the existing
registration procedures for message header fields defined in registration procedures for message header fields defined in
[RFC3864]. It defines both a new registration procedure and moves [RFC3864]. It replaces the old procedures as they relate to HTTP, by
HTTP field definitions into a separate registry. defining a new registration procedure and moving HTTP field
definitions into a separate registry.
Please create a new registry as outlined in Section 16.3.1. Please create a new registry as outlined in Section 16.3.1.
After creating the registry, all entries in the Permanent and After creating the registry, all entries in the Permanent and
Provisional Message Header Registries with the protocol 'http' are to Provisional Message Header Registries with the protocol 'http' are to
be moved to it, with the following changes applied: be moved to it, with the following changes applied:
1. The 'Applicable Protocol' field is to be omitted. 1. The 'Applicable Protocol' field is to be omitted.
2. Entries with a status of 'standard', 'experimental', 'reserved', 2. Entries with a status of 'standard', 'experimental', 'reserved',
skipping to change at page 202, line 12 skipping to change at page 202, line 12
Table 11 Table 11
18.8. Media Type Registration 18.8. Media Type Registration
Please update the "Media Types" registry at Please update the "Media Types" registry at
<https://www.iana.org/assignments/media-types> with the registration <https://www.iana.org/assignments/media-types> with the registration
information in Section 14.6 for the media type "multipart/ information in Section 14.6 for the media type "multipart/
byteranges". byteranges".
Furthermore please update the registry note about "q" parameters with
a link to Section 12.5.1 of this document.
18.9. Port Registration 18.9. Port Registration
Please update the "Service Name and Transport Protocol Port Number" Please update the "Service Name and Transport Protocol Port Number"
registry at <https://www.iana.org/assignments/service-names-port- registry at <https://www.iana.org/assignments/service-names-port-
numbers/> for the services on ports 80 and 443 that use UDP or TCP numbers/> for the services on ports 80 and 443 that use UDP or TCP
to: to:
1. use this document as "Reference", and 1. use this document as "Reference", and
2. when currently unspecified, set "Assignee" to "IESG" and 2. when currently unspecified, set "Assignee" to "IESG" and
skipping to change at page 202, line 46 skipping to change at page 202, line 49
+------+-------------------+-------------------------+------+ +------+-------------------+-------------------------+------+
Table 12 Table 12
19. References 19. References
19.1. Normative References 19.1. Normative References
[CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", Work in Progress, Internet-Draft, Ed., "HTTP Caching", Work in Progress, Internet-Draft,
draft-ietf-httpbis-cache-18, 18 August 2021, draft-ietf-httpbis-cache-19, 10 September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
cache-18>. cache-19>.
[RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data [RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, Format Specification version 3.3", RFC 1950,
DOI 10.17487/RFC1950, May 1996, DOI 10.17487/RFC1950, May 1996,
<https://www.rfc-editor.org/info/rfc1950>. <https://www.rfc-editor.org/info/rfc1950>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
<https://www.rfc-editor.org/info/rfc1951>. <https://www.rfc-editor.org/info/rfc1951>.
skipping to change at page 206, line 16 skipping to change at page 206, line 16
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
<https://www.rfc-editor.org/info/rfc7541>. <https://www.rfc-editor.org/info/rfc7541>.
[HTTP/1.0] Berners-Lee, T., Fielding, R.T., and H.F. Nielsen, [HTTP/1.0] Berners-Lee, T., Fielding, R.T., and H.F. Nielsen,
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
DOI 10.17487/RFC1945, May 1996, DOI 10.17487/RFC1945, May 1996,
<https://www.rfc-editor.org/info/rfc1945>. <https://www.rfc-editor.org/info/rfc1945>.
[HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft- Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft-
ietf-httpbis-messaging-18, 18 August 2021, ietf-httpbis-messaging-19, 10 September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
messaging-18>. messaging-19>.
[HTTP/2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP/2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[HTTP/3] Bishop, M., "Hypertext Transfer Protocol Version 3 [HTTP/3] Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-34, 2 February 2021, quic-http-34, 2 February 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
skipping to change at page 211, line 8 skipping to change at page 211, line 8
<https://mimesniff.spec.whatwg.org>. <https://mimesniff.spec.whatwg.org>.
[WEBDAV] Dusseault, L.M., Ed., "HTTP Extensions for Web Distributed [WEBDAV] Dusseault, L.M., Ed., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, Authoring and Versioning (WebDAV)", RFC 4918,
DOI 10.17487/RFC4918, June 2007, DOI 10.17487/RFC4918, June 2007,
<https://www.rfc-editor.org/info/rfc4918>. <https://www.rfc-editor.org/info/rfc4918>.
Appendix A. Collected ABNF Appendix A. Collected ABNF
In the collected ABNF below, list rules are expanded as per In the collected ABNF below, list rules are expanded as per
Section 5.6.1.1. Section 5.6.1.
Accept = [ ( media-range [ weight ] ) *( OWS "," OWS ( media-range [ Accept = [ ( media-range [ weight ] ) *( OWS "," OWS ( media-range [
weight ] ) ) ] weight ] ) ) ]
Accept-Charset = [ ( ( token / "*" ) [ weight ] ) *( OWS "," OWS ( ( Accept-Charset = [ ( ( token / "*" ) [ weight ] ) *( OWS "," OWS ( (
token / "*" ) [ weight ] ) ) ] token / "*" ) [ weight ] ) ) ]
Accept-Encoding = [ ( codings [ weight ] ) *( OWS "," OWS ( codings [ Accept-Encoding = [ ( codings [ weight ] ) *( OWS "," OWS ( codings [
weight ] ) ) ] weight ] ) ) ]
Accept-Language = [ ( language-range [ weight ] ) *( OWS "," OWS ( Accept-Language = [ ( language-range [ weight ] ) *( OWS "," OWS (
language-range [ weight ] ) ) ] language-range [ weight ] ) ) ]
Accept-Ranges = acceptable-ranges Accept-Ranges = acceptable-ranges
skipping to change at page 239, line 24 skipping to change at page 239, line 24
core/issues/953>) core/issues/953>)
* In Section 13.1, make preconditions consistent on when they are * In Section 13.1, make preconditions consistent on when they are
required to be evaluated (<https://github.com/httpwg/http-core/ required to be evaluated (<https://github.com/httpwg/http-core/
issues/954>) issues/954>)
* Throughout, disambiguate "selected representation" and "selected * Throughout, disambiguate "selected representation" and "selected
response" (now "chosen response") (<https://github.com/httpwg/ response" (now "chosen response") (<https://github.com/httpwg/
http-core/issues/958>) http-core/issues/958>)
C.20. Since draft-ietf-httpbis-semantics-18
* In Section 12.5.1, align text about "q" parameter with recent
changes to IANA media types registry, and instruct IANA to
reference this document with respect to the "q" special case
(<https://github.com/httpwg/http-core/issues/970>)
* In Section 18.4, rephrase text about the relation with [RFC3864]
(<https://github.com/httpwg/http-core/pull/973>)
* In Section 3.7, avoid bare "for the sake of security"
(<https://github.com/httpwg/http-core/pull/974>)
* In Section 12.2, wordsmith future guidance on reactive negotiation
(<https://github.com/httpwg/http-core/pull/975>)
* In Section 15.4.2 and Section 15.4.9, improve text about automatic
link-editing (<https://github.com/httpwg/http-core/pull/976>)
* In Section 17, reference [URI] security considerations
(<https://github.com/httpwg/http-core/pull/977>)
Acknowledgements Acknowledgements
Aside from the current editors, the following individuals deserve Aside from the current editors, the following individuals deserve
special recognition for their contributions to early aspects of HTTP special recognition for their contributions to early aspects of HTTP
and its core specifications: Marc Andreessen, Tim Berners-Lee, Robert and its core specifications: Marc Andreessen, Tim Berners-Lee, Robert
Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jim Gettys, Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jim Gettys,
Jean-François Groff, Phillip M. Hallam-Baker, Koen Holtman, Jeffery Jean-François Groff, Phillip M. Hallam-Baker, Koen Holtman, Jeffery
L. Hostetler, Shel Kaphan, Dave Kristol, Yves Lafon, Scott L. Hostetler, Shel Kaphan, Dave Kristol, Yves Lafon, Scott
D. Lawrence, Paul J. Leach, Håkon W. Lie, Ari Luotonen, Larry D. Lawrence, Paul J. Leach, Håkon W. Lie, Ari Luotonen, Larry
Masinter, Rob McCool, Jeffrey C. Mogul, Lou Montulli, David Morris, Masinter, Rob McCool, Jeffrey C. Mogul, Lou Montulli, David Morris,
 End of changes. 29 change blocks. 
44 lines changed or deleted 77 lines changed or added

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