| draft-ietf-httpbis-p2-semantics-24.txt |  | draft-ietf-httpbis-p2-semantics-25.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 September 25, 2013 |  | Intended status: Standards Track November 17, 2013 |
| Expires: March 29, 2014 |  | Expires: May 21, 2014 |
| Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |  | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
| draft-ietf-httpbis-p2-semantics-24 |  | draft-ietf-httpbis-p2-semantics-25 |
| 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.4. |  | The changes in this draft are summarized in Appendix E.2. |
| 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 March 29, 2014. |  | This Internet-Draft will expire on May 21, 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 3, line 34 |  | skipping to change at page 3, line 34 |
| 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 . . . . . . . . . . . . . . . . . . . . . . . 45 |  | 5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 45 |
| 5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 46 |  | 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 . . . . . . . . . . . . . . . . . 48 |
| 6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 50 |  | 6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 50 |
| 6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 50 |  | 6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 50 |
| 6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50 |  | 6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50 |
| 6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51 |
| 6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51 |
| 6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 52 |  | 6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 52 |
| 6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 52 |  | 6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 52 |
| 6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 52 |  | 6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 52 |
| 6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 53 |  | 6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 53 |
| 6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 53 |  | 6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 53 |
| 6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 54 |  | 6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 54 |
| 6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 55 |  | 6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 55 |
| 6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 56 |  | 6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 56 |
| 6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 56 |  | 6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 56 |
| 6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 57 |  | 6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 57 |
| 6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 57 |  | 6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 57 |
| 6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 57 |  | 6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 58 |
| 6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 58 |  | 6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 58 |
| 6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58 |  | 6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58 |
| 6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 58 |  | 6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 58 |
| 6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 58 |  | 6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 58 |
| 6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 58 |  | 6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 59 |
| 6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 59 |  | 6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 59 |
| 6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 59 |  | 6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 59 |
| 6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 59 |  | 6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 59 |
| 6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 60 |  | 6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 60 |
| 6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 60 |  | 6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 60 |
| 6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60 |  | 6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60 |
| 6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 61 |  | 6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 61 |
| 6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 61 |  | 6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 61 |
| 6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61 |  | 6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61 |
| 6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 61 |  | 6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 62 |
| 6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62 |  | 6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62 |
| 6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62 |  | 6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62 |
| 6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62 |  | 6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62 |
| 6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 62 |  | 6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 63 |
| 6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 62 |  | 6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 63 |
| 6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 63 |  | 6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 63 |
| 6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 63 |  | 6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 63 |
| 6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 63 |  | 6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 63 |
| 6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 63 |  | 6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 63 |
| 7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 63 |  | 7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 64 |
| 7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 64 |  | 7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 64 |
| 7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 64 |  | 7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 64 |
| 7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 68 |  | 7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 68 |
| 7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69 |  | 7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69 |
| 7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70 |  | 7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70 |
| 7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71 |  | 7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71 |
| 7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72 |  | 7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72 |
| 7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 72 |  | 7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 72 |
| 7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72 |  | 7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72 |
| 7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 73 |  | 7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 73 |
| skipping to change at page 5, line 10 |  | skipping to change at page 5, line 10 |
| 8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77 |  | 8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77 |
| 8.3.1. Considerations for New Header Fields . . . . . . . . . 78 |  | 8.3.1. Considerations for New Header Fields . . . . . . . . . 78 |
| 8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80 |  | 8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80 |
| 8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80 |  | 8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80 |
| 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 80 |  | 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 80 |
| 8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81 |  | 8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81 |
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 81 |  | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 81 |
| 9.1. Attacks Based On File and Path Names . . . . . . . . . . . 81 |  | 9.1. Attacks Based On File and Path Names . . . . . . . . . . . 81 |
| 9.2. Personal Information . . . . . . . . . . . . . . . . . . . 82 |  | 9.2. Personal Information . . . . . . . . . . . . . . . . . . . 82 |
| 9.3. Sensitive Information in URIs . . . . . . . . . . . . . . 82 |  | 9.3. Sensitive Information in URIs . . . . . . . . . . . . . . 82 |
| 9.4. Product Information . . . . . . . . . . . . . . . . . . . 83 |  | 9.4. Product Information . . . . . . . . . . . . . . . . . . . 82 |
| 9.5. Fragment after Redirects . . . . . . . . . . . . . . . . . 83 |  | 9.5. Fragment after Redirects . . . . . . . . . . . . . . . . . 83 |
| 9.6. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 83 |  | 9.6. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 83 |
| 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 |  | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 |
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84 |  | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84 |
| 11.1. Normative References . . . . . . . . . . . . . . . . . . . 84 |  | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 84 |
| 11.2. Informative References . . . . . . . . . . . . . . . . . . 86 |  | 11.2. Informative References . . . . . . . . . . . . . . . . . . 85 |
| Appendix A. Differences between HTTP and MIME . . . . . . . . . . 88 |  | Appendix A. Differences between HTTP and MIME . . . . . . . . . . 87 |
| A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88 |  | A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88 |
| A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 88 |  | A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 88 |
| A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 89 |  | A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 88 |
| A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 89 |  | A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 88 |
| A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 89 |  | A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 89 |
| A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 89 |  | A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 89 |
| Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 90 |  | Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 89 |
| Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 92 |  | Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 92 |
| Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 93 |  | Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 92 |
| Appendix E. Change Log (to be removed by RFC Editor before |  | Appendix E. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 96 |  | publication) . . . . . . . . . . . . . . . . . . . . 95 |
| E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 96 |  | E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 95 |
| E.2. Since draft-ietf-httpbis-p2-semantics-21 . . . . . . . . . 96 |  | E.2. Since draft-ietf-httpbis-p2-semantics-24 . . . . . . . . . 95 |
| 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 23, line 48 |  | skipping to change at page 23, line 48 |
| 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 owner 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 |  | A request method is considered "idempotent" if the intended effect on |
| multiple identical requests is the same as for a single request. Of |  | the server of multiple identical requests with that method is the |
| the request methods defined by this specification, the PUT, DELETE, |  | same as the effect for a single such request. Of the request methods |
| and safe request methods are idempotent. |  | defined by this specification, PUT, DELETE, and safe request methods |
|  |  | are idempotent. |
| Like the definition of safe, the idempotent property only applies to |  | Like the definition of safe, the idempotent property only applies to |
| what has been requested by the user; a server is free to log each |  | what has been requested by the user; a server is free to log each |
| request separately, retain a revision control history, or implement |  | request separately, retain a revision control history, or implement |
| other non-idempotent side-effects for each idempotent request. |  | other non-idempotent side-effects for each idempotent request. |
| Idempotent methods are distinguished because the request can be |  | Idempotent methods are distinguished because the request can be |
| repeated automatically if a communication failure occurs before the |  | repeated automatically if a communication failure occurs before the |
| 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 the client 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, though the status codes might differ in response). |
| indicate a problem within the server. |  | Note, however, that repeated communication failures might indicate |
|  |  | that the server has failed in general, or that something in the |
|  |  | request is triggering a connection drop. |
| 4.2.3. Cacheable Methods |  | 4.2.3. Cacheable Methods |
| Request methods can be defined as "cacheable" to indicate that |  | Request methods can be defined as "cacheable" to indicate that |
| responses to them are allowed to be stored for future reuse; for |  | responses to them are allowed to be stored for future reuse; for |
| specific requirements see [Part6]. In general, safe methods that do |  | specific requirements see [Part6]. In general, safe methods that do |
| not depend on a current or authoritative response are defined as |  | not depend on a current or authoritative response are defined as |
| cacheable; this specification defines GET, HEAD and POST as |  | cacheable; this specification defines GET, HEAD and POST as |
| cacheable, although the overwhelming majority of cache |  | cacheable, although the overwhelming majority of cache |
| implementations only support GET and HEAD. |  | implementations only support GET and HEAD. |
| skipping to change at page 45, line 17 |  | skipping to change at page 45, line 17 |
| 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 NOT include the fragment and userinfo components of the |  | agent MUST NOT include the fragment and userinfo components of the |
| URI reference [RFC3986], if any, when generating the Referer field |  | URI reference [RFC3986], if any, when generating the Referer field |
| value. |  | value. |
| Referer = absolute-URI / partial-URI |  | Referer = absolute-URI / partial-URI |
| Referer allows servers to generate back-links to other resources for |  | The Referer header field allows servers to generate back-links to |
| simple analytics, logging, optimized caching, etc. It also allows |  | other resources for simple analytics, logging, optimized caching, |
| obsolete or mistyped links to be found for maintenance. Some servers |  | etc. It also allows obsolete or mistyped links to be found for |
| use Referer as a means of denying links from other sites (so-called |  | maintenance. Some servers use the Referer header field as a means of |
| "deep linking") or restricting cross-site request forgery (CSRF), but |  | denying links from other sites (so-called "deep linking") or |
| not all requests contain a Referer header field. |  | restricting cross-site request forgery (CSRF), but not all requests |
|  |  | contain it. |
| Example: |  | Example: |
| Referer: http://www.example.org/hypertext/Overview.html |  | Referer: http://www.example.org/hypertext/Overview.html |
| If the target URI was obtained from a source that does not have its |  | If the target URI was obtained from a source that does not have its |
| own URI (e.g., input from the user keyboard, or an entry within the |  | own URI (e.g., input from the user keyboard, or an entry within the |
| 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". |
| skipping to change at page 48, line 7 |  | skipping to change at page 48, line 13 |
| 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 |  | 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 |  | (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501 in this |
| reused by a cache with heuristic expiration unless otherwise |  | specification) can be reused by a cache with heuristic expiration |
| indicated by the method definition or explicit cache controls |  | unless otherwise indicated by the method definition or explicit cache |
| [Part6]; all other status codes are not cacheable by default. |  | 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 | |
| skipping to change at page 51, line 47 |  | skipping to change at page 51, line 47 |
| 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 section. |  | response header section. |
| A 200 response is cacheable unless otherwise indicated by the method |  | A 200 response is cacheable by default; i.e., unless otherwise |
| definition or explicit cache controls (see Section 4.2.2 of [Part6]). |  | indicated by the method 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 52 |  | skipping to change at page 52, line 52 |
| 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 5.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 by default; i.e., unless otherwise |
| definition or explicit cache controls (see Section 4.2.2 of [Part6]). |  | indicated by the method 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 53, line 36 |  | 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 by default; i.e., unless otherwise |
| definition or explicit cache controls (see Section 4.2.2 of [Part6]). |  | indicated by the method 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, |
| skipping to change at page 55, line 43 |  | skipping to change at page 55, line 46 |
| redirection. |  | redirection. |
| 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 by default; i.e., unless otherwise |
| definition or explicit cache controls (see Section 4.2.2 of [Part6]). |  | indicated by the method 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 56, line 28 |  | skipping to change at page 56, line 35 |
| 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, a user agent 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, the 307 (Temporary Redirect) status code |  | behavior is undesired, the 307 (Temporary Redirect) status code |
| can be used instead. |  | can be used instead. |
| A 301 response is cacheable unless otherwise indicated by the method |  | A 301 response is cacheable by default; i.e., unless otherwise |
| definition or explicit cache controls (see Section 4.2.2 of [Part6]). |  | indicated by the method 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 |
| skipping to change at page 59, line 26 |  | skipping to change at page 59, line 33 |
| 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 code does not |  | willing to disclose that one exists. A 404 status code does not |
| indicate whether this lack of representation is temporary or |  | indicate whether this lack of representation is temporary or |
| permanent; the 410 (Gone) status code is preferred over 404 if the |  | permanent; the 410 (Gone) status code is preferred over 404 if the |
| origin server knows, presumably through some configurable means, that |  | origin server knows, presumably through some configurable means, that |
| the condition 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 by default; i.e., unless otherwise |
| definition or explicit cache controls (see Section 4.2.2 of [Part6]). |  | indicated by the method 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 |
| received 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 by default; i.e., unless otherwise |
| definition or explicit cache controls (see Section 4.2.2 of [Part6]). |  | indicated by the method 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 61, line 5 |  | skipping to change at page 61, line 15 |
| The 410 response is primarily intended to assist the task of web |  | The 410 response is primarily intended to assist the task of web |
| 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 by default; i.e., unless otherwise |
| definition or explicit cache controls (see Section 4.2.2 of [Part6]). |  | indicated by the method 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 61, line 39 |  | skipping to change at page 61, line 50 |
| The 414 (URI Too Long) status code indicates that the server is |  | The 414 (URI Too Long) status code indicates that the server is |
| 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 by default; i.e., unless otherwise |
| definition or explicit cache controls (see Section 4.2.2 of [Part6]). |  | indicated by the method 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 this method on the target resource. |  | is in a format not supported by this method on the target resource. |
| The format problem might be due to the request's indicated Content- |  | The format problem might be due to the request's indicated Content- |
| Type or Content-Encoding, or as a result of inspecting the data |  | Type or Content-Encoding, or as a result of inspecting the data |
| directly. |  | directly. |
| skipping to change at page 63, line 6 |  | skipping to change at page 63, line 18 |
| 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 by default; i.e., unless otherwise |
| definition or explicit cache controls (see Section 4.2.2 of [Part6]). |  | indicated by the method 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 65, line 13 |  | skipping to change at page 65, line 25 |
| MUST accept all three HTTP-date formats. When a sender generates a |  | MUST accept all three HTTP-date formats. When a sender generates a |
| header field that contains one or more timestamps defined as HTTP- |  | header field that contains one or more timestamps defined as HTTP- |
| date, the sender MUST generate those timestamps in the IMF-fixdate |  | date, the sender MUST generate those timestamps in the IMF-fixdate |
| format. |  | 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 ([RFC5905]) or some similar protocol to |
| synchronize its clock to UTC. |  | synchronize its clock to UTC. |
| Preferred format: |  | Preferred format: |
| IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT |  | IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT |
| ; fixed length/zone subset of the format defined in |  | ; fixed length/zone subset of the format defined in |
| ; Section 3.3 of [RFC5322] |  | ; Section 3.3 of [RFC5322] |
| day-name = %x4D.6F.6E ; "Mon", case-sensitive |  | day-name = %x4D.6F.6E ; "Mon", case-sensitive |
| / %x54.75.65 ; "Tue", case-sensitive |  | / %x54.75.65 ; "Tue", case-sensitive |
| skipping to change at page 70, line 7 |  | skipping to change at page 70, line 7 |
| 7.1.3. Retry-After |  | 7.1.3. Retry-After |
| Servers send the "Retry-After" header field to indicate how long the |  | Servers send the "Retry-After" header field to indicate how long the |
| user agent ought to wait before making a follow-up request. When |  | user agent ought to wait before making a follow-up request. When |
| sent with a 503 (Service Unavailable) response, Retry-After indicates |  | sent with a 503 (Service Unavailable) response, Retry-After indicates |
| how long the service is expected to be unavailable to the client. |  | how long the service is expected to be unavailable to the client. |
| When sent with any 3xx (Redirection) response, Retry-After indicates |  | When sent with any 3xx (Redirection) response, Retry-After indicates |
| the minimum time that the user agent is asked to wait before issuing |  | the minimum time that the user agent is asked to wait before issuing |
| the redirected request. |  | the redirected request. |
| The value of this field can be either an HTTP-date or an integer |  | The value of this field can be either an HTTP-date or a number of |
| number of seconds (in decimal) after the time of the response. |  | seconds to delay after the response is received. |
| Retry-After = HTTP-date / delta-seconds |  | Retry-After = HTTP-date / delay-seconds |
| Time spans are non-negative decimal integers, representing time in |  | A delay-seconds value is a non-negative decimal integer, representing |
| seconds. |  | time in seconds. |
| delta-seconds = 1*DIGIT |  | delay-seconds = 1*DIGIT |
| 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 |
| skipping to change at page 74, line 8 |  | skipping to change at page 74, line 8 |
| subproducts by third parties. Overly long and detailed Server field |  | subproducts by third parties. Overly long and detailed Server field |
| values increase response latency and potentially reveal internal |  | values increase response latency and potentially reveal internal |
| implementation details that might make it (slightly) easier for |  | implementation details that might make it (slightly) easier for |
| attackers to find and exploit known security holes. |  | attackers to find and exploit known security holes. |
| 8. IANA Considerations |  | 8. IANA Considerations |
| 8.1. Method Registry |  | 8.1. Method Registry |
| The HTTP Method Registry defines the name space for the request |  | The HTTP Method Registry defines the name space for the request |
| method token (Section 4). The method registry will be created and |  | method token (Section 4). The method registry will be created and |
| maintained at <http://www.iana.org/assignments/http-methods>. |  | maintained at (the suggested URI) |
|  |  | <http://www.iana.org/assignments/http-methods>. |
| 8.1.1. Procedure |  | 8.1.1. Procedure |
| HTTP method registrations MUST include the following fields: |  | HTTP method registrations MUST include the following fields: |
| o Method Name (see Section 4) |  | o Method Name (see Section 4) |
| o Safe ("yes" or "no", see Section 4.2.1) |  | o Safe ("yes" or "no", see Section 4.2.1) |
| o Idempotent ("yes" or "no", see Section 4.2.2) |  | o Idempotent ("yes" or "no", see Section 4.2.2) |
| skipping to change at page 78, line 13 |  | skipping to change at page 78, line 13 |
| message-header-index.html>, as defined by [BCP90]. |  | message-header-index.html>, as defined by [BCP90]. |
| 8.3.1. Considerations for New Header Fields |  | 8.3.1. Considerations for New Header Fields |
| Header fields are key:value pairs that can be used to communicate |  | Header fields are key:value pairs that can be used to communicate |
| data about the message, its payload, the target resource, or the |  | data about the message, its payload, the target resource, or the |
| connection (i.e., control data). See Section 3.2 of [Part1] for a |  | connection (i.e., control data). See Section 3.2 of [Part1] for a |
| general definition of header field syntax in HTTP messages. |  | general definition of header field syntax in HTTP messages. |
| The requirements for header field names are defined in [BCP90]. |  | The requirements for header field names are defined in [BCP90]. |
| 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; see [BCP178] for further information) |
| 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 Section 7 of [Part1] |  | ABNF ([RFC5234]), using the extension defined in Section 7 of [Part1] |
| as necessary, and are usually constrained to the range of ASCII |  | as necessary, and are usually constrained to the range of ASCII |
| characters. Header fields needing a greater range of characters can |  | characters. Header fields needing a greater range of 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 |
| skipping to change at page 81, line 25 |  | skipping to change at page 81, line 25 |
| Values to be added to this name space require IETF Review (see |  | Values to be added to this name space require IETF Review (see |
| Section 4.1 of [RFC5226]), and MUST conform to the purpose of content |  | Section 4.1 of [RFC5226]), and MUST conform to the purpose of content |
| coding defined in this section. |  | coding defined in this section. |
| 8.4.2. Registrations |  | 8.4.2. Registrations |
| The HTTP Content Codings Registry shall be updated with the |  | The HTTP Content Codings Registry shall be updated with the |
| registrations below: |  | registrations below: |
| +------------+--------------------------------------+---------------+ |  | +----------+----------------------------------------+---------------+ |
| | Name | Description | Reference | |  | | Name | Description | Reference | |
| +------------+--------------------------------------+---------------+ |  | +----------+----------------------------------------+---------------+ |
| | compress | UNIX "compress" data format [Welch] | Section 4.2.1 | |  | | identity | Reserved (synonym for "no encoding" in | Section 5.3.4 | |
| | | | of [Part1] | |  | | | Accept-Encoding) | | |
| | deflate | "deflate" compressed data | Section 4.2.2 | |  | +----------+----------------------------------------+---------------+ |
| | | ([RFC1951]) inside the "zlib" data | of [Part1] | |  |  |
| | | format ([RFC1950]) | | |  |  |
| | gzip | GZIP file format [RFC1952] | Section 4.2.3 | |  |  |
| | | | of [Part1] | |  |  |
| | identity | Reserved (synonym for "no encoding" | Section 5.3.4 | |  |  |
| | | in Accept-Encoding) | | |  |  |
| | x-compress | Deprecated (alias for compress) | Section 4.2.1 | |  |  |
| | | | of [Part1] | |  |  |
| | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | |  |  |
| | | | of [Part1] | |  |  |
| +------------+--------------------------------------+---------------+ |  |  |
| 9. Security Considerations |  | 9. Security Considerations |
| This section is meant to inform developers, information providers, |  | This section is meant to inform developers, information providers, |
| and users of known security concerns relevant to HTTP/1.1 semantics |  | and users of known security concerns relevant to HTTP/1.1 semantics |
| and its use for transferring information over the Internet. |  | and its use for transferring information over the Internet. |
| 9.1. Attacks Based On File and Path Names |  | 9.1. Attacks Based On File and Path Names |
| Origin servers frequently make use of their local file system to |  | Origin servers frequently make use of their local file system to |
| skipping to change at page 84, line 48 |  | skipping to change at page 84, line 37 |
| 10. Acknowledgments |  | 10. Acknowledgments |
| See Section 10 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-24 (work in |  | Routing", draft-ietf-httpbis-p1-messaging-25 (work in |
| progress), September 2013. |  | progress), November 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-24 (work in |  | draft-ietf-httpbis-p4-conditional-25 (work in |
| progress), September 2013. |  | progress), November 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-24 (work in |  | Requests", draft-ietf-httpbis-p5-range-25 (work in |
| progress), September 2013. |  | progress), November 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-24 (work in progress), |  | draft-ietf-httpbis-p6-cache-25 (work in progress), |
| September 2013. |  | November 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-24 (work in progress), |  | draft-ietf-httpbis-p7-auth-25 (work in progress), |
| September 2013. |  | November 2013. |
| [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |  |  |
| Format Specification version 3.3", RFC 1950, May 1996. |  |  |
| [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |  |  |
| Specification version 1.3", RFC 1951, May 1996. |  |  |
| [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and |  |  |
| G. Randers-Pehrson, "GZIP file format specification |  |  |
| version 4.3", RFC 1952, May 1996. |  |  |
| [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |  | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |
| Mail Extensions (MIME) Part One: Format of Internet |  | Mail Extensions (MIME) Part One: Format of Internet |
| Message Bodies", RFC 2045, November 1996. |  | Message Bodies", RFC 2045, November 1996. |
| [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet |  | [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet |
| Mail Extensions (MIME) Part Two: Media Types", |  | Mail Extensions (MIME) Part Two: Media Types", |
| RFC 2046, November 1996. |  | RFC 2046, November 1996. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| skipping to change at page 86, line 15 |  | skipping to change at page 85, line 42 |
| January 2008. |  | January 2008. |
| [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for |  | [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for |
| Identifying Languages", BCP 47, RFC 5646, |  | Identifying Languages", BCP 47, RFC 5646, |
| September 2009. |  | September 2009. |
| [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in |  | [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in |
| Internationalization in the IETF", BCP 166, RFC 6365, |  | Internationalization in the IETF", BCP 166, RFC 6365, |
| September 2011. |  | September 2011. |
| [Welch] Welch, T., "A Technique for High Performance Data |  |  |
| Compression", IEEE Computer 17(6), June 1984. |  |  |
| 11.2. Informative References |  | 11.2. Informative References |
| [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type |  | [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type |
| Specifications and Registration Procedures", BCP 13, |  | Specifications and Registration Procedures", BCP 13, |
| RFC 6838, January 2013. |  | RFC 6838, January 2013. |
|  |  | [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, |
|  |  | "Deprecating the "X-" Prefix and Similar Constructs in |
|  |  | Application Protocols", BCP 178, RFC 6648, June 2012. |
| [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Procedures for Message Header Fields", BCP 90, |  | Procedures for Message Header Fields", BCP 90, |
| RFC 3864, September 2004. |  | RFC 3864, September 2004. |
| [REST] Fielding, R., "Architectural Styles and the Design of |  | [REST] Fielding, R., "Architectural Styles and the Design of |
| Network-based Software Architectures", Doctoral |  | Network-based Software Architectures", Doctoral |
| Dissertation, University of California, Irvine , |  | Dissertation, University of California, Irvine , |
| September 2000, |  | September 2000, |
| <http://roy.gbiv.com/pubs/dissertation/top.htm>. |  | <http://roy.gbiv.com/pubs/dissertation/top.htm>. |
| [RFC1305] Mills, D., "Network Time Protocol (Version 3) |  |  |
| Specification, Implementation", RFC 1305, March 1992. |  |  |
| [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |  | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |
| "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |  | "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |
| May 1996. |  | May 1996. |
| [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet |  | [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet |
| Mail Extensions (MIME) Part Five: Conformance Criteria |  | Mail Extensions (MIME) Part Five: Conformance Criteria |
| and Examples", RFC 2049, November 1996. |  | and Examples", RFC 2049, November 1996. |
| [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and |  | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and |
| T. Berners-Lee, "Hypertext Transfer Protocol -- |  | T. Berners-Lee, "Hypertext Transfer Protocol -- |
| skipping to change at page 87, line 35 |  | skipping to change at page 87, line 11 |
| [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing |  | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing |
| an IANA Considerations Section in RFCs", BCP 26, |  | an IANA Considerations Section in RFCs", BCP 26, |
| RFC 5226, May 2008. |  | RFC 5226, May 2008. |
| [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |  | [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |
| October 2008. |  | October 2008. |
| [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", |  | [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", |
| RFC 5789, March 2010. |  | RFC 5789, March 2010. |
|  |  | [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, |
|  |  | "Network Time Protocol Version 4: Protocol and |
|  |  | Algorithms Specification", RFC 5905, June 2010. |
| [RFC5987] Reschke, J., "Character Set and Language Encoding for |  | [RFC5987] Reschke, J., "Character Set and Language Encoding for |
| Hypertext Transfer Protocol (HTTP) Header Field |  | Hypertext Transfer Protocol (HTTP) Header Field |
| Parameters", RFC 5987, August 2010. |  | Parameters", RFC 5987, August 2010. |
| [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. |  | [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. |
| [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, |  | [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, |
| April 2011. |  | April 2011. |
| [RFC6266] Reschke, J., "Use of the Content-Disposition Header |  | [RFC6266] Reschke, J., "Use of the Content-Disposition Header |
| skipping to change at page 94, line 4 |  | skipping to change at page 93, line 22 |
| Expect = "100-continue" |  | 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 |
| Max-Forwards = 1*DIGIT |  | Max-Forwards = 1*DIGIT |
| OWS = <OWS, defined in [Part1], Section 3.2.3> |  | OWS = <OWS, defined in [Part1], Section 3.2.3> |
| RWS = <RWS, defined in [Part1], Section 3.2.3> |  | RWS = <RWS, defined in [Part1], Section 3.2.3> |
| Referer = absolute-URI / partial-URI |  | Referer = absolute-URI / partial-URI |
| Retry-After = HTTP-date / delta-seconds |  | Retry-After = HTTP-date / delay-seconds |
| Server = product *( RWS ( product / comment ) ) |  | Server = product *( RWS ( product / comment ) ) |
| URI-reference = <URI-reference, defined in [Part1], Section 2.7> |  | URI-reference = <URI-reference, defined in [Part1], Section 2.7> |
| User-Agent = product *( RWS ( product / comment ) ) |  | User-Agent = product *( RWS ( product / comment ) ) |
| Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] |  | Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] |
| ) ) |  | ) ) |
| absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> |
| skipping to change at page 94, line 51 |  | skipping to change at page 94, line 22 |
| / %x46.72.69 ; Fri |  | / %x46.72.69 ; Fri |
| / %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 |  | delay-seconds = 1*DIGIT |
| 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 12 |  | skipping to change at page 95, line 32 |
| weight = OWS ";" OWS "q=" qvalue |  | weight = OWS ";" OWS "q=" qvalue |
| word = <word, defined in [Part1], Section 3.2.6> |  | word = <word, defined in [Part1], Section 3.2.6> |
| year = 4DIGIT |  | year = 4DIGIT |
| Appendix E. Change Log (to be removed by RFC Editor before publication) |  | Appendix E. Change Log (to be removed by RFC Editor before publication) |
| E.1. Since RFC 2616 |  | E.1. Since RFC 2616 |
| Changes up to the first Working Group Last Call draft are summarized |  | Changes up to the IETF Last Call draft are summarized in <http:// |
| in <http://trac.tools.ietf.org/html/ |  | trac.tools.ietf.org/html/ |
| draft-ietf-httpbis-p2-semantics-21#appendix-F>. |  | draft-ietf-httpbis-p2-semantics-24#appendix-E>. |
| E.2. Since draft-ietf-httpbis-p2-semantics-21 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/22>: "ETag (and |  |  |
| other metadata) in status messages" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/96>: "Conditional |  |  |
| GET text" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/146>: "Clarify |  |  |
| description of 405 (Not Allowed)" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing |  |  |
| heuristic caching for new status codes" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/315>: "method |  |  |
| semantics: retrieval/representation" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/388>: "User |  |  |
| confirmation for unsafe methods" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/404>: "Tentative |  |  |
| Status Codes" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/418>: "No-Transform" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/419>: "p2 editorial |  |  |
| feedback" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/424>: "Absence of |  |  |
| Accept-Encoding" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/428>: "Accept- |  |  |
| Language ordering for identical qvalues" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/432>: "Identify |  |  |
| additional status codes as cacheable by default" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/434>: "mention in |  |  |
| header field considerations that leading/trailing WS is lossy" |  |  |
| E.3. Since draft-ietf-httpbis-p2-semantics-22 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list |  |  |
| expansion in ABNF appendices" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/448>: "Fallback for |  |  |
| Accept-Language" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/449>: "Receiving a |  |  |
| higher minor HTTP version number" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/456>: "Language-tag |  |  |
| vs. language-range" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/457>: "Registering |  |  |
| x-gzip and x-deflate" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/459>: "RFC2774 and |  |  |
| method registrations" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/488>: "Selection |  |  |
| based upon request target" |  |  |
| E.4. Since draft-ietf-httpbis-p2-semantics-23 |  | E.2. Since draft-ietf-httpbis-p2-semantics-24 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/303>: "400 response |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/432>: "Review |
| isn't generic" |  | Cachability of Status Codes WRT 'Negative Caching'" |
| 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 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/499>: "RFC 1305 ref |
| 'Cacheable'?" |  | needs to be updated to 5905" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/478>: "MUSTs and |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/501>: "idempotency: |
| other feedback" |  | clarify 'effect'" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/487>: "Resubmission |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/503>: "APPSDIR |
| of 403" |  | review of draft-ietf-httpbis-p2-semantics-24" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/491>: "does 205 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/517>: "move IANA |
| allow chunked encoding?" |  | registrations to correct draft" |
| Index |  | Index |
| 1 |  | 1 |
| 1xx Informational (status code class) 50 |  | 1xx Informational (status code class) 50 |
| 2 |  | 2 |
| 2xx Successful (status code class) 51 |  | 2xx Successful (status code class) 51 |
| 3 |  | 3 |
| skipping to change at page 99, line 7 |  | skipping to change at page 96, line 44 |
| 203 Non-Authoritative Information (status code) 52 |  | 203 Non-Authoritative Information (status code) 52 |
| 204 No Content (status code) 53 |  | 204 No Content (status code) 53 |
| 205 Reset Content (status code) 53 |  | 205 Reset Content (status code) 53 |
| 3 |  | 3 |
| 300 Multiple Choices (status code) 55 |  | 300 Multiple Choices (status code) 55 |
| 301 Moved Permanently (status code) 56 |  | 301 Moved Permanently (status code) 56 |
| 302 Found (status code) 56 |  | 302 Found (status code) 56 |
| 303 See Other (status code) 57 |  | 303 See Other (status code) 57 |
| 305 Use Proxy (status code) 57 |  | 305 Use Proxy (status code) 57 |
| 306 (Unused) (status code) 57 |  | 306 (Unused) (status code) 58 |
| 307 Temporary Redirect (status code) 58 |  | 307 Temporary Redirect (status code) 58 |
| 4 |  | 4 |
| 400 Bad Request (status code) 58 |  | 400 Bad Request (status code) 58 |
| 402 Payment Required (status code) 58 |  | 402 Payment Required (status code) 58 |
| 403 Forbidden (status code) 58 |  | 403 Forbidden (status code) 59 |
| 404 Not Found (status code) 59 |  | 404 Not Found (status code) 59 |
| 405 Method Not Allowed (status code) 59 |  | 405 Method Not Allowed (status code) 59 |
| 406 Not Acceptable (status code) 59 |  | 406 Not Acceptable (status code) 59 |
| 408 Request Timeout (status code) 60 |  | 408 Request Timeout (status code) 60 |
| 409 Conflict (status code) 60 |  | 409 Conflict (status code) 60 |
| 410 Gone (status code) 60 |  | 410 Gone (status code) 60 |
| 411 Length Required (status code) 61 |  | 411 Length Required (status code) 61 |
| 413 Payload Too Large (status code) 61 |  | 413 Payload Too Large (status code) 61 |
| 414 URI Too Long (status code) 61 |  | 414 URI Too Long (status code) 61 |
| 415 Unsupported Media Type (status code) 61 |  | 415 Unsupported Media Type (status code) 62 |
| 417 Expectation Failed (status code) 62 |  | 417 Expectation Failed (status code) 62 |
| 426 Upgrade Required (status code) 62 |  | 426 Upgrade Required (status code) 62 |
| 5 |  | 5 |
| 500 Internal Server Error (status code) 62 |  | 500 Internal Server Error (status code) 63 |
| 501 Not Implemented (status code) 62 |  | 501 Not Implemented (status code) 63 |
| 502 Bad Gateway (status code) 63 |  | 502 Bad Gateway (status code) 63 |
| 503 Service Unavailable (status code) 63 |  | 503 Service Unavailable (status code) 63 |
| 504 Gateway Timeout (status code) 63 |  | 504 Gateway Timeout (status code) 63 |
| 505 HTTP Version Not Supported (status code) 63 |  | 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 |
| skipping to change at page 100, line 42 |  | skipping to change at page 98, line 30 |
| 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 67 |  | Date 67 |
| date1 66 |  | date1 66 |
| day 66 |  | day 66 |
| day-name 66 |  | day-name 66 |
| day-name-l 66 |  | day-name-l 66 |
| delta-seconds 70 |  | delay-seconds 70 |
| Expect 34 |  | Expect 34 |
| From 44 |  | From 44 |
| GMT 66 |  | GMT 66 |
| hour 66 |  | hour 66 |
| HTTP-date 64 |  | HTTP-date 64 |
| IMF-fixdate 66 |  | IMF-fixdate 66 |
| language-range 42 |  | language-range 42 |
| language-tag 13 |  | language-tag 13 |
| Location 68 |  | Location 68 |
| Max-Forwards 36 |  | Max-Forwards 36 |
End of changes. 64 change blocks.
| 216 lines changed or deleted |  | 135 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/