| < 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/ | ||||