| draft-ietf-httpbis-p2-semantics-23.txt |  | draft-ietf-httpbis-p2-semantics-24.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2616 (if approved) J. Reschke, Ed. |  | Obsoletes: 2616 (if approved) J. Reschke, Ed. |
| Updates: 2817 (if approved) greenbytes |  | Updates: 2817 (if approved) greenbytes |
| Intended status: Standards Track July 15, 2013 |  | Intended status: Standards Track September 25, 2013 |
| Expires: January 16, 2014 |  | Expires: March 29, 2014 |
| Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |  | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
| draft-ietf-httpbis-p2-semantics-23 |  | draft-ietf-httpbis-p2-semantics-24 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypertext information |  | protocol for distributed, collaborative, hypertext information |
| systems. This document defines the semantics of HTTP/1.1 messages, |  | systems. This document defines the semantics of HTTP/1.1 messages, |
| as expressed by request methods, request header fields, response |  | as expressed by request methods, request header fields, response |
| status codes, and response header fields, along with the payload of |  | status codes, and response header fields, along with the payload of |
| messages (metadata and body content) and mechanisms for content |  | messages (metadata and body content) and mechanisms for content |
| negotiation. |  | negotiation. |
| skipping to change at page 1, line 34 |  | skipping to change at page 1, line 34 |
| Discussion of this draft takes place on the HTTPBIS working group |  | Discussion of this draft takes place on the HTTPBIS working group |
| mailing list (ietf-http-wg@w3.org), which is archived at |  | mailing list (ietf-http-wg@w3.org), which is archived at |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
| The current issues list is at |  | The current issues list is at |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix E.3. |  | The changes in this draft are summarized in Appendix E.4. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| This Internet-Draft will expire on January 16, 2014. |  | This Internet-Draft will expire on March 29, 2014. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2013 IETF Trust and the persons identified as the |  | Copyright (c) 2013 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| skipping to change at page 2, line 41 |  | skipping to change at page 2, line 41 |
| than English. |  | than English. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 6 |  | 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 6 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |
| 2. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 2. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 3. Representations . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 3. Representations . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 3.1. Representation Metadata . . . . . . . . . . . . . . . . . 8 |  | 3.1. Representation Metadata . . . . . . . . . . . . . . . . . 8 |
| 3.1.1. Processing the Data . . . . . . . . . . . . . . . . . 8 |  | 3.1.1. Processing Representation Data . . . . . . . . . . . . 8 |
| 3.1.2. Encoding for Compression or Integrity . . . . . . . . 11 |  | 3.1.2. Encoding for Compression or Integrity . . . . . . . . 11 |
| 3.1.3. Audience Language . . . . . . . . . . . . . . . . . . 13 |  | 3.1.3. Audience Language . . . . . . . . . . . . . . . . . . 13 |
| 3.1.4. Identification . . . . . . . . . . . . . . . . . . . . 14 |  | 3.1.4. Identification . . . . . . . . . . . . . . . . . . . . 14 |
| 3.2. Representation Data . . . . . . . . . . . . . . . . . . . 17 |  | 3.2. Representation Data . . . . . . . . . . . . . . . . . . . 17 |
| 3.3. Payload Semantics . . . . . . . . . . . . . . . . . . . . 17 |  | 3.3. Payload Semantics . . . . . . . . . . . . . . . . . . . . 17 |
| 3.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 18 |  | 3.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 18 |
| 3.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 18 |  | 3.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 19 |
| 3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . . 19 |  | 3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . . 20 |
| 4. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 4. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 21 |
| 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21 |
| 4.2. Common Method Properties . . . . . . . . . . . . . . . . . 22 |  | 4.2. Common Method Properties . . . . . . . . . . . . . . . . . 22 |
| 4.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 22 |  | 4.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 22 |
| 4.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 23 |  | 4.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 23 |
| 4.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 23 |  | 4.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 24 |
| 4.3. Method Definitions . . . . . . . . . . . . . . . . . . . . 23 |  | 4.3. Method Definitions . . . . . . . . . . . . . . . . . . . . 24 |
| 4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24 |  | 4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 24 |  | 4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 4.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 4.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 4.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 26 |  | 4.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 26 |
| 4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 30 |
| 4.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 4.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 31 |
| 4.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 4.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 5. Request Header Fields . . . . . . . . . . . . . . . . . . . . 32 |  | 5. Request Header Fields . . . . . . . . . . . . . . . . . . . . 33 |
| 5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 34 |
| 5.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36 |  | 5.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36 |
| 5.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36 |  | 5.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36 |
| 5.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 37 |  | 5.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 37 |
| 5.3.1. Quality Values . . . . . . . . . . . . . . . . . . . . 37 |  | 5.3.1. Quality Values . . . . . . . . . . . . . . . . . . . . 37 |
| 5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38 |  | 5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38 |
| 5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40 |  | 5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40 |
| 5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41 |  | 5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41 |
| 5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42 |  | 5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42 |
| 5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43 |  | 5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43 |
| 5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 44 |  | 5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 44 |
| 5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44 |  | 5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44 |
| 5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 44 |  | 5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 45 |
| 5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 45 |  | 5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 46 |
| 6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47 |  | 6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47 |
| 6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 47 |  | 6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 47 |
| 6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 49 |  | 6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 50 |
| 6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 49 |  | 6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 50 |
| 6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50 |  | 6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50 |
| 6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 50 |  | 6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51 |
| 6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 50 |  | 6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51 |
| 6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 52 |
| 6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 52 |
| 6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 51 |  | 6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 52 |
| 6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 52 |  | 6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 53 |
| 6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 52 |  | 6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 53 |
| 6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 53 |  | 6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 54 |
| 6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 54 |  | 6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 55 |
| 6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 55 |  | 6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 56 |
| 6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 55 |  | 6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 56 |
| 6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 56 |  | 6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 57 |
| 6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 56 |  | 6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 57 |
| 6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 56 |  | 6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 57 |
| 6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 57 |  | 6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 58 |
| 6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 57 |  | 6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58 |
| 6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 57 |  | 6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 58 |
| 6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 57 |  | 6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 58 |
| 6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 57 |  | 6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 58 |
| 6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 58 |  | 6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 59 |
| 6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 58 |  | 6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 59 |
| 6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 58 |  | 6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 59 |
| 6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 59 |  | 6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 60 |
| 6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 59 |  | 6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 60 |
| 6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 59 |  | 6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60 |
| 6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 60 |  | 6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 61 |
| 6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 60 |  | 6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 61 |
| 6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 60 |  | 6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61 |
| 6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 60 |  | 6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 61 |
| 6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 61 |  | 6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62 |
| 6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 61 |  | 6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62 |
| 6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 61 |  | 6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62 |
| 6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 61 |  | 6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 62 |
| 6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 61 |  | 6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 62 |
| 6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 62 |  | 6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 63 |
| 6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 62 |  | 6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 63 |
| 6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 62 |  | 6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 63 |
| 6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 62 |  | 6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 63 |
| 7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 62 |  | 7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 63 |
| 7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 63 |  | 7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 64 |
| 7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 63 |  | 7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 64 |
| 7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 66 |  | 7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 68 |
| 7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 68 |  | 7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69 |
| 7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 68 |  | 7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70 |
| 7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 69 |  | 7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71 |
| 7.3. Authentication Challenges . . . . . . . . . . . . . . . . 70 |  | 7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72 |
| 7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 70 |  | 7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 72 |
| 7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 71 |  | 7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72 |
| 7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 71 |  | 7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 73 |
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 |  | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 |
| 8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 72 |  | 8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 74 |
| 8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 72 |  | 8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 74 |
| 8.1.2. Considerations for New Methods . . . . . . . . . . . . 72 |  | 8.1.2. Considerations for New Methods . . . . . . . . . . . . 74 |
| 8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 73 |  | 8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 75 |
| 8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 73 |  | 8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 75 |
| 8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 73 |  | 8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 75 |
| 8.2.2. Considerations for New Status Codes . . . . . . . . . 74 |  | 8.2.2. Considerations for New Status Codes . . . . . . . . . 76 |
| 8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 75 |  | 8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 76 |
| 8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 76 |  | 8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77 |
| 8.3.1. Considerations for New Header Fields . . . . . . . . . 77 |  | 8.3.1. Considerations for New Header Fields . . . . . . . . . 78 |
| 8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 79 |  | 8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80 |
| 8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 79 |  | 8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80 |
| 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 79 |  | 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 80 |
| 8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 80 |  | 8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81 |
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 80 |  | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 81 |
| 9.1. Attacks Based On File and Path Names . . . . . . . . . . . 80 |  | 9.1. Attacks Based On File and Path Names . . . . . . . . . . . 81 |
| 9.2. Personal Information . . . . . . . . . . . . . . . . . . . 81 |  | 9.2. Personal Information . . . . . . . . . . . . . . . . . . . 82 |
| 9.3. Sensitive Information in URIs . . . . . . . . . . . . . . 81 |  | 9.3. Sensitive Information in URIs . . . . . . . . . . . . . . 82 |
| 9.4. Product Information . . . . . . . . . . . . . . . . . . . 82 |  | 9.4. Product Information . . . . . . . . . . . . . . . . . . . 83 |
| 9.5. Fragment after Redirects . . . . . . . . . . . . . . . . . 82 |  | 9.5. Fragment after Redirects . . . . . . . . . . . . . . . . . 83 |
| 9.6. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 82 |  | 9.6. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 83 |
| 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83 |  | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 |
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 83 |  | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84 |
| 11.1. Normative References . . . . . . . . . . . . . . . . . . . 83 |  | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 84 |
| 11.2. Informative References . . . . . . . . . . . . . . . . . . 85 |  | 11.2. Informative References . . . . . . . . . . . . . . . . . . 86 |
| Appendix A. Differences between HTTP and MIME . . . . . . . . . . 87 |  | Appendix A. Differences between HTTP and MIME . . . . . . . . . . 88 |
| A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 87 |  | A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88 |
| A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 87 |  | A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 88 |
| A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 88 |  | A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 89 |
| A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 88 |  | A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 89 |
| A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 88 |  | A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 89 |
| A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 88 |  | A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 89 |
| Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 89 |  | Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 90 |
| Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 91 |  | Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 92 |
| Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 92 |  | Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 93 |
| Appendix E. Change Log (to be removed by RFC Editor before |  | Appendix E. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 95 |  | publication) . . . . . . . . . . . . . . . . . . . . 96 |
| E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 95 |  | E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 96 |
| E.2. Since draft-ietf-httpbis-p2-semantics-21 . . . . . . . . . 95 |  | E.2. Since draft-ietf-httpbis-p2-semantics-21 . . . . . . . . . 96 |
| E.3. Since draft-ietf-httpbis-p2-semantics-22 . . . . . . . . . 96 |  | E.3. Since draft-ietf-httpbis-p2-semantics-22 . . . . . . . . . 97 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 |  | E.4. Since draft-ietf-httpbis-p2-semantics-23 . . . . . . . . . 97 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 |
| 1. Introduction |  | 1. Introduction |
| Each Hypertext Transfer Protocol (HTTP) message is either a request |  | Each Hypertext Transfer Protocol (HTTP) message is either a request |
| or a response. A server listens on a connection for a request, |  | or a response. A server listens on a connection for a request, |
| parses each message received, interprets the message semantics in |  | parses each message received, interprets the message semantics in |
| relation to the identified request target, and responds to that |  | relation to the identified request target, and responds to that |
| request with one or more response messages. A client constructs |  | request with one or more response messages. A client constructs |
| request messages to communicate specific intentions, and examines |  | request messages to communicate specific intentions, and examines |
| received responses to see if the intentions were carried out and |  | received responses to see if the intentions were carried out and |
| skipping to change at page 6, line 48 |  | skipping to change at page 6, line 48 |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in [RFC2119]. |  | document are to be interpreted as described in [RFC2119]. |
| Conformance criteria and considerations regarding error handling are |  | Conformance criteria and considerations regarding error handling are |
| defined in Section 2.5 of [Part1]. |  | defined in Section 2.5 of [Part1]. |
| 1.2. Syntax Notation |  | 1.2. Syntax Notation |
| This specification uses the Augmented Backus-Naur Form (ABNF) |  | This specification uses the Augmented Backus-Naur Form (ABNF) |
| notation of [RFC5234] with the list rule extension defined in Section |  | notation of [RFC5234] with the list rule extension defined in Section |
| 1.2 of [Part1]. Appendix C describes rules imported from other |  | 7 of [Part1]. Appendix C describes rules imported from other |
| documents. Appendix D shows the collected ABNF with the list rule |  | documents. Appendix D shows the collected ABNF with the list rule |
| expanded. |  | expanded. |
| This specification uses the terms "character", "character encoding |  | This specification uses the terms "character", "character encoding |
| scheme", "charset", and "protocol element" as they are defined in |  | scheme", "charset", and "protocol element" as they are defined in |
| [RFC6365]. |  | [RFC6365]. |
| 2. Resources |  | 2. Resources |
| The target of each HTTP request is called a resource. HTTP does not |  | The target of an HTTP request is called a resource. HTTP does not |
| limit the nature of a resource; it merely defines an interface that |  | limit the nature of a resource; it merely defines an interface that |
| might be used to interact with resources. Each resource is |  | might be used to interact with resources. Each resource is |
| identified by a Uniform Resource Identifier (URI), as described in |  | identified by a Uniform Resource Identifier (URI), as described in |
| Section 2.7 of [Part1]. |  | Section 2.7 of [Part1]. |
| When a client constructs an HTTP/1.1 request message, it sends the |  | When a client constructs an HTTP/1.1 request message, it sends the |
| target URI in one of various forms, as defined in (Section 5.3 of |  | target URI in one of various forms, as defined in (Section 5.3 of |
| [Part1]). When a request is received, the server reconstructs an |  | [Part1]). When a request is received, the server reconstructs an |
| effective request URI for the target resource (Section 5.5 of |  | effective request URI for the target resource (Section 5.5 of |
| [Part1]). |  | [Part1]). |
| skipping to change at page 8, line 18 |  | skipping to change at page 8, line 18 |
| 3.1. Representation Metadata |  | 3.1. Representation Metadata |
| Representation header fields provide metadata about the |  | Representation header fields provide metadata about the |
| representation. When a message includes a payload body, the |  | representation. When a message includes a payload body, the |
| representation header fields describe how to interpret the |  | representation header fields describe how to interpret the |
| representation data enclosed in the payload body. In a response to a |  | representation data enclosed in the payload body. In a response to a |
| HEAD request, the representation header fields describe the |  | HEAD request, the representation header fields describe the |
| representation data that would have been enclosed in the payload body |  | representation data that would have been enclosed in the payload body |
| if the same request had been a GET. |  | if the same request had been a GET. |
| The following header fields are defined to convey representation |  | The following header fields convey representation metadata: |
| metadata: |  |  |
| +-------------------+-----------------+ |  | +-------------------+-----------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +-------------------+-----------------+ |  | +-------------------+-----------------+ |
| | Content-Type | Section 3.1.1.5 | |  | | Content-Type | Section 3.1.1.5 | |
| | Content-Encoding | Section 3.1.2.2 | |  | | Content-Encoding | Section 3.1.2.2 | |
| | Content-Language | Section 3.1.3.2 | |  | | Content-Language | Section 3.1.3.2 | |
| | Content-Location | Section 3.1.4.2 | |  | | Content-Location | Section 3.1.4.2 | |
| +-------------------+-----------------+ |  | +-------------------+-----------------+ |
| 3.1.1. Processing the Data |  | 3.1.1. Processing Representation Data |
| 3.1.1.1. Media Type |  | 3.1.1.1. Media Type |
| HTTP uses Internet Media Types [RFC2046] in the Content-Type |  | HTTP uses Internet Media Types [RFC2046] in the Content-Type |
| (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order |  | (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order |
| to provide open and extensible data typing and type negotiation. |  | to provide open and extensible data typing and type negotiation. |
| Media types define both a data format and various processing models: |  | Media types define both a data format and various processing models: |
| how to process that data in accordance with each context in which it |  | how to process that data in accordance with each context in which it |
| is received. |  | is received. |
| skipping to change at page 10, line 9 |  | skipping to change at page 10, line 8 |
| Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the |  | Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the |
| performance characteristics of email deployments (i.e., store and |  | performance characteristics of email deployments (i.e., store and |
| forward messages to peers) are significantly different from those |  | forward messages to peers) are significantly different from those |
| common to HTTP and the Web (server-based information services). |  | common to HTTP and the Web (server-based information services). |
| Furthermore, MIME's constraints for the sake of compatibility with |  | Furthermore, MIME's constraints for the sake of compatibility with |
| older mail transfer protocols do not apply to HTTP (see Appendix A). |  | older mail transfer protocols do not apply to HTTP (see Appendix A). |
| MIME's canonical form requires that media subtypes of the "text" type |  | MIME's canonical form requires that media subtypes of the "text" type |
| use CRLF as the text line break. HTTP allows the transfer of text |  | use CRLF as the text line break. HTTP allows the transfer of text |
| media with plain CR or LF alone representing a line break, when such |  | media with plain CR or LF alone representing a line break, when such |
| line breaks are consistent for an entire representation. HTTP |  | line breaks are consistent for an entire representation. An HTTP |
| senders MAY generate, and recipients MUST be able to parse, line |  | sender MAY generate, and a recipient MUST be able to parse, line |
| breaks in text media that consist of CRLF, bare CR, or bare LF. In |  | breaks in text media that consist of CRLF, bare CR, or bare LF. In |
| addition, text media in HTTP is not limited to charsets that use |  | addition, text media in HTTP is not limited to charsets that use |
| octets 13 and 10 for CR and LF, respectively. This flexibility |  | octets 13 and 10 for CR and LF, respectively. This flexibility |
| regarding line breaks applies only to text within a representation |  | regarding line breaks applies only to text within a representation |
| that has been assigned a "text" media type; it does not apply to |  | that has been assigned a "text" media type; it does not apply to |
| "multipart" types or HTTP elements outside the payload body (e.g., |  | "multipart" types or HTTP elements outside the payload body (e.g., |
| header fields). |  | header fields). |
| If a representation is encoded with a content-coding, the underlying |  | If a representation is encoded with a content-coding, the underlying |
| data ought to be in a form defined above prior to being encoded. |  | data ought to be in a form defined above prior to being encoded. |
| skipping to change at page 11, line 5 |  | skipping to change at page 11, line 4 |
| message payload or the selected representation, as determined by the |  | message payload or the selected representation, as determined by the |
| message semantics. The indicated media type defines both the data |  | message semantics. The indicated media type defines both the data |
| format and how that data is intended to be processed by a recipient, |  | format and how that data is intended to be processed by a recipient, |
| within the scope of the received message semantics, after any content |  | within the scope of the received message semantics, after any content |
| codings indicated by Content-Encoding are decoded. |  | codings indicated by Content-Encoding are decoded. |
| Content-Type = media-type |  | Content-Type = media-type |
| Media types are defined in Section 3.1.1.1. An example of the field |  | Media types are defined in Section 3.1.1.1. An example of the field |
| is |  | is |
| Content-Type: text/html; charset=ISO-8859-4 |  | Content-Type: text/html; charset=ISO-8859-4 |
| A sender that generates a message containing a payload body SHOULD |  | A sender that generates a message containing a payload body SHOULD |
| generate a Content-Type header field in that message unless the |  | generate a Content-Type header field in that message unless the |
| intended media type of the enclosed representation is unknown to the |  | intended media type of the enclosed representation is unknown to the |
| sender. If a Content-Type header field is not present, recipients |  | sender. If a Content-Type header field is not present, the recipient |
| MAY either assume a media type of "application/octet-stream" |  | MAY either assume a media type of "application/octet-stream" |
| ([RFC2046], Section 4.5.1) or examine the data to determine its type. |  | ([RFC2046], Section 4.5.1) or examine the data to determine its type. |
| In practice, resource owners do not always properly configure their |  | In practice, resource owners do not always properly configure their |
| origin server to provide the correct Content-Type for a given |  | origin server to provide the correct Content-Type for a given |
| representation, with the result that some clients will examine a |  | representation, with the result that some clients will examine a |
| payload's content and override the specified type. Clients that do |  | payload's content and override the specified type. Clients that do |
| so risk drawing incorrect conclusions, which might expose additional |  | so risk drawing incorrect conclusions, which might expose additional |
| security risks (e.g., "privilege escalation"). Furthermore, it is |  | security risks (e.g., "privilege escalation"). Furthermore, it is |
| impossible to determine the sender's intent by examining the data |  | impossible to determine the sender's intent by examining the data |
| skipping to change at page 11, line 36 |  | skipping to change at page 11, line 34 |
| 3.1.2. Encoding for Compression or Integrity |  | 3.1.2. Encoding for Compression or Integrity |
| 3.1.2.1. Content Codings |  | 3.1.2.1. Content Codings |
| Content coding values indicate an encoding transformation that has |  | Content coding values indicate an encoding transformation that has |
| been or can be applied to a representation. Content codings are |  | been or can be applied to a representation. Content codings are |
| primarily used to allow a representation to be compressed or |  | primarily used to allow a representation to be compressed or |
| otherwise usefully transformed without losing the identity of its |  | otherwise usefully transformed without losing the identity of its |
| underlying media type and without loss of information. Frequently, |  | underlying media type and without loss of information. Frequently, |
| the representation is stored in coded form, transmitted directly, and |  | the representation is stored in coded form, transmitted directly, and |
| only decoded by the recipient. |  | only decoded by the final recipient. |
| content-coding = token |  | content-coding = token |
| All content-coding values are case-insensitive and ought to be |  | All content-coding values are case-insensitive and ought to be |
| registered within the HTTP Content Coding registry, as defined in |  | registered within the HTTP Content Coding registry, as defined in |
| Section 8.4. They are used in the Accept-Encoding (Section 5.3.4) |  | Section 8.4. They are used in the Accept-Encoding (Section 5.3.4) |
| and Content-Encoding (Section 3.1.2.2) header fields. |  | and Content-Encoding (Section 3.1.2.2) header fields. |
| The following content-coding values are defined by this |  | The following content-coding values are defined by this |
| specification: |  | specification: |
| skipping to change at page 12, line 23 |  | skipping to change at page 12, line 21 |
| header field. Content-Encoding is primarily used to allow a |  | header field. Content-Encoding is primarily used to allow a |
| representation's data to be compressed without losing the identity of |  | representation's data to be compressed without losing the identity of |
| its underlying media type. |  | its underlying media type. |
| Content-Encoding = 1#content-coding |  | Content-Encoding = 1#content-coding |
| An example of its use is |  | An example of its use is |
| Content-Encoding: gzip |  | Content-Encoding: gzip |
| If multiple encodings have been applied to a representation, the |  | If one or more encodings have been applied to a representation, the |
| content codings MUST be listed in the order in which they were |  | sender that applied the encodings MUST generate a Content-Encoding |
| applied. Additional information about the encoding parameters MAY be |  | header field that lists the content codings in the order in which |
| provided by other header fields not defined by this specification. |  | they were applied. Additional information about the encoding |
|  |  | parameters MAY be provided by other header fields not defined by this |
|  |  | specification. |
| Unlike Transfer-Encoding (Section 3.3.1 of [Part1]), the codings |  | Unlike Transfer-Encoding (Section 3.3.1 of [Part1]), the codings |
| listed in Content-Encoding are a characteristic of the |  | listed in Content-Encoding are a characteristic of the |
| representation; the representation is defined in terms of the coded |  | representation; the representation is defined in terms of the coded |
| form, and all other metadata about the representation is about the |  | form, and all other metadata about the representation is about the |
| coded form unless otherwise noted in the metadata definition. |  | coded form unless otherwise noted in the metadata definition. |
| Typically, the representation is only decoded just prior to rendering |  | Typically, the representation is only decoded just prior to rendering |
| or analogous usage. |  | or analogous usage. |
| If the media type includes an inherent encoding, such as a data |  | If the media type includes an inherent encoding, such as a data |
| skipping to change at page 13, line 12 |  | skipping to change at page 13, line 12 |
| Media Type) if a representation in the request message has a content |  | Media Type) if a representation in the request message has a content |
| coding that is not acceptable. |  | coding that is not acceptable. |
| 3.1.3. Audience Language |  | 3.1.3. Audience Language |
| 3.1.3.1. Language Tags |  | 3.1.3.1. Language Tags |
| A language tag, as defined in [RFC5646], identifies a natural |  | A language tag, as defined in [RFC5646], identifies a natural |
| language spoken, written, or otherwise conveyed by human beings for |  | language spoken, written, or otherwise conveyed by human beings for |
| communication of information to other human beings. Computer |  | communication of information to other human beings. Computer |
| languages are explicitly excluded. HTTP uses language tags within |  | languages are explicitly excluded. |
| the Accept-Language and Content-Language header fields. |  |  |
| Accept-Language uses the looser language-range production defined in |  | HTTP uses language tags within the Accept-Language and Content- |
| Section 5.3.5, whereas Content-Language uses the stricter language- |  | Language header fields. Accept-Language uses the broader language- |
| tag production defined below. |  | range production defined in Section 5.3.5, whereas Content-Language |
|  |  | uses the language-tag production defined below. |
| language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> |  | language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> |
| A language tag is composed of one or more parts: a primary language |  | A language tag is a sequence of one or more case-insensitive subtags, |
| subtag followed by a possibly empty series of subtags. White space |  | each separated by a hyphen character ("-", %x2D). In most cases, a |
| is not allowed within the tag and all tags are case-insensitive. |  | language tag consists of a primary language subtag that identifies a |
| Example tags include: |  | broad family of related languages (e.g., "en" = English) which is |
|  |  | optionally followed by a series of subtags that refine or narrow that |
|  |  | language's range (e.g., "en-CA" = the variety of English as |
|  |  | communicated in Canada). Whitespace is not allowed within a language |
|  |  | tag. Example tags include: |
| en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN |  | fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN |
| See [RFC5646] for further information. |  | See [RFC5646] for further information. |
| 3.1.3.2. Content-Language |  | 3.1.3.2. Content-Language |
| The "Content-Language" header field describes the natural language(s) |  | The "Content-Language" header field describes the natural language(s) |
| of the intended audience for the representation. Note that this |  | of the intended audience for the representation. Note that this |
| might not be equivalent to all the languages used within the |  | might not be equivalent to all the languages used within the |
| representation. |  | representation. |
| skipping to change at page 14, line 35 |  | skipping to change at page 14, line 39 |
| payload, it is often desirable for the sender to supply, or the |  | payload, it is often desirable for the sender to supply, or the |
| recipient to determine, an identifier for a resource corresponding to |  | recipient to determine, an identifier for a resource corresponding to |
| that representation. |  | that representation. |
| For a request message: |  | For a request message: |
| o If the request has a Content-Location header field, then the |  | o If the request has a Content-Location header field, then the |
| sender asserts that the payload is a representation of the |  | sender asserts that the payload is a representation of the |
| resource identified by the Content-Location field-value. However, |  | resource identified by the Content-Location field-value. However, |
| such an assertion cannot be trusted unless it can be verified by |  | such an assertion cannot be trusted unless it can be verified by |
| other means (not defined by HTTP). The information might still be |  | other means (not defined by this specification). The information |
| useful for revision history links. |  | might still be useful for revision history links. |
| o Otherwise, the payload is unidentified. |  | o Otherwise, the payload is unidentified. |
| For a response message, the following rules are applied in order |  | For a response message, the following rules are applied in order |
| until a match is found: |  | until a match is found: |
| 1. If the request is GET or HEAD and the response status code is 200 |  | 1. If the request is GET or HEAD and the response status code is 200 |
| (OK), 204 (No Content), 206 (Partial Content), or 304 (Not |  | (OK), 204 (No Content), 206 (Partial Content), or 304 (Not |
| Modified), the payload is a representation of the resource |  | Modified), the payload is a representation of the resource |
| identified by the effective request URI (Section 5.5 of [Part1]). |  | identified by the effective request URI (Section 5.5 of [Part1]). |
| skipping to change at page 15, line 15 |  | skipping to change at page 15, line 20 |
| 3. If the response has a Content-Location header field and its |  | 3. If the response has a Content-Location header field and its |
| field-value is a reference to the same URI as the effective |  | field-value is a reference to the same URI as the effective |
| request URI, the payload is a representation of the resource |  | request URI, the payload is a representation of the resource |
| identified by the effective request URI. |  | identified by the effective request URI. |
| 4. If the response has a Content-Location header field and its |  | 4. If the response has a Content-Location header field and its |
| field-value is a reference to a URI different from the effective |  | field-value is a reference to a URI different from the effective |
| request URI, then the sender asserts that the payload is a |  | request URI, then the sender asserts that the payload is a |
| representation of the resource identified by the Content-Location |  | representation of the resource identified by the Content-Location |
| field-value. However, such an assertion cannot be trusted unless |  | field-value. However, such an assertion cannot be trusted unless |
| it can be verified by other means (not defined by HTTP). |  | it can be verified by other means (not defined by this |
|  |  | specification). |
| 5. Otherwise, the payload is unidentified. |  | 5. Otherwise, the payload is unidentified. |
| 3.1.4.2. Content-Location |  | 3.1.4.2. Content-Location |
| The "Content-Location" header field references a URI that can be used |  | The "Content-Location" header field references a URI that can be used |
| as an identifier for a specific resource corresponding to the |  | as an identifier for a specific resource corresponding to the |
| representation in this message's payload. In other words, if one |  | representation in this message's payload. In other words, if one |
| were to perform a GET request on this URI at the time of this |  | were to perform a GET request on this URI at the time of this |
| message's generation, then a 200 (OK) response would contain the same |  | message's generation, then a 200 (OK) response would contain the same |
| skipping to change at page 18, line 39 |  | skipping to change at page 18, line 45 |
| patterns of content negotiation include "conditional content", where |  | patterns of content negotiation include "conditional content", where |
| the representation consists of multiple parts that are selectively |  | the representation consists of multiple parts that are selectively |
| rendered based on user agent parameters, "active content", where the |  | rendered based on user agent parameters, "active content", where the |
| representation contains a script that makes additional (more |  | representation contains a script that makes additional (more |
| specific) requests based on the user agent characteristics, and |  | specific) requests based on the user agent characteristics, and |
| "Transparent Content Negotiation" ([RFC2295]), where content |  | "Transparent Content Negotiation" ([RFC2295]), where content |
| selection is performed by an intermediary. These patterns are not |  | selection is performed by an intermediary. These patterns are not |
| mutually exclusive, and each has trade-offs in applicability and |  | mutually exclusive, and each has trade-offs in applicability and |
| practicality. |  | practicality. |
| Note that, in all cases, the supplier of representations to the |  | Note that, in all cases, HTTP is not aware of the resource semantics. |
| origin server determines which representations might be considered to |  | The consistency with which an origin server responds to requests, |
| be the "same information". |  | over time and over the varying dimensions of content negotiation, and |
|  |  | thus the "sameness" of a resource's observed representations over |
|  |  | time, is determined entirely by whatever entity or algorithm selects |
|  |  | or generates those responses. HTTP pays no attention to the man |
|  |  | behind the curtain. |
| 3.4.1. Proactive Negotiation |  | 3.4.1. Proactive Negotiation |
| When content negotiation preferences are sent by the user agent in a |  | When content negotiation preferences are sent by the user agent in a |
| request in order to encourage an algorithm located at the server to |  | request to encourage an algorithm located at the server to select the |
| select the preferred representation, it is called proactive |  | preferred representation, it is called proactive negotiation (a.k.a., |
| negotiation (a.k.a., server-driven negotiation). Selection is based |  | server-driven negotiation). Selection is based on the available |
| on the available representations for a response (the dimensions over |  | representations for a response (the dimensions over which it might |
| which it might vary, such as language, content-coding, etc.) compared |  | vary, such as language, content-coding, etc.) compared to various |
| to various information supplied in the request, including both the |  | information supplied in the request, including both the explicit |
| explicit negotiation fields of Section 5.3 and implicit |  | negotiation fields of Section 5.3 and implicit characteristics, such |
| characteristics, such as the client's network address or parts of the |  | as the client's network address or parts of the User-Agent field. |
| User-Agent field. |  |  |
| Proactive negotiation is advantageous when the algorithm for |  | Proactive negotiation is advantageous when the algorithm for |
| selecting from among the available representations is difficult to |  | selecting from among the available representations is difficult to |
| describe to a user agent, or when the server desires to send its |  | describe to a user agent, or when the server desires to send its |
| "best guess" to the user agent along with the first response (hoping |  | "best guess" to the user agent along with the first response (hoping |
| to avoid the round-trip delay of a subsequent request if the "best |  | to avoid the round-trip delay of a subsequent request if the "best |
| guess" is good enough for the user). In order to improve the |  | guess" is good enough for the user). In order to improve the |
| server's guess, a user agent MAY send request header fields that |  | server's guess, a user agent MAY send request header fields that |
| describe its preferences. |  | describe its preferences. |
| skipping to change at page 19, line 50 |  | skipping to change at page 20, line 11 |
| An origin server MAY generate a Vary header field (Section 7.1.4) in |  | An origin server MAY generate a Vary header field (Section 7.1.4) in |
| responses that are subject to proactive negotiation to indicate what |  | responses that are subject to proactive negotiation to indicate what |
| parameters of request information might be used in its selection |  | parameters of request information might be used in its selection |
| algorithm, thereby providing a means for recipients to determine the |  | algorithm, thereby providing a means for recipients to determine the |
| reusability of that same response for user agents with differing |  | reusability of that same response for user agents with differing |
| request information. |  | request information. |
| 3.4.2. Reactive Negotiation |  | 3.4.2. Reactive Negotiation |
| With reactive negotiation (a.k.a., agent-driven negotiation), |  | With reactive negotiation (a.k.a., agent-driven negotiation), |
| selection of the best representation for a response is performed by |  | selection of the best response representation (regardless of the |
| the user agent after receiving an initial response from the origin |  | status code) is performed by the user agent after receiving an |
| server with a list of alternative resources. If the user agent is |  | initial response from the origin server that contains a list of |
| not satisfied by the initial response, it can perform a GET request |  | resources for alternative representations. If the user agent is not |
| on one or more of the alternative resources, selected based on |  | satisfied by the initial response representation, it can perform a |
| metadata included in the list, to obtain a different form of |  | GET request on one or more of the alternative resources, selected |
| representation. Selection of alternatives might be performed |  | based on metadata included in the list, to obtain a different form of |
| automatically by the user agent or manually by the user selecting |  | representation for that response. Selection of alternatives might be |
| from a generated (possibly hypertext) menu. |  | performed automatically by the user agent or manually by the user |
|  |  | selecting from a generated (possibly hypertext) menu. |
| A server can send a 300 (Multiple Choices) response to indicate that |  | Note that the above refers to representations of the response, in |
| reactive negotiation by the user agent is desired, or a 406 (Not |  | general, not representations of the resource. The alternative |
| Acceptable) status code to indicate that proactive negotiation has |  | representations are only considered representations of the target |
| failed. In both cases, the response ought to include information |  | resource if the response in which those alternatives are provided has |
| about the available representations so that the user or user agent |  | the semantics of being a representation of the target resource (e.g., |
| can react by making a selection. |  | a 200 (OK) response to a GET request) or has the semantics of |
|  |  | providing links to alternative representations for the target |
|  |  | resource (e.g., a 300 (Multiple Choices) response to a GET request). |
|  |  | A server might choose not to send an initial representation, other |
|  |  | than the list of alternatives, and thereby indicate that reactive |
|  |  | negotiation by the user agent is preferred. For example, the |
|  |  | alternatives listed in responses with the 300 (Multiple Choices) and |
|  |  | 406 (Not Acceptable) status codes include information about the |
|  |  | available representations so that the user or user agent can react by |
|  |  | making a selection. |
| Reactive negotiation is advantageous when the response would vary |  | Reactive negotiation is advantageous when the response would vary |
| over commonly-used dimensions (such as type, language, or encoding), |  | over commonly-used dimensions (such as type, language, or encoding), |
| 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 |
| skipping to change at page 20, line 39 |  | skipping to change at page 21, line 11 |
| specification does not define a mechanism for supporting automatic |  | specification does not define a mechanism for supporting automatic |
| selection, though it does not prevent such a mechanism from being |  | selection, though it does not prevent such a mechanism from being |
| developed as an extension. |  | developed as an extension. |
| 4. Request Methods |  | 4. Request Methods |
| 4.1. Overview |  | 4.1. Overview |
| The request method token is the primary source of request semantics; |  | The request method token is the primary source of request semantics; |
| it indicates the purpose for which the client has made this request |  | it indicates the purpose for which the client has made this request |
| and what is expected by the client as a successful result. The |  | and what is expected by the client as a successful result. |
| request semantics might be further specialized by the semantics of |  |  |
| some header fields when present in a request (Section 5) if those |  | The request method's semantics might be further specialized by the |
| additional semantics do not conflict with the method. |  | semantics of some header fields when present in a request (Section 5) |
|  |  | if those additional semantics do not conflict with the method. For |
|  |  | example, a client can send conditional request header fields |
|  |  | (Section 5.2) to make the requested action conditional on the current |
|  |  | state of the target resource ([Part4]). |
| method = token |  | method = token |
| HTTP was originally designed to be usable as an interface to |  | HTTP was originally designed to be usable as an interface to |
| distributed object systems. The request method was envisioned as |  | distributed object systems. The request method was envisioned as |
| applying semantics to a target resource in much the same way as |  | applying semantics to a target resource in much the same way as |
| invoking a defined method on an identified object would apply |  | invoking a defined method on an identified object would apply |
| semantics. The method token is case-sensitive because it might be |  | semantics. The method token is case-sensitive because it might be |
| used as a gateway to object-based systems with case-sensitive method |  | used as a gateway to object-based systems with case-sensitive method |
| names. |  | names. |
| skipping to change at page 21, line 24 |  | skipping to change at page 22, line 11 |
| commonly used in HTTP, as outlined by the following table. By |  | commonly used in HTTP, as outlined by the following table. By |
| convention, standardized methods are defined in all-uppercase ASCII |  | convention, standardized methods are defined in all-uppercase ASCII |
| letters. |  | letters. |
| +---------+-------------------------------------------------+-------+ |  | +---------+-------------------------------------------------+-------+ |
| | Method | Description | Sec. | |  | | Method | Description | Sec. | |
| +---------+-------------------------------------------------+-------+ |  | +---------+-------------------------------------------------+-------+ |
| | GET | Transfer a current representation of the target | 4.3.1 | |  | | GET | Transfer a current representation of the target | 4.3.1 | |
| | | resource. | | |  | | | resource. | | |
| | HEAD | Same as GET, but only transfer the status line | 4.3.2 | |  | | HEAD | Same as GET, but only transfer the status line | 4.3.2 | |
| | | and header block. | | |  | | | and header section. | | |
| | POST | Perform resource-specific processing on the | 4.3.3 | |  | | POST | Perform resource-specific processing on the | 4.3.3 | |
| | | request payload. | | |  | | | request payload. | | |
| | PUT | Replace all current representations of the | 4.3.4 | |  | | PUT | Replace all current representations of the | 4.3.4 | |
| | | target resource with the request payload. | | |  | | | target resource with the request payload. | | |
| | DELETE | Remove all current representations of the | 4.3.5 | |  | | DELETE | Remove all current representations of the | 4.3.5 | |
| | | target resource. | | |  | | | target resource. | | |
| | CONNECT | Establish a tunnel to the server identified by | 4.3.6 | |  | | CONNECT | Establish a tunnel to the server identified by | 4.3.6 | |
| | | the target resource. | | |  | | | the target resource. | | |
| | OPTIONS | Describe the communication options for the | 4.3.7 | |  | | OPTIONS | Describe the communication options for the | 4.3.7 | |
| | | target resource. | | |  | | | target resource. | | |
| skipping to change at page 22, line 10 |  | skipping to change at page 22, line 45 |
| The set of methods allowed by a target resource can be listed in an |  | The set of methods allowed by a target resource can be listed in an |
| Allow header field (Section 7.4.1). However, the set of allowed |  | Allow header field (Section 7.4.1). However, the set of allowed |
| methods can change dynamically. When a request method is received |  | methods can change dynamically. When a request method is received |
| that is unrecognized or not implemented by an origin server, the |  | that is unrecognized or not implemented by an origin server, the |
| origin server SHOULD respond with the 501 (Not Implemented) status |  | origin server SHOULD respond with the 501 (Not Implemented) status |
| code. When a request method is received that is known by an origin |  | code. When a request method is received that is known by an origin |
| server but not allowed for the target resource, the origin server |  | server but not allowed for the target resource, the origin server |
| SHOULD respond with the 405 (Method Not Allowed) status code. |  | SHOULD respond with the 405 (Method Not Allowed) status code. |
| A client can send conditional request header fields (Section 5.2) to |  |  |
| make the requested action conditional on the current state of the |  |  |
| target resource ([Part4]). |  |  |
| 4.2. Common Method Properties |  | 4.2. Common Method Properties |
| 4.2.1. Safe Methods |  | 4.2.1. Safe Methods |
| Request methods are considered "safe" if their defined semantics are |  | Request methods are considered "safe" if their defined semantics are |
| essentially read-only; i.e., the client does not request, and does |  | essentially read-only; i.e., the client does not request, and does |
| not expect, any state change on the origin server as a result of |  | not expect, any state change on the origin server as a result of |
| applying a safe method to a target resource. Likewise, reasonable |  | applying a safe method to a target resource. Likewise, reasonable |
| use of a safe method is not expected to cause any harm, loss of |  | use of a safe method is not expected to cause any harm, loss of |
| property, or unusual burden on the origin server. |  | property, or unusual burden on the origin server. |
| skipping to change at page 23, line 9 |  | skipping to change at page 23, line 39 |
| A user agent SHOULD distinguish between safe and unsafe methods when |  | A user agent SHOULD distinguish between safe and unsafe methods when |
| presenting potential actions to a user, such that the user can be |  | presenting potential actions to a user, such that the user can be |
| made aware of an unsafe action before it is requested. |  | made aware of an unsafe action before it is requested. |
| When a resource is constructed such that parameters within the |  | When a resource is constructed such that parameters within the |
| effective request URI have the effect of selecting an action, it is |  | effective request URI have the effect of selecting an action, it is |
| the resource owner's responsibility to ensure that the action is |  | the resource owner's responsibility to ensure that the action is |
| consistent with the request method semantics. For example, it is |  | consistent with the request method semantics. For example, it is |
| common for Web-based content editing software to use actions within |  | common for Web-based content editing software to use actions within |
| query parameters, such as "page?do=delete". If the purpose of such a |  | query parameters, such as "page?do=delete". If the purpose of such a |
| resource is to perform an unsafe action, then the resource MUST |  | resource is to perform an unsafe action, then the resource owner MUST |
| disable or disallow that action when it is accessed using a safe |  | disable or disallow that action when it is accessed using a safe |
| request method. Failure to do so will result in unfortunate side- |  | request method. Failure to do so will result in unfortunate side- |
| effects when automated processes perform a GET on every URI reference |  | effects when automated processes perform a GET on every URI reference |
| for the sake of link maintenance, pre-fetching, building a search |  | for the sake of link maintenance, pre-fetching, building a search |
| index, etc. |  | index, etc. |
| 4.2.2. Idempotent Methods |  | 4.2.2. Idempotent Methods |
| Request methods are considered "idempotent" if the intended effect of |  | Request methods are considered "idempotent" if the intended effect of |
| multiple identical requests is the same as for a single request. Of |  | multiple identical requests is the same as for a single request. Of |
| skipping to change at page 23, line 40 |  | skipping to change at page 24, line 22 |
| client is able to read the server's response. For example, if a |  | client is able to read the server's response. For example, if a |
| client sends a PUT request and the underlying connection is closed |  | client sends a PUT request and the underlying connection is closed |
| before any response is received, then it can establish a new |  | before any response is received, then it can establish a new |
| connection and retry the idempotent request because it knows that |  | connection and retry the idempotent request because it knows that |
| repeating the request will have the same effect even if the original |  | repeating the request will have the same effect even if the original |
| request succeeded. Note, however, that repeated failures would |  | request succeeded. Note, however, that repeated failures would |
| indicate a problem within the server. |  | indicate a problem within the server. |
| 4.2.3. Cacheable Methods |  | 4.2.3. Cacheable Methods |
| Request methods are considered "cacheable" if it is possible and |  | Request methods can be defined as "cacheable" to indicate that |
| useful to answer a current client request with a stored response from |  | responses to them are allowed to be stored for future reuse; for |
| a prior request. GET and HEAD are defined to be cacheable. In |  | specific requirements see [Part6]. In general, safe methods that do |
| general, safe methods that do not depend on a current or |  | not depend on a current or authoritative response are defined as |
| authoritative response are cacheable, though the overwhelming |  | cacheable; this specification defines GET, HEAD and POST as |
| majority of caches only support GET and HEAD. HTTP requirements for |  | cacheable, although the overwhelming majority of cache |
| cache behavior and cacheable responses are defined in [Part6]. |  | implementations only support GET and HEAD. |
| 4.3. Method Definitions |  | 4.3. Method Definitions |
| 4.3.1. GET |  | 4.3.1. GET |
| The GET method requests transfer of a current selected representation |  | The GET method requests transfer of a current selected representation |
| for the target resource. GET is the primary mechanism of information |  | for the target resource. GET is the primary mechanism of information |
| retrieval and the focus of almost all performance optimizations. |  | retrieval and the focus of almost all performance optimizations. |
| Hence, when people speak of retrieving some identifiable information |  | Hence, when people speak of retrieving some identifiable information |
| via HTTP, they are generally referring to making a GET request. |  | via HTTP, they are generally referring to making a GET request. |
| It is tempting to think of resource identifiers as remote filesystem |  | It is tempting to think of resource identifiers as remote filesystem |
| pathnames, and of representations as being a copy of the contents of |  | pathnames, and of representations as being a copy of the contents of |
| skipping to change at page 24, line 39 |  | skipping to change at page 25, line 18 |
| requesting transfer of only some part(s) of the selected |  | requesting transfer of only some part(s) of the selected |
| representation, by sending a Range header field in the request |  | representation, by sending a Range header field in the request |
| ([Part5]). |  | ([Part5]). |
| A payload within a GET request message has no defined semantics; |  | A payload within a GET request message has no defined semantics; |
| sending a payload body on a GET request might cause some existing |  | sending a payload body on a GET request might cause some existing |
| implementations to reject the request. |  | implementations to reject the request. |
| The response to a GET request is cacheable; a cache MAY use it to |  | The response to a GET request is cacheable; a cache MAY use it to |
| satisfy subsequent GET and HEAD requests unless otherwise indicated |  | satisfy subsequent GET and HEAD requests unless otherwise indicated |
| by the Cache-Control header field (Section 7.2 of [Part6]). |  | by the Cache-Control header field (Section 5.2 of [Part6]). |
| 4.3.2. HEAD |  | 4.3.2. HEAD |
| The HEAD method is identical to GET except that the server MUST NOT |  | The HEAD method is identical to GET except that the server MUST NOT |
| send a message body in the response (i.e., the response terminates at |  | send a message body in the response (i.e., the response terminates at |
| the end of the header block). Aside from the payload header fields |  | the end of the header section). The server SHOULD send the same |
| (Section 3.3), the server SHOULD send the same header fields in |  | header fields in response to a HEAD request as it would have sent if |
| response to a HEAD request as it would have sent if the request had |  | the request had been a GET, except that the payload header fields |
| been a GET. This method can be used for obtaining metadata about the |  | (Section 3.3) MAY be omitted. This method can be used for obtaining |
| selected representation without transferring the representation data. |  | metadata about the selected representation without transferring the |
| This method is often used for testing hypertext links for validity, |  | representation data and is often used for testing hypertext links for |
| accessibility, and recent modification. |  | validity, accessibility, and recent modification. |
| A payload within a HEAD request message has no defined semantics; |  | A payload within a HEAD request message has no defined semantics; |
| sending a payload body on a HEAD request might cause some existing |  | sending a payload body on a HEAD request might cause some existing |
| implementations to reject the request. |  | implementations to reject the request. |
| The response to a HEAD request is cacheable; a cache MAY use it to |  | The response to a HEAD request is cacheable; a cache MAY use it to |
| satisfy subsequent HEAD requests unless otherwise indicated by the |  | satisfy subsequent HEAD requests unless otherwise indicated by the |
| Cache-Control header field (Section 7.2 of [Part6]). A HEAD response |  | Cache-Control header field (Section 5.2 of [Part6]). A HEAD response |
| might also have an effect on previously cached responses to GET; see |  | might also have an effect on previously cached responses to GET; see |
| Section 5 of [Part6]. |  | Section 4.3.5 of [Part6]. |
| 4.3.3. POST |  | 4.3.3. POST |
| The POST method requests that the target resource process the |  | The POST method requests that the target resource process the |
| representation enclosed in the request according to the resource's |  | representation enclosed in the request according to the resource's |
| own specific semantics. For example, POST is used for the following |  | own specific semantics. For example, POST is used for the following |
| functions (among others): |  | functions (among others): |
| o Providing a block of data, such as the fields entered into an HTML |  | o Providing a block of data, such as the fields entered into an HTML |
| form, to a data-handling process; |  | form, to a data-handling process; |
| skipping to change at page 25, line 47 |  | skipping to change at page 26, line 27 |
| being 206, 304, and 416). |  | being 206, 304, and 416). |
| If one or more resources has been created on the origin server as a |  | If one or more resources has been created on the origin server as a |
| result of successfully processing a POST request, the origin server |  | result of successfully processing a POST request, the origin server |
| SHOULD send a 201 (Created) response containing a Location header |  | SHOULD send a 201 (Created) response containing a Location header |
| field that provides an identifier for the primary resource created |  | field that provides an identifier for the primary resource created |
| (Section 7.1.2) and a representation that describes the status of the |  | (Section 7.1.2) and a representation that describes the status of the |
| request while referring to the new resource(s). |  | request while referring to the new resource(s). |
| Responses to POST requests are only cacheable when they include |  | Responses to POST requests are only cacheable when they include |
| explicit freshness information (see Section 4.1.1 of [Part6]). |  | explicit freshness information (see Section 4.2.1 of [Part6]). |
| However, POST caching is not widely implemented. For cases where an |  | However, POST caching is not widely implemented. For cases where an |
| origin server wishes the client to be able to cache the result of a |  | origin server wishes the client to be able to cache the result of a |
| POST in a way that can be reused by a later GET, the origin server |  | POST in a way that can be reused by a later GET, the origin server |
| MAY send a 200 (OK) response containing the result and a Content- |  | MAY send a 200 (OK) response containing the result and a Content- |
| Location header field that has the same value as the POST's effective |  | Location header field that has the same value as the POST's effective |
| request URI (Section 3.1.4.2). |  | request URI (Section 3.1.4.2). |
| If the result of processing a POST would be equivalent to a |  | If the result of processing a POST would be equivalent to a |
| representation of an existing resource, an origin server MAY redirect |  | representation of an existing resource, an origin server MAY redirect |
| the user agent to that resource by sending a 303 (See Other) response |  | the user agent to that resource by sending a 303 (See Other) response |
| skipping to change at page 26, line 35 |  | skipping to change at page 27, line 15 |
| subject to dynamic processing by the origin server, before any |  | subject to dynamic processing by the origin server, before any |
| subsequent GET is received. A successful response only implies that |  | subsequent GET is received. A successful response only implies that |
| the user agent's intent was achieved at the time of its processing by |  | the user agent's intent was achieved at the time of its processing by |
| the origin server. |  | the origin server. |
| If the target resource does not have a current representation and the |  | If the target resource does not have a current representation and the |
| PUT successfully creates one, then the origin server MUST inform the |  | PUT successfully creates one, then the origin server MUST inform the |
| user agent by sending a 201 (Created) response. If the target |  | user agent by sending a 201 (Created) response. If the target |
| resource does have a current representation and that representation |  | resource does have a current representation and that representation |
| is successfully modified in accordance with the state of the enclosed |  | is successfully modified in accordance with the state of the enclosed |
| representation, then either a 200 (OK) or 204 (No Content) response |  | representation, then the origin server MUST send either a 200 (OK) or |
| SHOULD be sent to indicate successful completion of the request. |  | a 204 (No Content) response to indicate successful completion of the |
|  |  | request. |
| An origin server SHOULD ignore unrecognized header fields received in |  | An origin server SHOULD ignore unrecognized header fields received in |
| a PUT request (i.e., do not save them as part of the resource state). |  | a PUT request (i.e., do not save them as part of the resource state). |
| An origin server SHOULD verify that the PUT representation is |  | An origin server SHOULD verify that the PUT representation is |
| consistent with any constraints the server has for the target |  | consistent with any constraints the server has for the target |
| resource that cannot or will not be changed by the PUT. This is |  | resource that cannot or will not be changed by the PUT. This is |
| particularly important when the origin server uses internal |  | particularly important when the origin server uses internal |
| configuration information related to the URI in order to set the |  | configuration information related to the URI in order to set the |
| values for representation metadata on GET responses. When a PUT |  | values for representation metadata on GET responses. When a PUT |
| representation is inconsistent with the target resource, the origin |  | representation is inconsistent with the target resource, the origin |
| server SHOULD either make them consistent, by transforming the |  | server SHOULD either make them consistent, by transforming the |
| representation or changing the resource configuration, or respond |  | representation or changing the resource configuration, or respond |
| with an appropriate error message containing sufficient information |  | with an appropriate error message containing sufficient information |
| to explain why the representation is unsuitable. The 409 (Conflict) |  | to explain why the representation is unsuitable. The 409 (Conflict) |
| or 415 (Unsupported Media Type) status codes are suggested, with the |  | or 415 (Unsupported Media Type) status codes are suggested, with the |
| latter being specific to constraints on Content-Type values. |  | latter being specific to constraints on Content-Type values. |
| For example, if the target resource is configured to always have a |  | For example, if the target resource is configured to always have a |
| Content-Type of "text/html" and the representation being PUT has a |  | Content-Type of "text/html" and the representation being PUT has a |
| Content-Type of "image/jpeg", then the origin server SHOULD do one |  | Content-Type of "image/jpeg", the origin server ought to do one of: |
| of: |  |  |
| a. reconfigure the target resource to reflect the new media type; |  | a. reconfigure the target resource to reflect the new media type; |
| b. transform the PUT representation to a format consistent with that |  | b. transform the PUT representation to a format consistent with that |
| of the resource before saving it as the new resource state; or, |  | of the resource before saving it as the new resource state; or, |
| c. reject the request with a 415 (Unsupported Media Type) response |  | c. reject the request with a 415 (Unsupported Media Type) response |
| indicating that the target resource is limited to "text/html", |  | indicating that the target resource is limited to "text/html", |
| perhaps including a link to a different resource that would be a |  | perhaps including a link to a different resource that would be a |
| suitable target for the new representation. |  | suitable target for the new representation. |
| skipping to change at page 28, line 18 |  | skipping to change at page 28, line 46 |
| knows which target resource is desired. A service that selects a |  | knows which target resource is desired. A service that selects a |
| proper URI on behalf of the client, after receiving a state-changing |  | proper URI on behalf of the client, after receiving a state-changing |
| request, SHOULD be implemented using the POST method rather than PUT. |  | request, SHOULD be implemented using the POST method rather than PUT. |
| If the origin server will not make the requested PUT state change to |  | If the origin server will not make the requested PUT state change to |
| the target resource and instead wishes to have it applied to a |  | the target resource and instead wishes to have it applied to a |
| different resource, such as when the resource has been moved to a |  | different resource, such as when the resource has been moved to a |
| different URI, then the origin server MUST send an appropriate 3xx |  | different URI, then the origin server MUST send an appropriate 3xx |
| (Redirection) response; the user agent MAY then make its own decision |  | (Redirection) response; the user agent MAY then make its own decision |
| regarding whether or not to redirect the request. |  | regarding whether or not to redirect the request. |
| A PUT request applied to the target resource MAY have side-effects on |  | A PUT request applied to the target resource can have side-effects on |
| other resources. For example, an article might have a URI for |  | other resources. For example, an article might have a URI for |
| identifying "the current version" (a resource) that is separate from |  | identifying "the current version" (a resource) that is separate from |
| the URIs identifying each particular version (different resources |  | the URIs identifying each particular version (different resources |
| that at one point shared the same state as the current version |  | that at one point shared the same state as the current version |
| resource). A successful PUT request on "the current version" URI |  | resource). A successful PUT request on "the current version" URI |
| might therefore create a new version resource in addition to changing |  | might therefore create a new version resource in addition to changing |
| the state of the target resource, and might also cause links to be |  | the state of the target resource, and might also cause links to be |
| added between the related resources. |  | added between the related resources. |
| An origin server SHOULD reject any PUT request that contains a |  | An origin server that allows PUT on a given target resource MUST send |
| Content-Range header field (Section 4.2 of [Part5]), since it might |  | a 400 (Bad Request) response to a PUT request that contains a |
| be misinterpreted as partial content (or might be partial content |  | Content-Range header field (Section 4.2 of [Part5]), since the |
| that is being mistakenly PUT as a full representation). Partial |  | payload is likely to be partial content that has been mistakenly PUT |
| content updates are possible by targeting a separately identified |  | as a full representation. Partial content updates are possible by |
| resource with state that overlaps a portion of the larger resource, |  | targeting a separately identified resource with state that overlaps a |
| or by using a different method that has been specifically defined for |  | portion of the larger resource, or by using a different method that |
| partial updates (for example, the PATCH method defined in [RFC5789]). |  | has been specifically defined for partial updates (for example, the |
|  |  | PATCH method defined in [RFC5789]). |
| Responses to the PUT method are not cacheable. If a PUT request |  | Responses to the PUT method are not cacheable. If a successful PUT |
| passes through a cache that has one or more stored responses for the |  | request passes through a cache that has one or more stored responses |
| effective request URI, those stored responses will be invalidated |  | for the effective request URI, those stored responses will be |
| (see Section 6 of [Part6]). |  | invalidated (see Section 4.4 of [Part6]). |
| 4.3.5. DELETE |  | 4.3.5. DELETE |
| The DELETE method requests that the origin server remove the |  | The DELETE method requests that the origin server remove the |
| association between the target resource and its current |  | association between the target resource and its current |
| functionality. In effect, this method is similar to the rm command |  | functionality. In effect, this method is similar to the rm command |
| in UNIX: it expresses a deletion operation on the URI mapping of the |  | in UNIX: it expresses a deletion operation on the URI mapping of the |
| origin server, rather than an expectation that the previously |  | origin server, rather than an expectation that the previously |
| associated information be deleted. |  | associated information be deleted. |
| skipping to change at page 29, line 27 |  | skipping to change at page 30, line 8 |
| previously created using a PUT request, or identified via the |  | previously created using a PUT request, or identified via the |
| Location header field after a 201 (Created) response to a POST |  | Location header field after a 201 (Created) response to a POST |
| request, might allow a corresponding DELETE request to undo those |  | request, might allow a corresponding DELETE request to undo those |
| actions. Similarly, custom user agent implementations that implement |  | actions. Similarly, custom user agent implementations that implement |
| an authoring function, such as revision control clients using HTTP |  | an authoring function, such as revision control clients using HTTP |
| for remote operations, might use DELETE based on an assumption that |  | for remote operations, might use DELETE based on an assumption that |
| the server's URI space has been crafted to correspond to a version |  | the server's URI space has been crafted to correspond to a version |
| repository. |  | repository. |
| If a DELETE method is successfully applied, the origin server SHOULD |  | If a DELETE method is successfully applied, the origin server SHOULD |
| send a 202 (Accepted) status code if the action seems okay but has |  | send a 202 (Accepted) status code if the action will likely succeed |
| not yet been enacted, a 204 (No Content) status code if the action |  | but has not yet been enacted, a 204 (No Content) status code if the |
| has been enacted and no further information is to be supplied, or a |  | action has been enacted and no further information is to be supplied, |
| 200 (OK) status code if the action has been enacted and the response |  | or a 200 (OK) status code if the action has been enacted and the |
| message includes a representation describing the status. |  | response message includes a representation describing the status. |
| A payload within a DELETE request message has no defined semantics; |  | A payload within a DELETE request message has no defined semantics; |
| sending a payload body on a DELETE request might cause some existing |  | sending a payload body on a DELETE request might cause some existing |
| implementations to reject the request. |  | implementations to reject the request. |
| Responses to the DELETE method are not cacheable. If a DELETE |  | Responses to the DELETE method are not cacheable. If a DELETE |
| request passes through a cache that has one or more stored responses |  | request passes through a cache that has one or more stored responses |
| for the effective request URI, those stored responses will be |  | for the effective request URI, those stored responses will be |
| invalidated (see Section 6 of [Part6]). |  | invalidated (see Section 4.4 of [Part6]). |
| 4.3.6. CONNECT |  | 4.3.6. CONNECT |
| The CONNECT method requests that the recipient establish a tunnel to |  | The CONNECT method requests that the recipient establish a tunnel to |
| the destination origin server identified by the request-target and, |  | the destination origin server identified by the request-target and, |
| if successful, thereafter restrict its behavior to blind forwarding |  | if successful, thereafter restrict its behavior to blind forwarding |
| of packets, in both directions, until the connection is closed. |  | of packets, in both directions, until the tunnel is closed. |
| CONNECT is intended only for use in requests to a proxy. An origin |  | CONNECT is intended only for use in requests to a proxy. An origin |
| server that receives a CONNECT request for itself MAY respond with a |  | server that receives a CONNECT request for itself MAY respond with a |
| 2xx status code to indicate that a connection is established. |  | 2xx status code to indicate that a connection is established. |
| However, most origin servers do not implement CONNECT. |  | However, most origin servers do not implement CONNECT. |
| A client sending a CONNECT request MUST send the authority form of |  | A client sending a CONNECT request MUST send the authority form of |
| request-target (Section 5.3 of [Part1]); i.e., the request-target |  | request-target (Section 5.3 of [Part1]); i.e., the request-target |
| consists of only the host name and port number of the tunnel |  | consists of only the host name and port number of the tunnel |
| destination, separated by a colon. For example, |  | destination, separated by a colon. For example, |
| CONNECT server.example.com:80 HTTP/1.1 |  | CONNECT server.example.com:80 HTTP/1.1 |
| Host: server.example.com:80 |  | Host: server.example.com:80 |
| skipping to change at page 30, line 20 |  | skipping to change at page 30, line 48 |
| destination, separated by a colon. For example, |  | destination, separated by a colon. For example, |
| CONNECT server.example.com:80 HTTP/1.1 |  | CONNECT server.example.com:80 HTTP/1.1 |
| Host: server.example.com:80 |  | Host: server.example.com:80 |
| The recipient proxy can establish a tunnel either by directly |  | The recipient proxy can establish a tunnel either by directly |
| connecting to the request-target or, if configured to use another |  | connecting to the request-target or, if configured to use another |
| proxy, by forwarding the CONNECT request to the next inbound proxy. |  | proxy, by forwarding the CONNECT request to the next inbound proxy. |
| Any 2xx (Successful) response indicates that the sender (and all |  | Any 2xx (Successful) response indicates that the sender (and all |
| inbound proxies) will switch to tunnel mode immediately after the |  | inbound proxies) will switch to tunnel mode immediately after the |
| blank line that concludes the successful response's header block; |  | blank line that concludes the successful response's header section; |
| data received after that blank line is from the server identified by |  | data received after that blank line is from the server identified by |
| the request-target. Any response other than a successful response |  | the request-target. Any response other than a successful response |
| indicates that the tunnel has not yet been formed and that the |  | indicates that the tunnel has not yet been formed and that the |
| connection remains governed by HTTP. |  | connection remains governed by HTTP. |
| A server SHOULD NOT send any Transfer-Encoding or Content-Length |  | A tunnel is closed when a tunnel intermediary detects that either |
| header fields in a successful response. A client MUST ignore any |  | side has closed its connection: the intermediary MUST attempt to send |
| Content-Length or Transfer-Encoding header fields received in a |  | any outstanding data that came from the closed side to the other |
| successful response. |  | side, close both connections, and then discard any remaining data |
|  |  | left undelivered. |
|  |  | Proxy authentication might be used to establish the authority to |
|  |  | create a tunnel. For example, |
|  |  | CONNECT server.example.com:80 HTTP/1.1 |
|  |  | Host: server.example.com:80 |
|  |  | Proxy-Authorization: basic aGVsbG86d29ybGQ= |
| There are significant risks in establishing a tunnel to arbitrary |  | There are significant risks in establishing a tunnel to arbitrary |
| servers, particularly when the destination is a well-known or |  | servers, particularly when the destination is a well-known or |
| reserved TCP port that is not intended for Web traffic. For example, |  | reserved TCP port that is not intended for Web traffic. For example, |
| a CONNECT to a request-target of "example.com:25" would suggest that |  | a CONNECT to a request-target of "example.com:25" would suggest that |
| the proxy connect to the reserved port for SMTP traffic; if allowed, |  | the proxy connect to the reserved port for SMTP traffic; if allowed, |
| that could trick the proxy into relaying spam email. Proxies that |  | that could trick the proxy into relaying spam email. Proxies that |
| support CONNECT SHOULD restrict its use to a limited set of known |  | support CONNECT SHOULD restrict its use to a limited set of known |
| ports or a configurable whitelist of safe request targets. |  | ports or a configurable whitelist of safe request targets. |
| Proxy authentication might be used to establish the authority to |  | A server MUST NOT send any Transfer-Encoding or Content-Length header |
| create a tunnel. For example, |  | fields in a 2xx (Successful) response to CONNECT. A client MUST |
|  |  | ignore any Content-Length or Transfer-Encoding header fields received |
| CONNECT server.example.com:80 HTTP/1.1 |  | in a successful response to CONNECT. |
| Host: server.example.com:80 |  |  |
| Proxy-Authorization: basic aGVsbG86d29ybGQ= |  |  |
| When a tunnel intermediary detects that either side has closed its |  |  |
| connection, any outstanding data that came from that side will first |  |  |
| be sent to the other side and then the intermediary will close both |  |  |
| connections. If there is outstanding data left undelivered, that |  |  |
| data will be discarded. |  |  |
| A payload within a CONNECT request message has no defined semantics; |  | A payload within a CONNECT request message has no defined semantics; |
| sending a payload body on a CONNECT request might cause some existing |  | sending a payload body on a CONNECT request might cause some existing |
| implementations to reject the request. |  | implementations to reject the request. |
| Responses to the CONNECT method are not cacheable. |  | Responses to the CONNECT method are not cacheable. |
| 4.3.7. OPTIONS |  | 4.3.7. OPTIONS |
| The OPTIONS method requests information about the communication |  | The OPTIONS method requests information about the communication |
| options available on the request/response chain identified by the |  | options available for the target resource, either at the origin |
| effective request URI. This method allows a client to determine the |  | server or an intervening intermediary. This method allows a client |
| options and/or requirements associated with a resource, or the |  | to determine the options and/or requirements associated with a |
| capabilities of a server, without implying a resource action. |  | resource, or the capabilities of a server, without implying a |
|  |  | resource action. |
| An OPTIONS request with an asterisk ("*") as the request-target |  | An OPTIONS request with an asterisk ("*") as the request-target |
| (Section 5.3 of [Part1]) applies to the server in general rather than |  | (Section 5.3 of [Part1]) applies to the server in general rather than |
| to a specific resource. Since a server's communication options |  | to a specific resource. Since a server's communication options |
| typically depend on the resource, the "*" request is only useful as a |  | typically depend on the resource, the "*" request is only useful as a |
| "ping" or "no-op" type of method; it does nothing beyond allowing the |  | "ping" or "no-op" type of method; it does nothing beyond allowing the |
| client to test the capabilities of the server. For example, this can |  | client to test the capabilities of the server. For example, this can |
| be used to test a proxy for HTTP/1.1 conformance (or lack thereof). |  | be used to test a proxy for HTTP/1.1 conformance (or lack thereof). |
| If the request-target is not an asterisk, the OPTIONS request applies |  | If the request-target is not an asterisk, the OPTIONS request applies |
| skipping to change at page 32, line 16 |  | skipping to change at page 32, line 46 |
| resource. |  | resource. |
| Responses to the OPTIONS method are not cacheable. |  | Responses to the OPTIONS method are not cacheable. |
| 4.3.8. TRACE |  | 4.3.8. TRACE |
| The TRACE method requests a remote, application-level loop-back of |  | The TRACE method requests a remote, application-level loop-back of |
| the request message. The final recipient of the request SHOULD |  | the request message. The final recipient of the request SHOULD |
| reflect the message received, excluding some fields described below, |  | reflect the message received, excluding some fields described below, |
| back to the client as the message body of a 200 (OK) response with a |  | back to the client as the message body of a 200 (OK) response with a |
| Content-Type of "message/http" (Section 7.3.1 of [Part1]). The final |  | Content-Type of "message/http" (Section 8.3.1 of [Part1]). The final |
| recipient is either the origin server or the first server to receive |  | recipient is either the origin server or the first server to receive |
| a Max-Forwards value of zero (0) in the request (Section 5.1.2). |  | a Max-Forwards value of zero (0) in the request (Section 5.1.2). |
| A client MUST NOT send header fields in a TRACE request containing |  | A client MUST NOT generate header fields in a TRACE request |
| sensitive data that might be disclosed by the response. For example, |  | containing sensitive data that might be disclosed by the response. |
| it would be foolish for a user agent to send stored user credentials |  |  |
| [Part7] or cookies [RFC6265] in a TRACE request. The final recipient |  | For example, it would be foolish for a user agent to send stored user |
| SHOULD exclude any request header fields from the response body that |  | credentials [Part7] or cookies [RFC6265] in a TRACE request. The |
| are likely to contain sensitive data. |  | final recipient of the request SHOULD exclude any request header |
|  |  | fields that are likely to contain sensitive data when that recipient |
|  |  | generates the response body. |
| TRACE allows the client to see what is being received at the other |  | TRACE allows the client to see what is being received at the other |
| end of the request chain and use that data for testing or diagnostic |  | end of the request chain and use that data for testing or diagnostic |
| information. The value of the Via header field (Section 5.7.1 of |  | information. The value of the Via header field (Section 5.7.1 of |
| [Part1]) is of particular interest, since it acts as a trace of the |  | [Part1]) is of particular interest, since it acts as a trace of the |
| request chain. Use of the Max-Forwards header field allows the |  | request chain. Use of the Max-Forwards header field allows the |
| client to limit the length of the request chain, which is useful for |  | client to limit the length of the request chain, which is useful for |
| testing a chain of proxies forwarding messages in an infinite loop. |  | testing a chain of proxies forwarding messages in an infinite loop. |
| A client MUST NOT send a message body in a TRACE request. |  | A client MUST NOT send a message body in a TRACE request. |
| skipping to change at page 33, line 8 |  | skipping to change at page 33, line 40 |
| parameters on a programming language method invocation. |  | parameters on a programming language method invocation. |
| 5.1. Controls |  | 5.1. Controls |
| Controls are request header fields that direct specific handling of |  | Controls are request header fields that direct specific handling of |
| the request. |  | the request. |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| | Cache-Control | Section 7.2 of [Part6] | |  | | Cache-Control | Section 5.2 of [Part6] | |
| | Expect | Section 5.1.1 | |  | | Expect | Section 5.1.1 | |
| | Host | Section 5.4 of [Part1] | |  | | Host | Section 5.4 of [Part1] | |
| | Max-Forwards | Section 5.1.2 | |  | | Max-Forwards | Section 5.1.2 | |
| | Pragma | Section 7.4 of [Part6] | |  | | Pragma | Section 5.4 of [Part6] | |
| | Range | Section 3.1 of [Part5] | |  | | Range | Section 3.1 of [Part5] | |
| | TE | Section 4.3 of [Part1] | |  | | TE | Section 4.3 of [Part1] | |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| 5.1.1. Expect |  | 5.1.1. Expect |
| The "Expect" header field is used to indicate that particular server |  | The "Expect" header field in a request indicates a certain set of |
| behaviors are required by the client. |  | behaviors (expectations) that need to be supported by the server in |
|  |  | order to properly handle this request. The only such expectation |
| Expect = 1#expectation |  | defined by this specification is 100-continue. |
| expectation = expect-name [ BWS "=" BWS expect-value ] |  |  |
| *( OWS ";" [ OWS expect-param ] ) |  |  |
| expect-param = expect-name [ BWS "=" BWS expect-value ] |  |  |
| expect-name = token |  |  |
| expect-value = token / quoted-string |  |  |
| If all received Expect header field(s) are syntactically valid but |  |  |
| contain an expectation that the recipient does not understand or |  |  |
| cannot comply with, the recipient MUST respond with a 417 |  |  |
| (Expectation Failed) status code. A recipient of a syntactically |  |  |
| invalid Expectation header field MUST respond with a 4xx status code |  |  |
| other than 417. |  |  |
| Comparison is case-insensitive for names (expect-name), and case- |  |  |
| sensitive for values (expect-value). |  |  |
| The Expect header field MUST be forwarded if the request is |  |  |
| forwarded. |  |  |
| Many older HTTP/1.0 and HTTP/1.1 servers do not understand the Expect |  |  |
| header field. |  |  |
| 5.1.1.1. Use of the 100 (Continue) Status |  | Expect = "100-continue" |
| The only expectation defined by this specification is: |  | The Expect field-value is case-insensitive. |
| 100-continue |  | A server that receives an Expect field-value other than 100-continue |
|  |  | MAY respond with a 417 (Expectation Failed) status code to indicate |
|  |  | that the unexpected expectation cannot be met. |
| The request includes a payload body and the client will wait for a |  | A 100-continue expectation informs recipients that the client is |
| 100 (Continue) response after sending the request header section |  | about to send a (presumably large) message body in this request and |
| but before sending the payload body. The 100-continue expectation |  | wishes to receive a 100 (Continue) interim response if the request- |
| does not use any expect-params. |  | line and header fields are not sufficient to cause an immediate |
|  |  | success, redirect, or error response. This allows the client to wait |
|  |  | for an indication that it is worthwhile to send the message body |
|  |  | before actually doing so, which can improve efficiency when the |
|  |  | message body is huge or when the client anticipates that an error is |
|  |  | likely (e.g., when sending a state-changing method, for the first |
|  |  | time, without previously verified authentication credentials). |
| The primary purpose of the 100 (Continue) status code (Section 6.2.1) |  | For example, a request that begins with |
| is to allow a client that is sending a request message with a payload |  |  |
| to determine if the origin server is willing to accept the request |  |  |
| (based on the request header fields) before the client sends the |  |  |
| payload body. In some cases, it might either be inappropriate or |  |  |
| highly inefficient for the client to send the payload body if the |  |  |
| server will reject the message without looking at the body. |  |  |
| Requirements for HTTP/1.1 clients: |  | PUT /somewhere/fun HTTP/1.1 |
|  |  | Host: origin.example.com |
|  |  | Content-Type: video/h264 |
|  |  | Content-Length: 1234567890987 |
|  |  | Expect: 100-continue |
| o If a client will wait for a 100 (Continue) response before sending |  | allows the origin server to immediately respond with an error |
| the payload body, it MUST send an Expect header field with the |  | message, such as 401 (Unauthorized) or 405 (Method Not Allowed), |
| "100-continue" expectation. |  | before the client starts filling the pipes with an unnecessary data |
|  |  | transfer. |
| o A client MUST NOT send an Expect header field with the "100- |  | Requirements for clients: |
| continue" expectation if it does not intend to send a payload |  |  |
| body. |  |  |
| Because of the presence of older implementations, the protocol allows |  | o A client MUST NOT generate a 100-continue expectation in a request |
| ambiguous situations in which a client might send "Expect: 100- |  | that does not include a message body. |
| continue" without receiving either a 417 (Expectation Failed) or a |  |  |
| 100 (Continue) status code. Therefore, when a client sends this |  |  |
| header field to an origin server (possibly via a proxy) from which it |  |  |
| has never seen a 100 (Continue) status code, the client SHOULD NOT |  |  |
| wait for an indefinite period before sending the payload body. |  |  |
| Requirements for HTTP/1.1 origin servers: |  | o A client that will wait for a 100 (Continue) response before |
|  |  | sending the request message body MUST send an Expect header field |
|  |  | containing a 100-continue expectation. |
| o Upon receiving a request that includes an Expect header field with |  | o A client that sends a 100-continue expectation is not required to |
| the "100-continue" expectation, an origin server MUST either |  | wait for any specific length of time; such a client MAY proceed to |
| respond with 100 (Continue) status code and continue to read from |  | send the message body even if it has not yet received a response. |
| the input stream, or respond with a final status code. The origin |  | Furthermore, since 100 (Continue) responses cannot be sent through |
| server MUST NOT wait for the payload body before sending the 100 |  | an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an |
| (Continue) response. If the origin server responds with a final |  | indefinite period before sending the message body. |
| status code, it MUST NOT have performed the request method and MAY |  |  |
| either close the connection or continue to read and discard the |  |  |
| rest of the request. |  |  |
| o An origin server SHOULD NOT send a 100 (Continue) response if the |  | o A client that receives a 417 (Expectation Failed) status code in |
| request message does not include an Expect header field with the |  | response to a request containing a 100-continue expectation SHOULD |
| "100-continue" expectation, and MUST NOT send a 100 (Continue) |  | repeat that request without a 100-continue expectation, since the |
| response if such a request comes from an HTTP/1.0 (or earlier) |  | 417 response merely indicates that the response chain does not |
| client. There is an exception to this rule: for compatibility |  | support expectations (e.g., it passes through an HTTP/1.0 server). |
| with [RFC2068], a server MAY send a 100 (Continue) status code in |  |  |
| response to an HTTP/1.1 PUT or POST request that does not include |  |  |
| an Expect header field with the "100-continue" expectation. This |  |  |
| exception, the purpose of which is to minimize any client |  |  |
| processing delays associated with an undeclared wait for 100 |  |  |
| (Continue) status code, applies only to HTTP/1.1 requests, and not |  |  |
| to requests with any other HTTP-version value. |  |  |
| o An origin server MAY omit a 100 (Continue) response if it has |  | Requirements for servers: |
| already received some or all of the payload body for the |  |  |
| corresponding request. |  |  |
| o An origin server that sends a 100 (Continue) response MUST |  | o A server that receives a 100-continue expectation in an HTTP/1.0 |
| ultimately send a final status code, once the payload body is |  | request MUST ignore that expectation. |
| received and processed, unless it terminates the transport |  |  |
| connection prematurely. |  |  |
| o If an origin server receives a request that does not include an |  | o A server MAY omit sending a 100 (Continue) response if it has |
| Expect header field with the "100-continue" expectation, the |  | already received some or all of the message body for the |
| request includes a payload body, and the server responds with a |  | corresponding request, or if the framing indicates that there is |
| final status code before reading the entire payload body from the |  | no message body. |
| transport connection, then the server SHOULD NOT close the |  |  |
| transport connection until it has read the entire request, or |  |  |
| until the client closes the connection. Otherwise, the client |  |  |
| might not reliably receive the response message. However, this |  |  |
| requirement ought not be construed as preventing a server from |  |  |
| defending itself against denial-of-service attacks, or from badly |  |  |
| broken client implementations. |  |  |
| Requirements for HTTP/1.1 proxies: |  | o A server that sends a 100 (Continue) response MUST ultimately send |
|  |  | a final status code, once the message body is received and |
|  |  | processed, unless the connection is closed prematurely. |
| o If a proxy receives a request that includes an Expect header field |  | o A server that responds with a final status code before reading the |
| with the "100-continue" expectation, and the proxy either knows |  | entire message body SHOULD indicate in that response whether it |
| that the next-hop server complies with HTTP/1.1 or higher, or does |  | intends to close the connection or continue reading and discarding |
| not know the HTTP version of the next-hop server, it MUST forward |  | the request message (see Section 6.6 of [Part1]). |
| the request, including the Expect header field. |  |  |
| o If the proxy knows that the version of the next-hop server is |  | An origin server MUST, upon receiving an HTTP/1.1 (or later) request- |
| HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST |  | line and a complete header section that contains a 100-continue |
| respond with a 417 (Expectation Failed) status code. |  | expectation and indicates a request message body will follow, either |
|  |  | send an immediate response with a final status code, if that status |
|  |  | can be determined by examining just the request-line and header |
|  |  | fields, or send an immediate 100 (Continue) response to encourage the |
|  |  | client to send the request's message body. The origin server MUST |
|  |  | NOT wait for the message body before sending the 100 (Continue) |
|  |  | response. |
| o Proxies SHOULD maintain a record of the HTTP version numbers |  | A proxy MUST, upon receiving an HTTP/1.1 (or later) request-line and |
| received from recently-referenced next-hop servers. |  | a complete header section that contains a 100-continue expectation |
|  |  | and indicates a request message body will follow, either send an |
|  |  | immediate response with a final status code, if that status can be |
|  |  | determined by examining just the request-line and header fields, or |
|  |  | begin forwarding the request toward the origin server by sending a |
|  |  | corresponding request-line and header section to the next inbound |
|  |  | server. If the proxy believes (from configuration or past |
|  |  | interaction) that the next inbound server only supports HTTP/1.0, the |
|  |  | proxy MAY generate an immediate 100 (Continue) response to encourage |
|  |  | the client to begin sending the message body. |
| o A proxy MUST NOT forward a 100 (Continue) response if the request |  | Note: The Expect header field was added after the original |
| message was received from an HTTP/1.0 (or earlier) client and did |  | publication of HTTP/1.1 [RFC2068] as both the means to request an |
| not include an Expect header field with the "100-continue" |  | interim 100 response and the general mechanism for indicating |
| expectation. This requirement overrides the general rule for |  | must-understand extensions. However, the extension mechanism has |
| forwarding of 1xx responses (see Section 6.2.1). |  | not been used by clients and the must-understand requirements have |
|  |  | not been implemented by many servers, rendering the extension |
|  |  | mechanism useless. This specification has removed the extension |
|  |  | mechanism in order to simplify the definition and processing of |
|  |  | 100-continue. |
| 5.1.2. Max-Forwards |  | 5.1.2. Max-Forwards |
| The "Max-Forwards" header field provides a mechanism with the TRACE |  | The "Max-Forwards" header field provides a mechanism with the TRACE |
| (Section 4.3.8) and OPTIONS (Section 4.3.7) methods to limit the |  | (Section 4.3.8) and OPTIONS (Section 4.3.7) request methods to limit |
| number of times that the request is forwarded by proxies. This can |  | the number of times that the request is forwarded by proxies. This |
| be useful when the client is attempting to trace a request that |  | can be useful when the client is attempting to trace a request that |
| appears to be failing or looping mid-chain. |  | appears to be failing or looping mid-chain. |
| Max-Forwards = 1*DIGIT |  | Max-Forwards = 1*DIGIT |
| The Max-Forwards value is a decimal integer indicating the remaining |  | The Max-Forwards value is a decimal integer indicating the remaining |
| number of times this request message can be forwarded. |  | number of times this request message can be forwarded. |
| Each recipient of a TRACE or OPTIONS request containing a Max- |  | Each intermediary that receives a TRACE or OPTIONS request containing |
| Forwards header field MUST check and update its value prior to |  | a Max-Forwards header field MUST check and update its value prior to |
| forwarding the request. If the received value is zero (0), the |  | forwarding the request. If the received value is zero (0), the |
| recipient MUST NOT forward the request; instead, it MUST respond as |  | intermediary MUST NOT forward the request; instead, the intermediary |
| the final recipient. If the received Max-Forwards value is greater |  | MUST respond as the final recipient. If the received Max-Forwards |
| than zero, then the forwarded message MUST contain an updated Max- |  | value is greater than zero, the intermediary MUST generate an updated |
| Forwards field with a value decremented by one (1). |  | Max-Forwards field in the forwarded message with a field-value that |
|  |  | is the lesser of: a) the received value decremented by one (1), or b) |
|  |  | the recipient's maximum supported value for Max-Forwards. |
| The Max-Forwards header field MAY be ignored for all other request |  | A recipient MAY ignore a Max-Forwards header field received with any |
| methods. |  | other request methods. |
| 5.2. Conditionals |  | 5.2. Conditionals |
| The HTTP conditional request header fields [Part4] allow a client to |  | The HTTP conditional request header fields [Part4] allow a client to |
| place a precondition on the state of the target resource, so that the |  | place a precondition on the state of the target resource, so that the |
| action corresponding to the method semantics will not be applied if |  | action corresponding to the method semantics will not be applied if |
| the precondition evaluates to false. Each precondition defined by |  | the precondition evaluates to false. Each precondition defined by |
| this specification consists of a comparison between a set of |  | this specification consists of a comparison between a set of |
| validators obtained from prior representations of the target resource |  | validators obtained from prior representations of the target resource |
| to the current state of validators for the selected representation |  | to the current state of validators for the selected representation |
| skipping to change at page 38, line 51 |  | skipping to change at page 39, line 11 |
| "q" from being used with a media range, such an event is believed |  | "q" from being used with a media range, such an event is believed |
| to be unlikely given the lack of any "q" parameters in the IANA |  | to be unlikely given the lack of any "q" parameters in the IANA |
| media type registry and the rare usage of any media type |  | media type registry and the rare usage of any media type |
| parameters in Accept. Future media types are discouraged from |  | parameters in Accept. Future media types are discouraged from |
| registering any parameter named "q". |  | registering any parameter named "q". |
| The example |  | The example |
| Accept: audio/*; q=0.2, audio/basic |  | Accept: audio/*; q=0.2, audio/basic |
| SHOULD be interpreted as "I prefer audio/basic, but send me any audio |  | is interpreted as "I prefer audio/basic, but send me any audio type |
| type if it is the best available after an 80% mark-down in quality". |  | if it is the best available after an 80% mark-down in quality". |
| A request without any Accept header field implies that the user agent |  | A request without any Accept header field implies that the user agent |
| will accept any media type in response. If the header field is |  | will accept any media type in response. If the header field is |
| present in a request and none of the available representations for |  | present in a request and none of the available representations for |
| the response have a media type that is listed as acceptable, the |  | the response have a media type that is listed as acceptable, the |
| origin server can either honor the header field by sending a 406 (Not |  | origin server can either honor the header field by sending a 406 (Not |
| Acceptable) response or disregard the header field by treating the |  | Acceptable) response or disregard the header field by treating the |
| response as if it is not subject to content negotiation. |  | response as if it is not subject to content negotiation. |
| A more elaborate example is |  | A more elaborate example is |
| skipping to change at page 44, line 39 |  | skipping to change at page 44, line 46 |
| An example is: |  | An example is: |
| From: webmaster@example.org |  | From: webmaster@example.org |
| The From header field is rarely sent by non-robotic user agents. A |  | The From header field is rarely sent by non-robotic user agents. A |
| user agent SHOULD NOT send a From header field without explicit |  | user agent SHOULD NOT send a From header field without explicit |
| configuration by the user, since that might conflict with the user's |  | configuration by the user, since that might conflict with the user's |
| privacy interests or their site's security policy. |  | privacy interests or their site's security policy. |
| Robotic user agents SHOULD send a valid From header field so that the |  | A robotic user agent SHOULD send a valid From header field so that |
| person responsible for running the robot can be contacted if problems |  | the person responsible for running the robot can be contacted if |
| occur on servers, such as if the robot is sending excessive, |  | problems occur on servers, such as if the robot is sending excessive, |
| unwanted, or invalid requests. |  | unwanted, or invalid requests. |
| Servers SHOULD NOT use the From header field for access control or |  | A server SHOULD NOT use the From header field for access control or |
| authentication, since most recipients will assume that the field |  | authentication, since most recipients will assume that the field |
| value is public information. |  | value is public information. |
| 5.5.2. Referer |  | 5.5.2. Referer |
| The "Referer" [sic] header field allows the user agent to specify a |  | The "Referer" [sic] header field allows the user agent to specify a |
| URI reference for the resource from which the target URI was obtained |  | URI reference for the resource from which the target URI was obtained |
| (i.e., the "referrer", though the field name is misspelled). A user |  | (i.e., the "referrer", though the field name is misspelled). A user |
| agent MUST exclude any fragment or userinfo components [RFC3986] when |  | agent MUST NOT include the fragment and userinfo components of the |
| generating the Referer field value. |  | URI reference [RFC3986], if any, when generating the Referer field |
|  |  | value. |
| Referer = absolute-URI / partial-URI |  | Referer = absolute-URI / partial-URI |
| Referer allows servers to generate back-links to other resources for |  | Referer allows servers to generate back-links to other resources for |
| simple analytics, logging, optimized caching, etc. It also allows |  | simple analytics, logging, optimized caching, etc. It also allows |
| obsolete or mistyped links to be found for maintenance. Some servers |  | obsolete or mistyped links to be found for maintenance. Some servers |
| use Referer as a means of denying links from other sites (so-called |  | use Referer as a means of denying links from other sites (so-called |
| "deep linking") or restricting cross-site request forgery (CSRF), but |  | "deep linking") or restricting cross-site request forgery (CSRF), but |
| not all requests contain a Referer header field. |  | not all requests contain a Referer header field. |
| skipping to change at page 45, line 32 |  | skipping to change at page 45, line 40 |
| user's bookmarks/favorites), the user agent MUST either exclude |  | user's bookmarks/favorites), the user agent MUST either exclude |
| Referer or send it with a value of "about:blank". |  | Referer or send it with a value of "about:blank". |
| The Referer field has the potential to reveal information about the |  | The Referer field has the potential to reveal information about the |
| request context or browsing history of the user, which is a privacy |  | request context or browsing history of the user, which is a privacy |
| concern if the referring resource's identifier reveals personal |  | concern if the referring resource's identifier reveals personal |
| information (such as an account name) or a resource that is supposed |  | information (such as an account name) or a resource that is supposed |
| to be confidential (such as behind a firewall or internal to a |  | to be confidential (such as behind a firewall or internal to a |
| secured service). Most general-purpose user agents do not send the |  | secured service). Most general-purpose user agents do not send the |
| Referer header field when the referring resource is a local "file" or |  | Referer header field when the referring resource is a local "file" or |
| "data" URI. A user agent SHOULD NOT send a Referer header field in |  | "data" URI. A user agent MUST NOT send a Referer header field in an |
| an unsecured HTTP request if the referring page was received with a |  | unsecured HTTP request if the referring page was received with a |
| secure protocol. See Section 9.3 for additional security |  | secure protocol. See Section 9.3 for additional security |
| considerations. |  | considerations. |
| Some intermediaries have been known to indiscriminately remove |  | Some intermediaries have been known to indiscriminately remove |
| Referer header fields from outgoing requests. This has the |  | Referer header fields from outgoing requests. This has the |
| unfortunate side-effect of interfering with protection against CSRF |  | unfortunate side-effect of interfering with protection against CSRF |
| attacks, which can be far more harmful to their users. |  | attacks, which can be far more harmful to their users. |
| Intermediaries and user agent extensions that wish to limit |  | Intermediaries and user agent extensions that wish to limit |
| information disclosure in Referer ought to restrict their changes to |  | information disclosure in Referer ought to restrict their changes to |
| specific edits, such as replacing internal domain names with |  | specific edits, such as replacing internal domain names with |
| pseudonyms or truncating the query and/or path components. |  | pseudonyms or truncating the query and/or path components. An |
| Intermediaries SHOULD NOT modify or delete the Referer field when the |  | intermediary SHOULD NOT modify or delete the Referer header field |
| field value shares the same scheme and host as the request target. |  | when the field value shares the same scheme and host as the request |
|  |  | target. |
| 5.5.3. User-Agent |  | 5.5.3. User-Agent |
| The "User-Agent" header field contains information about the user |  | The "User-Agent" header field contains information about the user |
| agent originating the request, which is often used by servers to help |  | agent originating the request, which is often used by servers to help |
| identify the scope of reported interoperability problems, to work |  | identify the scope of reported interoperability problems, to work |
| around or tailor responses to avoid particular user agent |  | around or tailor responses to avoid particular user agent |
| limitations, and for analytics regarding browser or operating system |  | limitations, and for analytics regarding browser or operating system |
| use. A user agent SHOULD send a User-Agent field in each request |  | use. A user agent SHOULD send a User-Agent field in each request |
| unless specifically configured not to do so. |  | unless specifically configured not to do so. |
| skipping to change at page 46, line 23 |  | skipping to change at page 46, line 32 |
| identifiers, each followed by zero or more comments (Section 3.2 of |  | identifiers, each followed by zero or more comments (Section 3.2 of |
| [Part1]), which together identify the user agent software and its |  | [Part1]), which together identify the user agent software and its |
| significant subproducts. By convention, the product identifiers are |  | significant subproducts. By convention, the product identifiers are |
| listed in decreasing order of their significance for identifying the |  | listed in decreasing order of their significance for identifying the |
| user agent software. Each product identifier consists of a name and |  | user agent software. Each product identifier consists of a name and |
| optional version. |  | optional version. |
| product = token ["/" product-version] |  | product = token ["/" product-version] |
| product-version = token |  | product-version = token |
| Senders SHOULD limit generated product identifiers to what is |  | A sender SHOULD limit generated product identifiers to what is |
| necessary to identify the product; senders MUST NOT generate |  | necessary to identify the product; a sender MUST NOT generate |
| advertising or other non-essential information within the product |  | advertising or other non-essential information within the product |
| identifier. Senders SHOULD NOT generate information in product- |  | identifier. A sender SHOULD NOT generate information in product- |
| version that is not a version identifier (i.e., successive versions |  | version that is not a version identifier (i.e., successive versions |
| of the same product name ought to only differ in the product-version |  | of the same product name ought to only differ in the product-version |
| portion of the product identifier). |  | portion of the product identifier). |
| Example: |  | Example: |
| User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |  | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
| A user agent SHOULD NOT generate a User-Agent field containing |  | A user agent SHOULD NOT generate a User-Agent field containing |
| needlessly fine-grained detail and SHOULD limit the addition of |  | needlessly fine-grained detail and SHOULD limit the addition of |
| skipping to change at page 47, line 12 |  | skipping to change at page 47, line 17 |
| that identified user agent, even if they might not work as well for |  | that identified user agent, even if they might not work as well for |
| the actual user agent being used. |  | the actual user agent being used. |
| 6. Response Status Codes |  | 6. Response Status Codes |
| The status-code element is a 3-digit integer code giving the result |  | The status-code element is a 3-digit integer code giving the result |
| of the attempt to understand and satisfy the request. |  | of the attempt to understand and satisfy the request. |
| HTTP status codes are extensible. HTTP clients are not required to |  | HTTP status codes are extensible. HTTP clients are not required to |
| understand the meaning of all registered status codes, though such |  | understand the meaning of all registered status codes, though such |
| understanding is obviously desirable. However, clients MUST |  | understanding is obviously desirable. However, a client MUST |
| understand the class of any status code, as indicated by the first |  | understand the class of any status code, as indicated by the first |
| digit, and treat an unrecognized status code as being equivalent to |  | digit, and treat an unrecognized status code as being equivalent to |
| the x00 status code of that class, with the exception that a response |  | the x00 status code of that class, with the exception that a |
| with an unrecognized status code MUST NOT be cached. |  | recipient MUST NOT cache a response with an unrecognized status code. |
| For example, if an unrecognized status code of 471 is received by a |  | For example, if an unrecognized status code of 471 is received by a |
| client, the client can assume that there was something wrong with its |  | client, the client can assume that there was something wrong with its |
| request and treat the response as if it had received a 400 status |  | request and treat the response as if it had received a 400 status |
| code. The response message will usually contain a representation |  | code. The response message will usually contain a representation |
| that explains the status. |  | that explains the status. |
| The first digit of the status-code defines the class of response. |  | The first digit of the status-code defines the class of response. |
| The last two digits do not have any categorization role. There are 5 |  | The last two digits do not have any categorization role. There are 5 |
| values for the first digit: |  | values for the first digit: |
| skipping to change at page 48, line 5 |  | skipping to change at page 48, line 6 |
| o 5xx (Server Error): The server failed to fulfill an apparently |  | o 5xx (Server Error): The server failed to fulfill an apparently |
| valid request |  | valid request |
| 6.1. Overview of Status Codes |  | 6.1. Overview of Status Codes |
| The status codes listed below are defined in this specification, |  | The status codes listed below are defined in this specification, |
| Section 4 of [Part4], Section 4 of [Part5], and Section 3 of [Part7]. |  | Section 4 of [Part4], Section 4 of [Part5], and Section 3 of [Part7]. |
| The reason phrases listed here are only recommendations -- they can |  | The reason phrases listed here are only recommendations -- they can |
| be replaced by local equivalents without affecting the protocol. |  | be replaced by local equivalents without affecting the protocol. |
|  |  | Responses with status codes that are defined as cacheable by default |
|  |  | (e.g., 200, 203, 206, 300, 301, and 410 in this specification) can be |
|  |  | reused by a cache with heuristic expiration unless otherwise |
|  |  | indicated by the method definition or explicit cache controls |
|  |  | [Part6]; all other status codes are not cacheable by default. |
| +------+-------------------------------+------------------------+ |  | +------+-------------------------------+------------------------+ |
| | code | reason-phrase | Defined in... | |  | | code | reason-phrase | Defined in... | |
| +------+-------------------------------+------------------------+ |  | +------+-------------------------------+------------------------+ |
| | 100 | Continue | Section 6.2.1 | |  | | 100 | Continue | Section 6.2.1 | |
| | 101 | Switching Protocols | Section 6.2.2 | |  | | 101 | Switching Protocols | Section 6.2.2 | |
| | 200 | OK | Section 6.3.1 | |  | | 200 | OK | Section 6.3.1 | |
| | 201 | Created | Section 6.3.2 | |  | | 201 | Created | Section 6.3.2 | |
| | 202 | Accepted | Section 6.3.3 | |  | | 202 | Accepted | Section 6.3.3 | |
| | 203 | Non-Authoritative Information | Section 6.3.4 | |  | | 203 | Non-Authoritative Information | Section 6.3.4 | |
| | 204 | No Content | Section 6.3.5 | |  | | 204 | No Content | Section 6.3.5 | |
| skipping to change at page 48, line 52 |  | skipping to change at page 49, line 52 |
| | 426 | Upgrade Required | Section 6.5.15 | |  | | 426 | Upgrade Required | Section 6.5.15 | |
| | 500 | Internal Server Error | Section 6.6.1 | |  | | 500 | Internal Server Error | Section 6.6.1 | |
| | 501 | Not Implemented | Section 6.6.2 | |  | | 501 | Not Implemented | Section 6.6.2 | |
| | 502 | Bad Gateway | Section 6.6.3 | |  | | 502 | Bad Gateway | Section 6.6.3 | |
| | 503 | Service Unavailable | Section 6.6.4 | |  | | 503 | Service Unavailable | Section 6.6.4 | |
| | 504 | Gateway Time-out | Section 6.6.5 | |  | | 504 | Gateway Time-out | Section 6.6.5 | |
| | 505 | HTTP Version Not Supported | Section 6.6.6 | |  | | 505 | HTTP Version Not Supported | Section 6.6.6 | |
| +------+-------------------------------+------------------------+ |  | +------+-------------------------------+------------------------+ |
| Note that this list is not exhaustive -- it does not include |  | Note that this list is not exhaustive -- it does not include |
| extension status codes defined in other specifications. |  | extension status codes defined in other specifications. The complete |
|  |  | list of status codes is maintained by IANA. See Section 8.2 for |
| Responses with status codes that are defined as cacheable by default |  | details. |
| (e.g., 200, 203, 206, 300, 301, and 410 in this specification) can be |  |  |
| reused by a cache with heuristic expiration unless otherwise |  |  |
| indicated by the method definition or explicit cache controls |  |  |
| [Part6]; all other status codes are not cacheable by default. |  |  |
| 6.2. Informational 1xx |  | 6.2. Informational 1xx |
| The 1xx (Informational) class of status code indicates an interim |  | The 1xx (Informational) class of status code indicates an interim |
| response for communicating connection status or request progress |  | response for communicating connection status or request progress |
| prior to completing the requested action and sending a final |  | prior to completing the requested action and sending a final |
| response. All 1xx responses consist of only the status-line and |  | response. All 1xx responses consist of only the status-line and |
| optional header fields, and thus are terminated by the empty line at |  | optional header fields, and thus are terminated by the empty line at |
| the end of the header block. Since HTTP/1.0 did not define any 1xx |  | the end of the header section. Since HTTP/1.0 did not define any 1xx |
| status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 |  | status codes, a server MUST NOT send a 1xx response to an HTTP/1.0 |
| client except under experimental conditions. |  | client. |
| A client MUST be prepared to accept one or more 1xx status responses |  | A client MUST be able to parse one or more 1xx responses received |
| prior to a final response, even if the client does not expect one. A |  | prior to a final response, even if the client does not expect one. A |
| user agent MAY ignore unexpected 1xx status responses. |  | user agent MAY ignore unexpected 1xx responses. |
| Proxies MUST forward 1xx responses, unless the connection between the |  | A proxy MUST forward 1xx responses unless the proxy itself requested |
| proxy and its client has been closed, or unless the proxy itself |  | the generation of the 1xx response. For example, if a proxy adds an |
| requested the generation of the 1xx response. For example, if a |  | "Expect: 100-continue" field when it forwards a request, then it need |
| proxy adds an "Expect: 100-continue" field when it forwards a |  | not forward the corresponding 100 (Continue) response(s). |
| request, then it need not forward the corresponding 100 (Continue) |  |  |
| response(s). |  |  |
| 6.2.1. 100 Continue |  | 6.2.1. 100 Continue |
| The 100 (Continue) status code indicates that the initial part of a |  | The 100 (Continue) status code indicates that the initial part of a |
| request has been received and has not yet been rejected by the |  | request has been received and has not yet been rejected by the |
| server. The server intends to send a final response after the |  | server. The server intends to send a final response after the |
| request has been fully received and acted upon. |  | request has been fully received and acted upon. |
| When the request contains an Expect header field that includes a 100- |  | When the request contains an Expect header field that includes a 100- |
| continue expectation, the 100 response indicates that the server |  | continue expectation, the 100 response indicates that the server |
| wishes to receive the request payload body, as described in |  | wishes to receive the request payload body, as described in |
| Section 5.1.1.1. The client ought to continue sending the request |  | Section 5.1.1. The client ought to continue sending the request and |
| and discard the 100 response. |  | discard the 100 response. |
| If the request did not contain an Expect header field containing the |  | If the request did not contain an Expect header field containing the |
| 100-continue expectation, the client can simply discard this interim |  | 100-continue expectation, the client can simply discard this interim |
| response. |  | response. |
| 6.2.2. 101 Switching Protocols |  | 6.2.2. 101 Switching Protocols |
| The 101 (Switching Protocols) status code indicates that the server |  | The 101 (Switching Protocols) status code indicates that the server |
| understands and is willing to comply with the client's request, via |  | understands and is willing to comply with the client's request, via |
| the Upgrade header field (Section 6.7 of [Part1]), for a change in |  | the Upgrade header field (Section 6.7 of [Part1]), for a change in |
| skipping to change at page 51, line 5 |  | skipping to change at page 51, line 45 |
| OPTIONS a representation of the communications options; |  | OPTIONS a representation of the communications options; |
| TRACE a representation of the request message as received by the end |  | TRACE a representation of the request message as received by the end |
| server. |  | server. |
| Aside from responses to CONNECT, a 200 response always has a payload, |  | Aside from responses to CONNECT, a 200 response always has a payload, |
| though an origin server MAY generate a payload body of zero length. |  | though an origin server MAY generate a payload body of zero length. |
| If no payload is desired, an origin server ought to send 204 (No |  | If no payload is desired, an origin server ought to send 204 (No |
| Content) instead. For CONNECT, no payload is allowed because the |  | Content) instead. For CONNECT, no payload is allowed because the |
| successful result is a tunnel, which begins immediately after the 200 |  | successful result is a tunnel, which begins immediately after the 200 |
| response header block. |  | response header section. |
| A 200 response is cacheable unless otherwise indicated by the method |  | A 200 response is cacheable unless otherwise indicated by the method |
| definition or explicit cache controls (see Section 4.1.2 of [Part6]). |  | definition or explicit cache controls (see Section 4.2.2 of [Part6]). |
| 6.3.2. 201 Created |  | 6.3.2. 201 Created |
| The 201 (Created) status code indicates that the request has been |  | The 201 (Created) status code indicates that the request has been |
| fulfilled and has resulted in one or more new resources being |  | fulfilled and has resulted in one or more new resources being |
| created. The primary resource created by the request is identified |  | created. The primary resource created by the request is identified |
| by either a Location header field in the response or, if no Location |  | by either a Location header field in the response or, if no Location |
| field is received, by the effective request URI. |  | field is received, by the effective request URI. |
| The 201 response payload typically describes and links to the |  | The 201 response payload typically describes and links to the |
| skipping to change at page 52, line 6 |  | skipping to change at page 52, line 49 |
| the request was successful but the enclosed payload has been modified |  | the request was successful but the enclosed payload has been modified |
| from that of the origin server's 200 (OK) response by a transforming |  | from that of the origin server's 200 (OK) response by a transforming |
| proxy (Section 5.7.2 of [Part1]). This status code allows the proxy |  | proxy (Section 5.7.2 of [Part1]). This status code allows the proxy |
| to notify recipients when a transformation has been applied, since |  | to notify recipients when a transformation has been applied, since |
| that knowledge might impact later decisions regarding the content. |  | that knowledge might impact later decisions regarding the content. |
| For example, future cache validation requests for the content might |  | For example, future cache validation requests for the content might |
| only be applicable along the same request path (through the same |  | only be applicable along the same request path (through the same |
| proxies). |  | proxies). |
| The 203 response is similar to the Warning code of 214 Transformation |  | The 203 response is similar to the Warning code of 214 Transformation |
| Applied (Section 7.5 of [Part6]), which has the advantage of being |  | Applied (Section 5.5 of [Part6]), which has the advantage of being |
| applicable to responses with any status code. |  | applicable to responses with any status code. |
| A 203 response is cacheable unless otherwise indicated by the method |  | A 203 response is cacheable unless otherwise indicated by the method |
| definition or explicit cache controls (see Section 4.1.2 of [Part6]). |  | definition or explicit cache controls (see Section 4.2.2 of [Part6]). |
| 6.3.5. 204 No Content |  | 6.3.5. 204 No Content |
| The 204 (No Content) status code indicates that the server has |  | The 204 (No Content) status code indicates that the server has |
| successfully fulfilled the request and that there is no additional |  | successfully fulfilled the request and that there is no additional |
| content to send in the response payload body. Metadata in the |  | content to send in the response payload body. Metadata in the |
| response header fields refer to the target resource and its selected |  | response header fields refer to the target resource and its selected |
| representation after the requested action was applied. |  | representation after the requested action was applied. |
| For example, if a 204 status code is received in response to a PUT |  | For example, if a 204 status code is received in response to a PUT |
| skipping to change at page 52, line 43 |  | skipping to change at page 53, line 37 |
| For example, a 204 status code is commonly used with document editing |  | For example, a 204 status code is commonly used with document editing |
| interfaces corresponding to a "save" action, such that the document |  | interfaces corresponding to a "save" action, such that the document |
| being saved remains available to the user for editing. It is also |  | being saved remains available to the user for editing. It is also |
| frequently used with interfaces that expect automated data transfers |  | frequently used with interfaces that expect automated data transfers |
| to be prevalent, such as within distributed version control systems. |  | to be prevalent, such as within distributed version control systems. |
| A 204 response is terminated by the first empty line after the header |  | A 204 response is terminated by the first empty line after the header |
| fields because it cannot contain a message body. |  | fields because it cannot contain a message body. |
| A 204 response is cacheable unless otherwise indicated by the method |  | A 204 response is cacheable unless otherwise indicated by the method |
| definition or explicit cache controls (see Section 4.1.2 of [Part6]). |  | definition or explicit cache controls (see Section 4.2.2 of [Part6]). |
| 6.3.6. 205 Reset Content |  | 6.3.6. 205 Reset Content |
| The 205 (Reset Content) status code indicates that the server has |  | The 205 (Reset Content) status code indicates that the server has |
| fulfilled the request and desires that the user agent reset the |  | fulfilled the request and desires that the user agent reset the |
| "document view", which caused the request to be sent, to its original |  | "document view", which caused the request to be sent, to its original |
| state as received from the origin server. |  | state as received from the origin server. |
| This response is intended to support a common data entry use case |  | This response is intended to support a common data entry use case |
| where the user receives content that supports data entry (a form, |  | where the user receives content that supports data entry (a form, |
| notepad, canvas, etc.), enters or manipulates data in that space, |  | notepad, canvas, etc.), enters or manipulates data in that space, |
| causes the entered data to be submitted in a request, and then the |  | causes the entered data to be submitted in a request, and then the |
| data entry mechanism is reset for the next entry so that the user can |  | data entry mechanism is reset for the next entry so that the user can |
| easily initiate another input action. |  | easily initiate another input action. |
| Since the 205 status code implies that no additional content will be |  | Since the 205 status code implies that no additional content will be |
| provided in the payload, the server MUST send a message body of zero |  | provided, a server MUST NOT generate a payload in a 205 response. In |
| length. In other words, the server MUST send a "Content-Length: 0" |  | other words, a server MUST do one of the following for a 205 |
| field in a 205 response or close the connection immediately after |  | response: a) indicate a zero-length body for the response by |
| sending the blank line terminating the header section. |  | including a Content-Length header field with a value of 0; b) |
|  |  | indicate a zero-length payload for the response by including a |
|  |  | Transfer-Encoding header field with a value of chunked and a message |
|  |  | body consisting of a single chunk of zero-length; or, c) close the |
|  |  | connection immediately after sending the blank line terminating the |
|  |  | header section. |
| 6.4. Redirection 3xx |  | 6.4. Redirection 3xx |
| The 3xx (Redirection) class of status code indicates that further |  | The 3xx (Redirection) class of status code indicates that further |
| action needs to be taken by the user agent in order to fulfill the |  | action needs to be taken by the user agent in order to fulfill the |
| request. If a Location header field (Section 7.1.2) is provided, the |  | request. If a Location header field (Section 7.1.2) is provided, the |
| user agent MAY automatically redirect its request to the URI |  | user agent MAY automatically redirect its request to the URI |
| referenced by the Location field value, even if the specific status |  | referenced by the Location field value, even if the specific status |
| code is not understood. Automatic redirection needs to done with |  | code is not understood. Automatic redirection needs to done with |
| care for methods not known to be safe, as defined in Section 4.2.1, |  | care for methods not known to be safe, as defined in Section 4.2.1, |
| skipping to change at page 54, line 12 |  | skipping to change at page 55, line 11 |
| originally defined the former semantics for 301 and 302 (to match |  | originally defined the former semantics for 301 and 302 (to match |
| its original implementation at CERN), and defined 303 (See Other) |  | its original implementation at CERN), and defined 303 (See Other) |
| to match the latter semantics, prevailing practice gradually |  | to match the latter semantics, prevailing practice gradually |
| converged on the latter semantics for 301 and 302 as well. The |  | converged on the latter semantics for 301 and 302 as well. The |
| first revision of HTTP/1.1 added 307 (Temporary Redirect) to |  | first revision of HTTP/1.1 added 307 (Temporary Redirect) to |
| indicate the former semantics without being impacted by divergent |  | indicate the former semantics without being impacted by divergent |
| practice. Over 10 years later, most user agents still do method |  | practice. Over 10 years later, most user agents still do method |
| rewriting for 301 and 302; therefore, this specification makes |  | rewriting for 301 and 302; therefore, this specification makes |
| that behavior conformant when the original request is POST. |  | that behavior conformant when the original request is POST. |
| Clients SHOULD detect and intervene in cyclical redirections (i.e., |  | A client SHOULD detect and intervene in cyclical redirections (i.e., |
| "infinite" redirection loops). |  | "infinite" redirection loops). |
| Note: An earlier version of this specification recommended a |  | Note: An earlier version of this specification recommended a |
| maximum of five redirections ([RFC2068], Section 10.3). Content |  | maximum of five redirections ([RFC2068], Section 10.3). Content |
| developers need to be aware that some clients might implement such |  | developers need to be aware that some clients might implement such |
| a fixed limitation. |  | a fixed limitation. |
| 6.4.1. 300 Multiple Choices |  | 6.4.1. 300 Multiple Choices |
| The 300 (Multiple Choices) status code indicates that the target |  | The 300 (Multiple Choices) status code indicates that the target |
| skipping to change at page 54, line 45 |  | skipping to change at page 55, line 44 |
| For request methods other than HEAD, the server SHOULD generate a |  | For request methods other than HEAD, the server SHOULD generate a |
| payload in the 300 response containing a list of representation |  | payload in the 300 response containing a list of representation |
| metadata and URI reference(s) from which the user or user agent can |  | metadata and URI reference(s) from which the user or user agent can |
| choose the one most preferred. The user agent MAY make a selection |  | choose the one most preferred. The user agent MAY make a selection |
| from that list automatically, depending upon the list format, but |  | from that list automatically, depending upon the list format, but |
| this specification does not define a standard for such automatic |  | this specification does not define a standard for such automatic |
| selection. |  | selection. |
| A 300 response is cacheable unless otherwise indicated by the method |  | A 300 response is cacheable unless otherwise indicated by the method |
| definition or explicit cache controls (see Section 4.1.2 of [Part6]). |  | definition or explicit cache controls (see Section 4.2.2 of [Part6]). |
| Note: The original proposal for 300 defined the URI header field |  | Note: The original proposal for 300 defined the URI header field |
| as providing a list of alternative representations, such that it |  | as providing a list of alternative representations, such that it |
| would be usable for 200, 300, and 406 responses and be transferred |  | would be usable for 200, 300, and 406 responses and be transferred |
| in responses to the HEAD method. However, lack of deployment and |  | in responses to the HEAD method. However, lack of deployment and |
| disagreement over syntax led to both URI and Alternates (a |  | disagreement over syntax led to both URI and Alternates (a |
| subsequent proposal) being dropped from this specification. It is |  | subsequent proposal) being dropped from this specification. It is |
| possible to communicate the list using a set of Link header fields |  | possible to communicate the list using a set of Link header fields |
| [RFC5988], each with a relationship of "alternate", though |  | [RFC5988], each with a relationship of "alternate", though |
| deployment is a chicken-and-egg problem. |  | deployment is a chicken-and-egg problem. |
| skipping to change at page 55, line 24 |  | skipping to change at page 56, line 23 |
| Clients with link editing capabilities ought to automatically re-link |  | Clients with link editing capabilities ought to automatically re-link |
| references to the effective request URI to one or more of the new |  | references to the effective request URI to one or more of the new |
| references sent by the server, where possible. |  | references sent by the server, where possible. |
| 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 payload usually contains a short |  | redirection. The server's response payload 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 historic reasons, user agents MAY change the request |  | Note: For historic reasons, a user agent MAY change the request |
| method from POST to GET for the subsequent request. If this |  | method from POST to GET for the subsequent request. If this |
| behavior is undesired, status code 307 (Temporary Redirect) can be |  | behavior is undesired, the 307 (Temporary Redirect) status code |
| used instead. |  | can be used instead. |
| A 301 response is cacheable unless otherwise indicated by the method |  | A 301 response is cacheable unless otherwise indicated by the method |
| definition or explicit cache controls (see Section 4.1.2 of [Part6]). |  | definition or explicit cache controls (see Section 4.2.2 of [Part6]). |
| 6.4.3. 302 Found |  | 6.4.3. 302 Found |
| The 302 (Found) status code indicates that the target resource |  | The 302 (Found) status code indicates that the target resource |
| resides temporarily under a different URI. Since the redirection |  | resides temporarily under a different URI. Since the redirection |
| might be altered on occasion, the client ought to continue to use the |  | might be altered on occasion, the client ought to continue to use the |
| effective request URI for future requests. |  | effective request URI for future requests. |
| The server SHOULD generate a Location header field in the response |  | The server SHOULD generate a Location header field in the response |
| 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 payload usually contains a short hypertext note with a |  | response payload usually contains a short hypertext note with a |
| hyperlink to the different URI(s). |  | hyperlink to the different URI(s). |
| Note: For historic reasons, user agents MAY change the request |  | Note: For historic reasons, a user agent MAY change the request |
| method from POST to GET for the subsequent request. If this |  | method from POST to GET for the subsequent request. If this |
| behavior is undesired, status code 307 (Temporary Redirect) can be |  | behavior is undesired, the 307 (Temporary Redirect) status code |
| used instead. |  | can be used instead. |
| 6.4.4. 303 See Other |  | 6.4.4. 303 See Other |
| The 303 (See Other) status code indicates that the server is |  | The 303 (See Other) status code indicates that the server is |
| redirecting the user agent to a different resource, as indicated by a |  | redirecting the user agent to a different resource, as indicated by a |
| URI in the Location header field, that is intended to provide an |  | URI in the Location header field, that is intended to provide an |
| indirect response to the original request. In order to satisfy the |  | indirect response to the original request. In order to satisfy the |
| original request, a user agent ought to perform a retrieval request |  | original request, a user agent ought to perform a retrieval request |
| using the Location URI (a GET or HEAD request if using HTTP), which |  | using the Location URI (a GET or HEAD request if using HTTP), which |
| can itself be redirected further, and present the eventual result as |  | can itself be redirected further, and present the eventual result as |
| skipping to change at page 57, line 38 |  | skipping to change at page 58, line 38 |
| The 4xx (Client Error) class of status code indicates that the client |  | The 4xx (Client Error) class of status code indicates that the client |
| seems to have erred. Except when responding to a HEAD request, the |  | seems to have erred. Except when responding to a HEAD request, the |
| server SHOULD send a representation containing an explanation of the |  | server SHOULD send a representation containing an explanation of the |
| error situation, and whether it is a temporary or permanent |  | error situation, and whether it is a temporary or permanent |
| condition. These status codes are applicable to any request method. |  | condition. These status codes are applicable to any request method. |
| User agents SHOULD display any included representation to the user. |  | User agents SHOULD display any included representation to the user. |
| 6.5.1. 400 Bad Request |  | 6.5.1. 400 Bad Request |
| The 400 (Bad Request) status code indicates that the server cannot or |  | The 400 (Bad Request) status code indicates that the server cannot or |
| will not process the request because the received syntax is invalid, |  | will not process the request due to something which is perceived to |
| nonsensical, or exceeds some limitation on what the server is willing |  | be a client error (e.g., malformed request syntax, invalid request |
| to process. |  | message framing, or deceptive request routing). |
| 6.5.2. 402 Payment Required |  | 6.5.2. 402 Payment Required |
| The 402 (Payment Required) status code is reserved for future use. |  | The 402 (Payment Required) status code is reserved for future use. |
| 6.5.3. 403 Forbidden |  | 6.5.3. 403 Forbidden |
| The 403 (Forbidden) status code indicates that the server understood |  | The 403 (Forbidden) status code indicates that the server understood |
| the request but refuses to authorize it. A server that wishes to |  | the request but refuses to authorize it. A server that wishes to |
| make public why the request has been forbidden can describe that |  | make public why the request has been forbidden can describe that |
| reason in the response payload (if any). |  | reason in the response payload (if any). |
| If authentication credentials were provided in the request, the |  | If authentication credentials were provided in the request, the |
| server considers them insufficient to grant access. The client |  | server considers them insufficient to grant access. The client |
| SHOULD NOT repeat the request with the same credentials. The client |  | SHOULD NOT automatically repeat the request with the same |
| MAY repeat the request with new or different credentials. However, a |  | credentials. The client MAY repeat the request with new or different |
| request might be forbidden for reasons unrelated to the credentials. |  | credentials. However, a request might be forbidden for reasons |
|  |  | unrelated to the credentials. |
| An origin server that wishes to "hide" the current existence of a |  | An origin server that wishes to "hide" the current existence of a |
| forbidden target resource MAY instead respond with a status code of |  | forbidden target resource MAY instead respond with a status code of |
| 404 (Not Found). |  | 404 (Not Found). |
| 6.5.4. 404 Not Found |  | 6.5.4. 404 Not Found |
| The 404 (Not Found) status code indicates that the origin server did |  | The 404 (Not Found) status code indicates that the origin server did |
| not find a current representation for the target resource or is not |  | not find a current representation for the target resource or is not |
| willing to disclose that one exists. A 404 status does not indicate |  | willing to disclose that one exists. A 404 status code does not |
| whether this lack of representation is temporary or permanent; the |  | indicate whether this lack of representation is temporary or |
| 410 (Gone) status code is preferred over 404 if the origin server |  | permanent; the 410 (Gone) status code is preferred over 404 if the |
| knows, presumably through some configurable means, that the condition |  | origin server knows, presumably through some configurable means, that |
| is likely to be permanent. |  | the condition is likely to be permanent. |
| A 404 response is cacheable unless otherwise indicated by the method |  | A 404 response is cacheable unless otherwise indicated by the method |
| definition or explicit cache controls (see Section 4.1.2 of [Part6]). |  | definition or explicit cache controls (see Section 4.2.2 of [Part6]). |
| 6.5.5. 405 Method Not Allowed |  | 6.5.5. 405 Method Not Allowed |
| The 405 (Method Not Allowed) status code indicates that the method |  | The 405 (Method Not Allowed) status code indicates that the method |
| specified in the request-line is known by the origin server but not |  | received in the request-line is known by the origin server but not |
| supported by the target resource. The origin server MUST generate an |  | supported by the target resource. The origin server MUST generate an |
| Allow header field in a 405 response containing a list of the target |  | Allow header field in a 405 response containing a list of the target |
| resource's currently supported methods. |  | resource's currently supported methods. |
| A 405 response is cacheable unless otherwise indicated by the method |  | A 405 response is cacheable unless otherwise indicated by the method |
| definition or explicit cache controls (see Section 4.1.2 of [Part6]). |  | definition or explicit cache controls (see Section 4.2.2 of [Part6]). |
| 6.5.6. 406 Not Acceptable |  | 6.5.6. 406 Not Acceptable |
| The 406 (Not Acceptable) status code indicates that the target |  | The 406 (Not Acceptable) status code indicates that the target |
| resource does not have a current representation that would be |  | resource does not have a current representation that would be |
| acceptable to the user agent, according to the proactive negotiation |  | acceptable to the user agent, according to the proactive negotiation |
| header fields received in the request (Section 5.3), and the server |  | header fields received in the request (Section 5.3), and the server |
| is unwilling to supply a default representation. |  | is unwilling to supply a default representation. |
| The server SHOULD generate a payload containing a list of available |  | The server SHOULD generate a payload containing a list of available |
| skipping to change at page 59, line 19 |  | skipping to change at page 60, line 20 |
| not receive a complete request message within the time that it was |  | not receive a complete request message within the time that it was |
| prepared to wait. A server SHOULD send the close connection option |  | prepared to wait. A server SHOULD send the close connection option |
| (Section 6.1 of [Part1]) in the response, since 408 implies that the |  | (Section 6.1 of [Part1]) in the response, since 408 implies that the |
| server has decided to close the connection rather than continue |  | server has decided to close the connection rather than continue |
| waiting. If the client has an outstanding request in transit, the |  | waiting. If the client has an outstanding request in transit, the |
| client MAY repeat that request on a new connection. |  | client MAY repeat that request on a new connection. |
| 6.5.8. 409 Conflict |  | 6.5.8. 409 Conflict |
| The 409 (Conflict) status code indicates that the request could not |  | The 409 (Conflict) status code indicates that the request could not |
| be completed due to a conflict with the current state of the |  | be completed due to a conflict with the current state of the target |
| resource. This code is used in situations where the user might be |  | resource. This code is used in situations where the user might be |
| able to resolve the conflict and resubmit the request. The server |  | able to resolve the conflict and resubmit the request. The server |
| SHOULD generate a payload that includes enough information for a user |  | SHOULD generate a payload that includes enough information for a user |
| to recognize the source of the conflict. |  | to recognize the source of the conflict. |
| Conflicts are most likely to occur in response to a PUT request. For |  | Conflicts are most likely to occur in response to a PUT request. For |
| example, if versioning were being used and the representation being |  | example, if versioning were being used and the representation being |
| PUT included changes to a resource that conflict with those made by |  | PUT included changes to a resource that conflict with those made by |
| an earlier (third-party) request, the origin server might use a 409 |  | an earlier (third-party) request, the origin server might use a 409 |
| response to indicate that it can't complete the request. In this |  | response to indicate that it can't complete the request. In this |
| skipping to change at page 60, line 6 |  | skipping to change at page 61, line 6 |
| maintenance by notifying the recipient that the resource is |  | maintenance by notifying the recipient that the resource is |
| intentionally unavailable and that the server owners desire that |  | intentionally unavailable and that the server owners desire that |
| remote links to that resource be removed. Such an event is common |  | remote links to that resource be removed. Such an event is common |
| for limited-time, promotional services and for resources belonging to |  | for limited-time, promotional services and for resources belonging to |
| individuals no longer associated with the origin server's site. It |  | individuals no longer associated with the origin server's site. It |
| is not necessary to mark all permanently unavailable resources as |  | is not necessary to mark all permanently unavailable resources as |
| "gone" or to keep the mark for any length of time -- that is left to |  | "gone" or to keep the mark for any length of time -- that is left to |
| the discretion of the server owner. |  | the discretion of the server owner. |
| A 410 response is cacheable unless otherwise indicated by the method |  | A 410 response is cacheable unless otherwise indicated by the method |
| definition or explicit cache controls (see Section 4.1.2 of [Part6]). |  | definition or explicit cache controls (see Section 4.2.2 of [Part6]). |
| 6.5.10. 411 Length Required |  | 6.5.10. 411 Length Required |
| The 411 (Length Required) status code indicates that the server |  | The 411 (Length Required) status code indicates that the server |
| refuses to accept the request without a defined Content-Length |  | refuses to accept the request without a defined Content-Length |
| (Section 3.3.2 of [Part1]). The client MAY repeat the request if it |  | (Section 3.3.2 of [Part1]). The client MAY repeat the request if it |
| adds a valid Content-Length header field containing the length of the |  | adds a valid Content-Length header field containing the length of the |
| message body in the request message. |  | message body in the request message. |
| 6.5.11. 413 Payload Too Large |  | 6.5.11. 413 Payload Too Large |
| skipping to change at page 60, line 40 |  | skipping to change at page 61, line 40 |
| refusing to service the request because the request-target (Section |  | refusing to service the request because the request-target (Section |
| 5.3 of [Part1]) is longer than the server is willing to interpret. |  | 5.3 of [Part1]) is longer than the server is willing to interpret. |
| This rare condition is only likely to occur when a client has |  | This rare condition is only likely to occur when a client has |
| improperly converted a POST request to a GET request with long query |  | improperly converted a POST request to a GET request with long query |
| information, when the client has descended into a "black hole" of |  | information, when the client has descended into a "black hole" of |
| redirection (e.g., a redirected URI prefix that points to a suffix of |  | redirection (e.g., a redirected URI prefix that points to a suffix of |
| itself), or when the server is under attack by a client attempting to |  | itself), or when the server is under attack by a client attempting to |
| exploit potential security holes. |  | exploit potential security holes. |
| A 414 response is cacheable unless otherwise indicated by the method |  | A 414 response is cacheable unless otherwise indicated by the method |
| definition or explicit cache controls (see Section 4.1.2 of [Part6]). |  | definition or explicit cache controls (see Section 4.2.2 of [Part6]). |
| 6.5.13. 415 Unsupported Media Type |  | 6.5.13. 415 Unsupported Media Type |
| The 415 (Unsupported Media Type) status code indicates that the |  | The 415 (Unsupported Media Type) status code indicates that the |
| origin server is refusing to service the request because the payload |  | origin server is refusing to service the request because the payload |
| is in a format not supported by the target resource for this method. |  | is in a format not supported by this method on the target resource. |
| The format problem might be due to the request's indicated Content- |  | The format problem might be due to the request's indicated Content- |
| Type or Content-Encoding, or as a result of inspecting the data |  | Type or Content-Encoding, or as a result of inspecting the data |
| directly. |  | directly. |
| 6.5.14. 417 Expectation Failed |  | 6.5.14. 417 Expectation Failed |
| The 417 (Expectation Failed) status code indicates that the |  | The 417 (Expectation Failed) status code indicates that the |
| expectation given in the request's Expect header field |  | expectation given in the request's Expect header field |
| (Section 5.1.1) could not be met by at least one of the inbound |  | (Section 5.1.1) could not be met by at least one of the inbound |
| servers. |  | servers. |
| skipping to change at page 61, line 38 |  | skipping to change at page 62, line 38 |
| This service requires use of the HTTP/3.0 protocol. |  | This service requires use of the HTTP/3.0 protocol. |
| 6.6. Server Error 5xx |  | 6.6. Server Error 5xx |
| The 5xx (Server Error) class of status code indicates that the server |  | The 5xx (Server Error) class of status code indicates that the server |
| is aware that it has erred or is incapable of performing the |  | is aware that it has erred or is incapable of performing the |
| requested method. Except when responding to a HEAD request, the |  | requested method. Except when responding to a HEAD request, the |
| server SHOULD send a representation containing an explanation of the |  | server SHOULD send a representation containing an explanation of the |
| error situation, and whether it is a temporary or permanent |  | error situation, and whether it is a temporary or permanent |
| condition. User agents SHOULD display any included representation to |  | condition. A user agent SHOULD display any included representation |
| the user. These response codes are applicable to any request method. |  | to the user. These response codes are applicable to any request |
|  |  | method. |
| 6.6.1. 500 Internal Server Error |  | 6.6.1. 500 Internal Server Error |
| The 500 (Internal Server Error) status code indicates that the server |  | The 500 (Internal Server Error) status code indicates that the server |
| encountered an unexpected condition that prevented it from fulfilling |  | encountered an unexpected condition that prevented it from fulfilling |
| the request. |  | the request. |
| 6.6.2. 501 Not Implemented |  | 6.6.2. 501 Not Implemented |
| The 501 (Not Implemented) status code indicates that the server does |  | The 501 (Not Implemented) status code indicates that the server does |
| not support the functionality required to fulfill the request. This |  | not support the functionality required to fulfill the request. This |
| is the appropriate response when the server does not recognize the |  | is the appropriate response when the server does not recognize the |
| request method and is not capable of supporting it for any resource. |  | request method and is not capable of supporting it for any resource. |
| A 501 response is cacheable unless otherwise indicated by the method |  | A 501 response is cacheable unless otherwise indicated by the method |
| definition or explicit cache controls (see Section 4.1.2 of [Part6]). |  | definition or explicit cache controls (see Section 4.2.2 of [Part6]). |
| 6.6.3. 502 Bad Gateway |  | 6.6.3. 502 Bad Gateway |
| The 502 (Bad Gateway) status code indicates that the server, while |  | The 502 (Bad Gateway) status code indicates that the server, while |
| acting as a gateway or proxy, received an invalid response from an |  | acting as a gateway or proxy, received an invalid response from an |
| inbound server it accessed while attempting to fulfill the request. |  | inbound server it accessed while attempting to fulfill the request. |
| 6.6.4. 503 Service Unavailable |  | 6.6.4. 503 Service Unavailable |
| The 503 (Service Unavailable) status code indicates that the server |  | The 503 (Service Unavailable) status code indicates that the server |
| skipping to change at page 63, line 18 |  | skipping to change at page 64, line 19 |
| 7.1. Control Data |  | 7.1. Control Data |
| Response header fields can supply control data that supplements the |  | Response header fields can supply control data that supplements the |
| status code, directs caching, or instructs the client where to go |  | status code, directs caching, or instructs the client where to go |
| next. |  | next. |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| | Age | Section 7.1 of [Part6] | |  | | Age | Section 5.1 of [Part6] | |
| | Cache-Control | Section 7.2 of [Part6] | |  | | Cache-Control | Section 5.2 of [Part6] | |
| | Expires | Section 7.3 of [Part6] | |  | | Expires | Section 5.3 of [Part6] | |
| | Date | Section 7.1.1.2 | |  | | Date | Section 7.1.1.2 | |
| | Location | Section 7.1.2 | |  | | Location | Section 7.1.2 | |
| | Retry-After | Section 7.1.3 | |  | | Retry-After | Section 7.1.3 | |
| | Vary | Section 7.1.4 | |  | | Vary | Section 7.1.4 | |
| | Warning | Section 7.5 of [Part6] | |  | | Warning | Section 5.5 of [Part6] | |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| 7.1.1. Origination Date |  | 7.1.1. Origination Date |
| 7.1.1.1. Date/Time Formats |  | 7.1.1.1. Date/Time Formats |
| Prior to 1995, there were three different formats commonly used by |  | Prior to 1995, there were three different formats commonly used by |
| servers to communicate timestamps. For compatibility with old |  | servers to communicate timestamps. For compatibility with old |
| implementations, all three are defined here. The preferred format is |  | implementations, all three are defined here. The preferred format is |
| a fixed-length and single-zone subset of the date and time |  | a fixed-length and single-zone subset of the date and time |
| skipping to change at page 63, line 50 |  | skipping to change at page 64, line 51 |
| An example of the preferred format is |  | An example of the preferred format is |
| Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate |  | Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate |
| Examples of the two obsolete formats are |  | Examples of the two obsolete formats are |
| Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format |  | Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format |
| Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |  | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |
| A recipient that parses a timestamp value in an HTTP header field |  | A recipient that parses a timestamp value in an HTTP header field |
| MUST accept all three formats. A sender MUST generate the IMF- |  | MUST accept all three HTTP-date formats. When a sender generates a |
| fixdate format when sending an HTTP-date value in a header field. |  | header field that contains one or more timestamps defined as HTTP- |
|  |  | date, the sender MUST generate those timestamps in the IMF-fixdate |
|  |  | format. |
| An HTTP-date value represents time as an instance of Coordinated |  | An HTTP-date value represents time as an instance of Coordinated |
| Universal Time (UTC). The first two formats indicate UTC by the |  | Universal Time (UTC). The first two formats indicate UTC by the |
| three-letter abbreviation for Greenwich Mean Time, "GMT", a |  | three-letter abbreviation for Greenwich Mean Time, "GMT", a |
| predecessor of the UTC name; values in the asctime format are assumed |  | predecessor of the UTC name; values in the asctime format are assumed |
| to be in UTC. A sender that generates HTTP-date values from a local |  | to be in UTC. A sender that generates HTTP-date values from a local |
| clock ought to use NTP ([RFC1305]) or some similar protocol to |  | clock ought to use NTP ([RFC1305]) or some similar protocol to |
| synchronize its clock to UTC. |  | synchronize its clock to UTC. |
| Preferred format: |  | Preferred format: |
| skipping to change at page 65, line 32 |  | skipping to change at page 67, line 27 |
| date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) |  | date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) |
| ; e.g., Jun 2 |  | ; e.g., Jun 2 |
| HTTP-date is case sensitive. A sender MUST NOT generate additional |  | HTTP-date is case sensitive. A sender MUST NOT generate additional |
| whitespace in an HTTP-date beyond that specifically included as SP in |  | whitespace in an HTTP-date beyond that specifically included as SP in |
| the grammar. The semantics of day-name, day, month, year, and time- |  | the grammar. The semantics of day-name, day, month, year, and time- |
| of-day are the same as those defined for the Internet Message Format |  | of-day are the same as those defined for the Internet Message Format |
| constructs with the corresponding name ([RFC5322], Section 3.3). |  | constructs with the corresponding name ([RFC5322], Section 3.3). |
| Recipients of a timestamp value in rfc850-date format, which uses a |  | Recipients of a timestamp value in rfc850-date format, which uses a |
| two-digit year, SHOULD interpret a timestamp that appears to be more |  | two-digit year, MUST interpret a timestamp that appears to be more |
| than 50 years in the future as representing the most recent year in |  | than 50 years in the future as representing the most recent year in |
| the past that had the same last two digits. |  | the past that had the same last two digits. |
| Recipients of timestamp values are encouraged to be robust in parsing |  | Recipients of timestamp values are encouraged to be robust in parsing |
| timestamps unless otherwise restricted by the field definition. For |  | timestamps unless otherwise restricted by the field definition. For |
| example, messages are occasionally forwarded over HTTP from a non- |  | example, messages are occasionally forwarded over HTTP from a non- |
| HTTP source that might generate any of the date and time |  | HTTP source that might generate any of the date and time |
| specifications defined by the Internet Message Format. |  | specifications defined by the Internet Message Format. |
| Note: HTTP requirements for the date/time stamp format apply only |  | Note: HTTP requirements for the date/time stamp format apply only |
| skipping to change at page 66, line 33 |  | skipping to change at page 68, line 24 |
| An origin server MUST NOT send a Date header field if it does not |  | An origin server MUST NOT send a Date header field if it does not |
| have a clock capable of providing a reasonable approximation of the |  | have a clock capable of providing a reasonable approximation of the |
| current instance in Coordinated Universal Time. An origin server MAY |  | current instance in Coordinated Universal Time. An origin server MAY |
| send a Date header field if the response is in the 1xx |  | send a Date header field if the response is in the 1xx |
| (Informational) or 5xx (Server Error) class of status codes. An |  | (Informational) or 5xx (Server Error) class of status codes. An |
| origin server MUST send a Date header field in all other cases. |  | origin server MUST send a Date header field in all other cases. |
| A recipient with a clock that receives a response message without a |  | A recipient with a clock that receives a response message without a |
| Date header field MUST record the time it was received and append a |  | Date header field MUST record the time it was received and append a |
| corresponding Date header field to the message's header block if it |  | corresponding Date header field to the message's header section if it |
| is cached or forwarded downstream. |  | is cached or forwarded downstream. |
| A user agent MAY send a Date header field in a request, though |  | A user agent MAY send a Date header field in a request, though |
| generally will not do so unless it is believed to convey useful |  | generally will not do so unless it is believed to convey useful |
| information to the server. For example, custom applications of HTTP |  | information to the server. For example, custom applications of HTTP |
| might convey a Date if the server is expected to adjust its |  | might convey a Date if the server is expected to adjust its |
| interpretation of the user's request based on differences between the |  | interpretation of the user's request based on differences between the |
| user agent and server clocks. |  | user agent and server clocks. |
| 7.1.2. Location |  | 7.1.2. Location |
| skipping to change at page 67, line 13 |  | skipping to change at page 69, line 5 |
| The field value consists of a single URI-reference. When it has the |  | The field value consists of a single URI-reference. When it has the |
| form of a relative reference ([RFC3986], Section 4.2), the final |  | form of a relative reference ([RFC3986], Section 4.2), the final |
| value is computed by resolving it against the effective request URI |  | value is computed by resolving it against the effective request URI |
| ([RFC3986], Section 5). |  | ([RFC3986], Section 5). |
| For 201 (Created) responses, the Location value refers to the primary |  | For 201 (Created) responses, the Location value refers to the primary |
| resource created by the request. For 3xx (Redirection) responses, |  | resource created by the request. For 3xx (Redirection) responses, |
| the Location value refers to the preferred target resource for |  | the Location value refers to the preferred target resource for |
| automatically redirecting the request. |  | automatically redirecting the request. |
| When Location is provided in a 3xx (Redirection) response and the URI |  | If the Location value provided in a 3xx (Redirection) does not have a |
| reference that the user agent used to generate the request target |  | fragment component, a user agent MUST process the redirection as if |
| contains a fragment identifier, the user agent SHOULD process the |  | the value inherits the fragment component of the URI reference used |
| redirection as if the Location field value inherits the original |  | to generate the request target (i.e., the redirection inherits the |
| fragment. In other words, if the Location does not have a fragment |  | original reference's fragment, if any). |
| component, the user agent SHOULD interpret the Location reference as |  |  |
| if it had the original reference's fragment. |  |  |
| For example, a GET request generated for the URI reference |  | For example, a GET request generated for the URI reference |
| "http://www.example.org/~tim" might result in a 303 (See Other) |  | "http://www.example.org/~tim" might result in a 303 (See Other) |
| response containing the header field: |  | response containing the header field: |
| Location: /People.html#tim |  | Location: /People.html#tim |
| which suggests that the user agent redirect to |  | which suggests that the user agent redirect to |
| "http://www.example.org/People.html#tim" |  | "http://www.example.org/People.html#tim" |
| skipping to change at page 68, line 40 |  | skipping to change at page 70, line 26 |
| Two examples of its use are |  | Two examples of its use are |
| Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |  | Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |
| Retry-After: 120 |  | Retry-After: 120 |
| In the latter example, the delay is 2 minutes. |  | In the latter example, the delay is 2 minutes. |
| 7.1.4. Vary |  | 7.1.4. Vary |
| The "Vary" header field describes what parts of a request message, |  | The "Vary" header field in a response describes what parts of a |
| aside from the method, the Host header field and the request target, |  | request message, aside from the method, Host header field, and |
| might influence the origin server's process for selecting and |  | request target, might influence the origin server's process for |
| representing the response. The value consists of either a single |  | selecting and representing this response. The value consists of |
| asterisk ("*") or a list of header field names (case-insensitive). |  | either a single asterisk ("*") or a list of header field names (case- |
|  |  | insensitive). |
| Vary = "*" / 1#field-name |  | Vary = "*" / 1#field-name |
| A Vary field value of "*" signals that anything about the request |  | A Vary field value of "*" signals that anything about the request |
| might play a role in selecting the response representation, possibly |  | might play a role in selecting the response representation, possibly |
| including elements outside the message syntax (e.g., the client's |  | including elements outside the message syntax (e.g., the client's |
| network address), and thus a recipient will not be able to determine |  | network address), and thus a recipient will not be able to determine |
| whether this response is appropriate for a later request without |  | whether this response is appropriate for a later request without |
| forwarding the request to the origin server. A proxy MUST NOT |  | forwarding the request to the origin server. A proxy MUST NOT |
| generate a Vary field with a "*" value. |  | generate a Vary field with a "*" value. |
| skipping to change at page 69, line 26 |  | skipping to change at page 71, line 18 |
| indicates that the origin server might have used the request's |  | indicates that the origin server might have used the request's |
| Accept-Encoding and Accept-Language fields (or lack thereof) as |  | Accept-Encoding and Accept-Language fields (or lack thereof) as |
| determining factors while choosing the content for this response. |  | determining factors while choosing the content for this response. |
| An origin server might send Vary with a list of fields for two |  | An origin server might send Vary with a list of fields for two |
| purposes: |  | purposes: |
| 1. To inform cache recipients that they MUST NOT use this response |  | 1. To inform cache recipients that they MUST NOT use this response |
| to satisfy a later request unless the later request has the same |  | to satisfy a later request unless the later request has the same |
| values for the listed fields as the original request (Section 4.3 |  | values for the listed fields as the original request (Section 4.1 |
| of [Part6]). In other words, Vary expands the cache key required |  | of [Part6]). In other words, Vary expands the cache key required |
| to match a new request to the stored cache entry. |  | to match a new request to the stored cache entry. |
| 2. To inform user agent recipients that this response is subject to |  | 2. To inform user agent recipients that this response is subject to |
| content negotiation (Section 5.3) and that a different |  | content negotiation (Section 5.3) and that a different |
| representation might be sent in a subsequent request if |  | representation might be sent in a subsequent request if |
| additional parameters are provided in the listed header fields |  | additional parameters are provided in the listed header fields |
| (proactive negotiation). |  | (proactive negotiation). |
| An origin server SHOULD send a Vary header field when its algorithm |  | An origin server SHOULD send a Vary header field when its algorithm |
| for selecting a representation varies based on aspects of the request |  | for selecting a representation varies based on aspects of the request |
| message other than the method and request target, unless the variance |  | message other than the method and request target, unless the variance |
| cannot be crossed or the origin server has been deliberately |  | cannot be crossed or the origin server has been deliberately |
| configured to prevent cache transparency. For example, there is no |  | configured to prevent cache transparency. For example, there is no |
| need to send the Authorization field name in Vary because reuse |  | need to send the Authorization field name in Vary because reuse |
| across users is constrained by the field definition (Section 4.1 of |  | across users is constrained by the field definition (Section 4.1 of |
| [Part7]). Likewise, an origin server might use Cache-Control |  | [Part7]). Likewise, an origin server might use Cache-Control |
| directives (Section 7.2 of [Part6]) to supplant Vary if it considers |  | directives (Section 5.2 of [Part6]) to supplant Vary if it considers |
| the variance less significant than the performance cost of Vary's |  | the variance less significant than the performance cost of Vary's |
| impact on caching. |  | impact on caching. |
| 7.2. Validator Header Fields |  | 7.2. Validator Header Fields |
| Validator header fields convey metadata about the selected |  | Validator header fields convey metadata about the selected |
| representation (Section 3). In responses to safe requests, validator |  | representation (Section 3). In responses to safe requests, validator |
| fields describe the selected representation chosen by the origin |  | fields describe the selected representation chosen by the origin |
| server while handling the response. Note that, depending on the |  | server while handling the response. Note that, depending on the |
| status code semantics, the selected representation for a given |  | status code semantics, the selected representation for a given |
| skipping to change at page 77, line 23 |  | skipping to change at page 78, line 23 |
| Authors of specifications defining new fields are advised to keep the |  | Authors of specifications defining new fields are advised to keep the |
| name as short as practical and to not prefix the name with "X-" |  | name as short as practical and to not prefix the name with "X-" |
| unless the header field will never be used on the Internet. (The |  | unless the header field will never be used on the Internet. (The |
| "x-" prefix idiom has been extensively misused in practice; it was |  | "x-" prefix idiom has been extensively misused in practice; it was |
| intended to only be used as a mechanism for avoiding name collisions |  | intended to only be used as a mechanism for avoiding name collisions |
| inside proprietary software or intranet processing, since the prefix |  | inside proprietary software or intranet processing, since the prefix |
| would ensure that private names never collide with a newly registered |  | would ensure that private names never collide with a newly registered |
| Internet name.) |  | Internet name.) |
| New header field values typically have their syntax defined using |  | New header field values typically have their syntax defined using |
| ABNF ([RFC5234]), using the extension defined in Appendix B of |  | ABNF ([RFC5234]), using the extension defined in Section 7 of [Part1] |
| [Part1] as necessary, and are usually constrained to the range of |  | as necessary, and are usually constrained to the range of ASCII |
| ASCII characters. Header fields needing a greater range of |  | characters. Header fields needing a greater range of characters can |
| characters can use an encoding such as the one defined in [RFC5987]. |  | use an encoding such as the one defined in [RFC5987]. |
| Leading and trailing whitespace in raw field values is removed upon |  | Leading and trailing whitespace in raw field values is removed upon |
| field parsing (Section 3.2.4 of [Part1]). Field definitions where |  | field parsing (Section 3.2.4 of [Part1]). Field definitions where |
| leading or trailing whitespace in values is significant will have to |  | leading or trailing whitespace in values is significant will have to |
| use a container syntax such as quoted-string. |  | use a container syntax such as quoted-string. |
| Because commas (",") are used as a generic delimiter between field- |  | Because commas (",") are used as a generic delimiter between field- |
| values, they need to be treated with care if they are allowed in the |  | values, they need to be treated with care if they are allowed in the |
| field-value. Typically, components that might contain a comma are |  | field-value. Typically, components that might contain a comma are |
| protected with double-quotes using the quoted-string ABNF production |  | protected with double-quotes using the quoted-string ABNF production |
| skipping to change at page 83, line 10 |  | skipping to change at page 84, line 10 |
| cookies). Many general-purpose user agents (i.e., Web browsers) have |  | cookies). Many general-purpose user agents (i.e., Web browsers) have |
| taken steps to reduce their fingerprints. |  | taken steps to reduce their fingerprints. |
| There are a number of request header fields that might reveal |  | There are a number of request header fields that might reveal |
| information to servers that is sufficiently unique to enable |  | information to servers that is sufficiently unique to enable |
| fingerprinting. The From header field is the most obvious, though it |  | fingerprinting. The From header field is the most obvious, though it |
| is expected that From will only be sent when self-identification is |  | is expected that From will only be sent when self-identification is |
| desired by the user. Likewise, Cookie header fields are deliberately |  | desired by the user. Likewise, Cookie header fields are deliberately |
| designed to enable re-identification, so we can assume that |  | designed to enable re-identification, so we can assume that |
| fingerprinting concerns only apply to situations where cookies are |  | fingerprinting concerns only apply to situations where cookies are |
| disabled or restricted by browser configuration. |  | disabled or restricted by the user agent's configuration. |
| The User-Agent header field might contain enough information to |  | The User-Agent header field might contain enough information to |
| uniquely identify a specific device, usually when combined with other |  | uniquely identify a specific device, usually when combined with other |
| characteristics, particularly if the user agent sends excessive |  | characteristics, particularly if the user agent sends excessive |
| details about the user's system or extensions. However, the source |  | details about the user's system or extensions. However, the source |
| of unique information that is least expected by users is proactive |  | of unique information that is least expected by users is proactive |
| negotiation (Section 5.3), including the Accept, Accept-Charset, |  | negotiation (Section 5.3), including the Accept, Accept-Charset, |
| Accept-Encoding, and Accept-Language header fields. |  | Accept-Encoding, and Accept-Language header fields. |
| In addition to the fingerprinting concern, detailed use of the |  | In addition to the fingerprinting concern, detailed use of the |
| skipping to change at page 83, line 40 |  | skipping to change at page 84, line 40 |
| In environments where proxies are used to enhance privacy, user |  | In environments where proxies are used to enhance privacy, user |
| agents ought to be conservative in sending proactive negotiation |  | agents ought to be conservative in sending proactive negotiation |
| header fields. General-purpose user agents that provide a high |  | header fields. General-purpose user agents that provide a high |
| degree of header field configurability ought to inform users about |  | degree of header field configurability ought to inform users about |
| the loss of privacy that might result if too much detail is provided. |  | the loss of privacy that might result if too much detail is provided. |
| As an extreme privacy measure, proxies could filter the proactive |  | As an extreme privacy measure, proxies could filter the proactive |
| negotiation header fields in relayed requests. |  | negotiation header fields in relayed requests. |
| 10. Acknowledgments |  | 10. Acknowledgments |
| See Section 9 of [Part1]. |  | See Section 10 of [Part1]. |
| 11. References |  | 11. References |
| 11.1. Normative References |  | 11.1. Normative References |
| [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
| Transfer Protocol (HTTP/1.1): Message Syntax and |  | Transfer Protocol (HTTP/1.1): Message Syntax and |
| Routing", draft-ietf-httpbis-p1-messaging-23 (work in |  | Routing", draft-ietf-httpbis-p1-messaging-24 (work in |
| progress), July 2013. |  | progress), September 2013. |
| [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
| Transfer Protocol (HTTP/1.1): Conditional Requests", |  | Transfer Protocol (HTTP/1.1): Conditional Requests", |
| draft-ietf-httpbis-p4-conditional-23 (work in |  | draft-ietf-httpbis-p4-conditional-24 (work in |
| progress), July 2013. |  | progress), September 2013. |
| [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| "Hypertext Transfer Protocol (HTTP/1.1): Range |  | "Hypertext Transfer Protocol (HTTP/1.1): Range |
| Requests", draft-ietf-httpbis-p5-range-23 (work in |  | Requests", draft-ietf-httpbis-p5-range-24 (work in |
| progress), July 2013. |  | progress), September 2013. |
| [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |  | [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
| Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |  | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
| draft-ietf-httpbis-p6-cache-23 (work in progress), |  | draft-ietf-httpbis-p6-cache-24 (work in progress), |
| July 2013. |  | September 2013. |
| [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
| Transfer Protocol (HTTP/1.1): Authentication", |  | Transfer Protocol (HTTP/1.1): Authentication", |
| draft-ietf-httpbis-p7-auth-23 (work in progress), |  | draft-ietf-httpbis-p7-auth-24 (work in progress), |
| July 2013. |  | September 2013. |
| [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |  | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |
| Format Specification version 3.3", RFC 1950, May 1996. |  | Format Specification version 3.3", RFC 1950, May 1996. |
| [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |  | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |
| Specification version 1.3", RFC 1951, May 1996. |  | Specification version 1.3", RFC 1951, May 1996. |
| [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and |  | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and |
| G. Randers-Pehrson, "GZIP file format specification |  | G. Randers-Pehrson, "GZIP file format specification |
| version 4.3", RFC 1952, May 1996. |  | version 4.3", RFC 1952, May 1996. |
| skipping to change at page 89, line 16 |  | skipping to change at page 90, line 16 |
| that might be contained therein. |  | that might be contained therein. |
| Appendix B. Changes from RFC 2616 |  | Appendix B. Changes from RFC 2616 |
| The primary changes in this revision have been editorial in nature: |  | The primary changes in this revision have been editorial in nature: |
| extracting the messaging syntax and partitioning HTTP semantics into |  | extracting the messaging syntax and partitioning HTTP semantics into |
| separate documents for the core features, conditional requests, |  | separate documents for the core features, conditional requests, |
| partial requests, caching, and authentication. The conformance |  | partial requests, caching, and authentication. The conformance |
| language has been revised to clearly target requirements and the |  | language has been revised to clearly target requirements and the |
| terminology has been improved to distinguish payload from |  | terminology has been improved to distinguish payload from |
| representations and representations from resources. An algorithm has |  | representations and representations from resources. |
| been added for determining if a payload is associated with a specific |  |  |
| identifier (Section 3.1.4.1). |  |  |
| A new requirement has been added that semantics embedded in a URI |  | A new requirement has been added that semantics embedded in a URI |
| should be disabled when those semantics are inconsistent with the |  | should be disabled when those semantics are inconsistent with the |
| request method, since this is a common cause of interoperability |  | request method, since this is a common cause of interoperability |
| failure. |  | failure. (Section 2) |
| The default charset of ISO-8859-1 for text media types has been |  | An algorithm has been added for determining if a payload is |
| removed; the default is now whatever the media type definition says |  | associated with a specific identifier. (Section 3.1.4.1) |
| (Section 3.1.1.3). Likewise, special treatment of ISO-8859-1 has |  |  |
| been removed from the Accept-Charset header field (Section 5.3.3). |  |  |
| The Content-Disposition header field has been removed since it is now |  | The default charset of ISO-8859-1 for text media types has been |
| defined by [RFC6266]. |  | removed; the default is now whatever the media type definition says. |
|  |  | Likewise, special treatment of ISO-8859-1 has been removed from the |
|  |  | Accept-Charset header field. (Section 3.1.1.3 and Section 5.3.3) |
| The definition of Content-Location has been changed to no longer |  | The definition of Content-Location has been changed to no longer |
| affect the base URI for resolving relative URI references, due to |  | affect the base URI for resolving relative URI references, due to |
| poor implementation support and the undesirable effect of potentially |  | poor implementation support and the undesirable effect of potentially |
| breaking relative links in content-negotiated resources |  | breaking relative links in content-negotiated resources. |
| (Section 3.1.4.2). |  | (Section 3.1.4.2) |
| The Content-MD5 header field has been removed because it was |  |  |
| inconsistently implemented with respect to partial responses. |  |  |
| To be consistent with the method-neutral parsing algorithm of |  | To be consistent with the method-neutral parsing algorithm of |
| [Part1], the definition of GET has been relaxed so that requests can |  | [Part1], the definition of GET has been relaxed so that requests can |
| have a body, even though a body has no meaning for GET |  | have a body, even though a body has no meaning for GET. |
| (Section 4.3.1). |  | (Section 4.3.1) |
| Servers are no longer required to handle all Content-* header fields |  | Servers are no longer required to handle all Content-* header fields |
| and use of Content-Range has been explicitly banned in PUT requests |  | and use of Content-Range has been explicitly banned in PUT requests. |
| (Section 4.3.4). |  | (Section 4.3.4) |
| Definition of the CONNECT method has been moved from [RFC2817] to |  | Definition of the CONNECT method has been moved from [RFC2817] to |
| this specification (Section 4.3.6). |  | this specification. (Section 4.3.6) |
| The OPTIONS (Section 4.3.7) and TRACE (Section 4.3.8) request methods |  |  |
| have been defined as being safe. |  |  |
| The definition of Expect has been both fixed to allow parameters for |  | The OPTIONS and TRACE request methods have been defined as being |
| value-less expectations and simplified to allow trailing semicolons |  | safe. (Section 4.3.7 and Section 4.3.8) |
| after "100-continue" (Section 5.1.1). |  | The Expect header field's extension mechanism has been removed due to |
|  |  | widely-deployed broken implementations. (Section 5.1.1) |
| The Max-Forwards header field (Section 5.1.2) has been restricted to |  | The Max-Forwards header field has been restricted to the OPTIONS and |
| the OPTIONS and TRACE methods; previously, extension methods could |  | TRACE methods; previously, extension methods could have used it as |
| have used it as well. |  | well. (Section 5.1.2) |
| The "about:blank" URI has been suggested as a value for the Referer |  | The "about:blank" URI has been suggested as a value for the Referer |
| header field when no referring URI is applicable, which distinguishes |  | header field when no referring URI is applicable, which distinguishes |
| that case from others where the Referer field is not sent or has been |  | that case from others where the Referer field is not sent or has been |
| removed (Section 5.5.2). |  | removed. (Section 5.5.2) |
|  |  | The following status codes are now cacheable (that is, they can be |
|  |  | stored and reused by a cache without explicit freshness information |
|  |  | present): 204, 404, 405, 414, 501. (Section 6) |
| The 201 (Created) status description has been changed to allow for |  | The 201 (Created) status description has been changed to allow for |
| the possibility that more than one resource has been created |  | the possibility that more than one resource has been created. |
| (Section 6.3.2). |  | (Section 6.3.2) |
| The definition of 203 (Non-Authoritative Information) has been |  | The definition of 203 (Non-Authoritative Information) has been |
| broadened to include cases of payload transformations as well |  | broadened to include cases of payload transformations as well. |
| (Section 6.3.4). |  | (Section 6.3.4) |
| The redirect status codes 301, 302, and 307 no longer have normative |  | The set of request methods that are safe to automatically redirect is |
| requirements on response payloads and user interaction (Section 6.4). |  | no longer closed; user agents are able to make that determination |
|  |  | based upon the request method semantics. The redirect status codes |
|  |  | 301, 302, and 307 no longer have normative requirements on response |
|  |  | payloads and user interaction. (Section 6.4) |
| The request methods that are safe to automatically redirect is no |  | The status codes 301 and 302 have been changed to allow user agents |
| longer a closed set; user agents are able to make that determination |  | to rewrite the method from POST to GET. (Sections 6.4.2 and 6.4.3) |
| based upon the request method semantics (Section 6.4). |  |  |
| The description of 303 (See Other) status code has been changed to |  | The description of 303 (See Other) status code has been changed to |
| allow it to be cached if explicit freshness information is given, and |  | allow it to be cached if explicit freshness information is given, and |
| a specific definition has been added for a 303 response to GET |  | a specific definition has been added for a 303 response to GET. |
| (Section 6.4.4). |  | (Section 6.4.4) |
| The status codes 301 and 302 (sections 6.4.2 and 6.4.3) have been |  |  |
| changed to allow user agents to rewrite the method from POST to GET. |  |  |
| The 305 (Use Proxy) status code has been deprecated due to security |  | The 305 (Use Proxy) status code has been deprecated due to security |
| concerns regarding in-band configuration of a proxy (Section 6.4.5). |  | concerns regarding in-band configuration of a proxy. (Section 6.4.5) |
| The 400 (Bad Request) status code has been relaxed so that it isn't |  | The 400 (Bad Request) status code has been relaxed so that it isn't |
| limited to syntax errors (Section 6.5.1). |  | limited to syntax errors. (Section 6.5.1) |
| The 426 (Upgrade Required) status code has been incorporated from |  | The 426 (Upgrade Required) status code has been incorporated from |
|  |  | [RFC2817]. (Section 6.5.15) |
| [RFC2817] (Section 6.5.15). |  |  |
| The following status codes are now cacheable (that is, they can be |  |  |
| stored and reused by a cache without explicit freshness information |  |  |
| present): 204, 404, 405, 414, 501. |  |  |
| Allow has been reclassified as a response header field, removing the |  |  |
| option to specify it in a PUT request. Requirements relating to the |  |  |
| content of Allow have been relaxed; correspondingly, clients are not |  |  |
| required to always trust its value (Section 7.4.1). |  |  |
| The target of requirements on HTTP-date and the Date header field |  | The target of requirements on HTTP-date and the Date header field |
| have been reduced to those systems generating the date, rather than |  | have been reduced to those systems generating the date, rather than |
| all systems sending a date (Section 7.1.1). |  | all systems sending a date. (Section 7.1.1) |
| The syntax of the Location header field has been changed to allow all |  | The syntax of the Location header field has been changed to allow all |
| URI references, including relative references and fragments, along |  | URI references, including relative references and fragments, along |
| with some clarifications as to when use of fragments would not be |  | with some clarifications as to when use of fragments would not be |
| appropriate (Section 7.1.2). |  | appropriate. (Section 7.1.2) |
| A Method Registry has been defined (Section 8.1). |  | Allow has been reclassified as a response header field, removing the |
|  |  | option to specify it in a PUT request. Requirements relating to the |
|  |  | content of Allow have been relaxed; correspondingly, clients are not |
|  |  | required to always trust its value. (Section 7.4.1) |
| The Status Code Registry (Section 8.2) has been redefined by this |  | A Method Registry has been defined. (Section 8.1) |
| specification; previously, it was defined in Section 7.1 of |  |  |
| [RFC2817]. |  | The Status Code Registry has been redefined by this specification; |
|  |  | previously, it was defined in Section 7.1 of [RFC2817]. |
|  |  | (Section 8.2) |
| Registration of Content Codings has been changed to require IETF |  | Registration of Content Codings has been changed to require IETF |
| Review (Section 8.4). |  | Review. (Section 8.4) |
|  |  | The Content-Disposition header field has been removed since it is now |
|  |  | defined by [RFC6266]. |
|  |  | The Content-MD5 header field has been removed because it was |
|  |  | inconsistently implemented with respect to partial responses. |
| Appendix C. Imported ABNF |  | Appendix C. Imported ABNF |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), |  | Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), |
| CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double |  | CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double |
| quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF |  | quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF |
| (line feed), OCTET (any 8-bit sequence of data), SP (space), and |  | (line feed), OCTET (any 8-bit sequence of data), SP (space), and |
| VCHAR (any visible US-ASCII character). |  | VCHAR (any visible US-ASCII character). |
| skipping to change at page 92, line 43 |  | skipping to change at page 93, line 43 |
| Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS |  | Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS |
| content-coding ] ) |  | content-coding ] ) |
| Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS |  | Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS |
| language-tag ] ) |  | language-tag ] ) |
| Content-Location = absolute-URI / partial-URI |  | Content-Location = absolute-URI / partial-URI |
| Content-Type = media-type |  | Content-Type = media-type |
| Date = HTTP-date |  | Date = HTTP-date |
| Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) |  | Expect = "100-continue" |
| From = mailbox |  | From = mailbox |
| GMT = %x47.4D.54 ; GMT |  | GMT = %x47.4D.54 ; GMT |
| HTTP-date = IMF-fixdate / obs-date |  | HTTP-date = IMF-fixdate / obs-date |
| IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT |  | IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT |
| Location = URI-reference |  | Location = URI-reference |
| skipping to change at page 94, line 4 |  | skipping to change at page 95, line 4 |
| / %x53.61.74 ; Sat |  | / %x53.61.74 ; Sat |
| / %x53.75.6E ; Sun |  | / %x53.75.6E ; Sun |
| day-name-l = %x4D.6F.6E.64.61.79 ; Monday |  | day-name-l = %x4D.6F.6E.64.61.79 ; Monday |
| / %x54.75.65.73.64.61.79 ; Tuesday |  | / %x54.75.65.73.64.61.79 ; Tuesday |
| / %x57.65.64.6E.65.73.64.61.79 ; Wednesday |  | / %x57.65.64.6E.65.73.64.61.79 ; Wednesday |
| / %x54.68.75.72.73.64.61.79 ; Thursday |  | / %x54.68.75.72.73.64.61.79 ; Thursday |
| / %x46.72.69.64.61.79 ; Friday |  | / %x46.72.69.64.61.79 ; Friday |
| / %x53.61.74.75.72.64.61.79 ; Saturday |  | / %x53.61.74.75.72.64.61.79 ; Saturday |
| / %x53.75.6E.64.61.79 ; Sunday |  | / %x53.75.6E.64.61.79 ; Sunday |
| delta-seconds = 1*DIGIT |  | delta-seconds = 1*DIGIT |
| expect-name = token |  |  |
| expect-param = expect-name [ BWS "=" BWS expect-value ] |  |  |
| expect-value = token / quoted-string |  |  |
| expectation = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [ |  |  |
| OWS expect-param ] ) |  |  |
| field-name = <comment, defined in [Part1], Section 3.2> |  | field-name = <comment, defined in [Part1], Section 3.2> |
| hour = 2DIGIT |  | hour = 2DIGIT |
| language-range = <language-range, defined in [RFC4647], Section 2.1> |  | language-range = <language-range, defined in [RFC4647], Section 2.1> |
| language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> |  | language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> |
| mailbox = <mailbox, defined in [RFC5322], Section 3.4> |  | mailbox = <mailbox, defined in [RFC5322], Section 3.4> |
| media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS |  | media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS |
| ";" OWS parameter ) |  | ";" OWS parameter ) |
| skipping to change at page 96, line 24 |  | skipping to change at page 97, line 18 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/434>: "mention in |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/434>: "mention in |
| header field considerations that leading/trailing WS is lossy" |  | header field considerations that leading/trailing WS is lossy" |
| E.3. Since draft-ietf-httpbis-p2-semantics-22 |  | E.3. Since draft-ietf-httpbis-p2-semantics-22 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list |
| expansion in ABNF appendices" |  | expansion in ABNF appendices" |
| o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/448>: "Fallback |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/448>: "Fallback for |
| for Accept-Language" |  | Accept-Language" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/449>: "Receiving a |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/449>: "Receiving a |
| higher minor HTTP version number" |  | higher minor HTTP version number" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/456>: "Language-tag |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/456>: "Language-tag |
| vs. language-range" |  | vs. language-range" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/457>: "Registering |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/457>: "Registering |
| x-gzip and x-deflate" |  | x-gzip and x-deflate" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/459>: "RFC2774 and |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/459>: "RFC2774 and |
| method registrations" |  | method registrations" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/488>: "Selection |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/488>: "Selection |
| based upon request target" |  | based upon request target" |
|  |  | E.4. Since draft-ietf-httpbis-p2-semantics-23 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/303>: "400 response |
|  |  | isn't generic" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/450>: "p2 Editorial |
|  |  | feedback" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/452>: "Content- |
|  |  | Length in HEAD responses" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/458>: "Requirements |
|  |  | upon proxies for Expect" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/468>: "Expectation |
|  |  | Extensions" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/470>: "What is |
|  |  | 'Cacheable'?" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/478>: "MUSTs and |
|  |  | other feedback" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/487>: "Resubmission |
|  |  | of 403" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/491>: "does 205 |
|  |  | allow chunked encoding?" |
| Index |  | Index |
| 1 |  | 1 |
| 1xx Informational (status code class) 49 |  | 1xx Informational (status code class) 50 |
| 2 |  | 2 |
| 2xx Successful (status code class) 50 |  | 2xx Successful (status code class) 51 |
| 3 |  | 3 |
| 3xx Redirection (status code class) 53 |  | 3xx Redirection (status code class) 54 |
| 4 |  | 4 |
| 4xx Client Error (status code class) 57 |  | 4xx Client Error (status code class) 58 |
| 5 |  | 5 |
| 5xx Server Error (status code class) 61 |  | 5xx Server Error (status code class) 62 |
| 1 |  | 1 |
| 100 Continue (status code) 49 |  | 100 Continue (status code) 50 |
| 100-continue (expect value) 33 |  | 100-continue (expect value) 34 |
| 101 Switching Protocols (status code) 50 |  | 101 Switching Protocols (status code) 50 |
| 2 |  | 2 |
| 200 OK (status code) 50 |  | 200 OK (status code) 51 |
| 201 Created (status code) 51 |  | 201 Created (status code) 52 |
| 202 Accepted (status code) 51 |  | 202 Accepted (status code) 52 |
| 203 Non-Authoritative Information (status code) 51 |  | 203 Non-Authoritative Information (status code) 52 |
| 204 No Content (status code) 52 |  | 204 No Content (status code) 53 |
| 205 Reset Content (status code) 52 |  | 205 Reset Content (status code) 53 |
| 3 |  | 3 |
| 300 Multiple Choices (status code) 54 |  | 300 Multiple Choices (status code) 55 |
| 301 Moved Permanently (status code) 55 |  | 301 Moved Permanently (status code) 56 |
| 302 Found (status code) 55 |  | 302 Found (status code) 56 |
| 303 See Other (status code) 56 |  | 303 See Other (status code) 57 |
| 305 Use Proxy (status code) 56 |  | 305 Use Proxy (status code) 57 |
| 306 (Unused) (status code) 56 |  | 306 (Unused) (status code) 57 |
| 307 Temporary Redirect (status code) 57 |  | 307 Temporary Redirect (status code) 58 |
| 4 |  | 4 |
| 400 Bad Request (status code) 57 |  | 400 Bad Request (status code) 58 |
| 402 Payment Required (status code) 57 |  | 402 Payment Required (status code) 58 |
| 403 Forbidden (status code) 57 |  | 403 Forbidden (status code) 58 |
| 404 Not Found (status code) 58 |  | 404 Not Found (status code) 59 |
| 405 Method Not Allowed (status code) 58 |  | 405 Method Not Allowed (status code) 59 |
| 406 Not Acceptable (status code) 58 |  | 406 Not Acceptable (status code) 59 |
| 408 Request Timeout (status code) 59 |  | 408 Request Timeout (status code) 60 |
| 409 Conflict (status code) 59 |  | 409 Conflict (status code) 60 |
| 410 Gone (status code) 59 |  | 410 Gone (status code) 60 |
| 411 Length Required (status code) 60 |  | 411 Length Required (status code) 61 |
| 413 Payload Too Large (status code) 60 |  | 413 Payload Too Large (status code) 61 |
| 414 URI Too Long (status code) 60 |  | 414 URI Too Long (status code) 61 |
| 415 Unsupported Media Type (status code) 60 |  | 415 Unsupported Media Type (status code) 61 |
| 417 Expectation Failed (status code) 61 |  | 417 Expectation Failed (status code) 62 |
| 426 Upgrade Required (status code) 61 |  | 426 Upgrade Required (status code) 62 |
| 5 |  | 5 |
| 500 Internal Server Error (status code) 61 |  | 500 Internal Server Error (status code) 62 |
| 501 Not Implemented (status code) 61 |  | 501 Not Implemented (status code) 62 |
| 502 Bad Gateway (status code) 62 |  | 502 Bad Gateway (status code) 63 |
| 503 Service Unavailable (status code) 62 |  | 503 Service Unavailable (status code) 63 |
| 504 Gateway Timeout (status code) 62 |  | 504 Gateway Timeout (status code) 63 |
| 505 HTTP Version Not Supported (status code) 62 |  | 505 HTTP Version Not Supported (status code) 63 |
| A |  | A |
| Accept header field 38 |  | Accept header field 38 |
| Accept-Charset header field 40 |  | Accept-Charset header field 40 |
| Accept-Encoding header field 41 |  | Accept-Encoding header field 41 |
| Accept-Language header field 42 |  | Accept-Language header field 42 |
| Allow header field 71 |  | Allow header field 72 |
| C |  | C |
| cacheable 23 |  | cacheable 24 |
| compress (content coding) 11 |  | compress (content coding) 11 |
| conditional request 36 |  | conditional request 36 |
| CONNECT method 29 |  | CONNECT method 30 |
| content coding 11 |  | content coding 11 |
| content negotiation 6 |  | content negotiation 6 |
| Content-Encoding header field 12 |  | Content-Encoding header field 12 |
| Content-Language header field 13 |  | Content-Language header field 13 |
| Content-Location header field 15 |  | Content-Location header field 15 |
| Content-Transfer-Encoding header field 88 |  | Content-Transfer-Encoding header field 89 |
| Content-Type header field 10 |  | Content-Type header field 10 |
| D |  | D |
| Date header field 66 |  | Date header field 67 |
| deflate (content coding) 11 |  | deflate (content coding) 11 |
| DELETE method 28 |  | DELETE method 29 |
| E |  | E |
| Expect header field 33 |  | Expect header field 34 |
| Expect Values |  |  |
| 100-continue 33 |  |  |
| F |  | F |
| From header field 44 |  | From header field 44 |
| G |  | G |
| GET method 24 |  | GET method 24 |
| Grammar |  | Grammar |
| Accept 38 |  | Accept 38 |
| Accept-Charset 40 |  | Accept-Charset 40 |
| Accept-Encoding 41 |  | Accept-Encoding 41 |
| accept-ext 38 |  | accept-ext 38 |
| Accept-Language 42 |  | Accept-Language 42 |
| accept-params 38 |  | accept-params 38 |
| Allow 71 |  | Allow 72 |
| asctime-date 65 |  | asctime-date 67 |
| attribute 8 |  | attribute 8 |
| charset 9 |  | charset 9 |
| codings 41 |  | codings 41 |
| content-coding 11 |  | content-coding 11 |
| Content-Encoding 12 |  | Content-Encoding 12 |
| Content-Language 13 |  | Content-Language 13 |
| Content-Location 15 |  | Content-Location 15 |
| Content-Type 10 |  | Content-Type 10 |
| Date 66 |  | Date 67 |
| date1 64 |  | date1 66 |
| day 64 |  | day 66 |
| day-name 64 |  | day-name 66 |
| day-name-l 64 |  | day-name-l 66 |
| delta-seconds 68 |  | delta-seconds 70 |
| Expect 33 |  | Expect 34 |
| expect-name 33 |  |  |
| expect-param 33 |  |  |
| expect-value 33 |  |  |
| expectation 33 |  |  |
| From 44 |  | From 44 |
| GMT 64 |  | GMT 66 |
| hour 64 |  | hour 66 |
| HTTP-date 63 |  | HTTP-date 64 |
| IMF-fixdate 64 |  | IMF-fixdate 66 |
| language-range 42 |  | language-range 42 |
| language-tag 13 |  | language-tag 13 |
| Location 66 |  | Location 68 |
| Max-Forwards 36 |  | Max-Forwards 36 |
| media-range 38 |  | media-range 38 |
| media-type 8 |  | media-type 8 |
| method 20 |  | method 21 |
| minute 64 |  | minute 66 |
| month 64 |  | month 66 |
| obs-date 65 |  | obs-date 66 |
| parameter 8 |  | parameter 8 |
| product 46 |  | product 46 |
| product-version 46 |  | product-version 46 |
| qvalue 37 |  | qvalue 38 |
| Referer 45 |  | Referer 45 |
| Retry-After 68 |  | Retry-After 70 |
| rfc850-date 65 |  | rfc850-date 67 |
| second 64 |  | second 66 |
| Server 71 |  | Server 73 |
| subtype 8 |  | subtype 8 |
| time-of-day 64 |  | time-of-day 66 |
| type 8 |  | type 8 |
| User-Agent 46 |  | User-Agent 46 |
| value 8 |  | value 8 |
| Vary 68 |  | Vary 70 |
| weight 37 |  | weight 38 |
| year 64 |  | year 66 |
| gzip (content coding) 11 |  | gzip (content coding) 11 |
| H |  | H |
| HEAD method 24 |  | HEAD method 25 |
| I |  | I |
| idempotent 23 |  | idempotent 23 |
| L |  | L |
| Location header field 66 |  | Location header field 68 |
| M |  | M |
| Max-Forwards header field 36 |  | Max-Forwards header field 36 |
| MIME-Version header field 87 |  | MIME-Version header field 88 |
| O |  | O |
| OPTIONS method 31 |  | OPTIONS method 31 |
| P |  | P |
| payload 17 |  | payload 17 |
| POST method 25 |  | POST method 25 |
| PUT method 26 |  | PUT method 26 |
| R |  | R |
| Referer header field 44 |  | Referer header field 45 |
| representation 7 |  | representation 7 |
| Retry-After header field 68 |  | Retry-After header field 69 |
| S |  | S |
| safe 22 |  | safe 22 |
| selected representation 7, 69 |  | selected representation 7, 71 |
| Server header field 71 |  | Server header field 73 |
| Status Codes Classes |  | Status Codes Classes |
| 1xx Informational 49 |  | 1xx Informational 50 |
| 2xx Successful 50 |  | 2xx Successful 51 |
| 3xx Redirection 53 |  | 3xx Redirection 54 |
| 4xx Client Error 57 |  | 4xx Client Error 58 |
| 5xx Server Error 61 |  | 5xx Server Error 62 |
| T |  | T |
| TRACE method 32 |  | TRACE method 32 |
| U |  | U |
| User-Agent header field 45 |  | User-Agent header field 46 |
| V |  | V |
| Vary header field 68 |  | Vary header field 70 |
| X |  | X |
| x-compress (content coding) 11 |  | x-compress (content coding) 11 |
| x-gzip (content coding) 11 |  | x-gzip (content coding) 11 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Adobe Systems Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
End of changes. 208 change blocks.
| 655 lines changed or deleted |  | 685 lines changed or added |
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/