| draft-ietf-httpbis-p2-semantics-01.txt |  | draft-ietf-httpbis-p2-semantics-02.txt |
--- | --- | --- | --- | ---
| Network Working Group R. Fielding, Ed. |  | Network Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Intended status: Standards Track One Laptop per Child |  | Intended status: Standards Track One Laptop per Child |
| Expires: July 15, 2008 J. Mogul |  | Expires: August 27, 2008 J. Mogul |
| HP |  | HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe Systems |  | Adobe Systems |
| P. Leach |  | P. Leach |
| Microsoft |  | Microsoft |
| T. Berners-Lee |  | T. Berners-Lee |
| W3C/MIT |  | W3C/MIT |
| Y. Lafon, Ed. |  | Y. Lafon, Ed. |
| W3C |  | W3C |
| J. Reschke, Ed. |  | J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| January 12, 2008 |  | February 24, 2008 |
| HTTP/1.1, part 2: Message Semantics |  | HTTP/1.1, part 2: Message Semantics |
| draft-ietf-httpbis-p2-semantics-01 |  | draft-ietf-httpbis-p2-semantics-02 |
| Status of this Memo |  | Status of this Memo |
| By submitting this Internet-Draft, each author represents that any |  | By submitting this Internet-Draft, each author represents that any |
| applicable patent or other IPR claims of which he or she is aware |  | applicable patent or other IPR claims of which he or she is aware |
| have been or will be disclosed, and any of which he or she becomes |  | have been or will be disclosed, and any of which he or she becomes |
| aware will be disclosed, in accordance with Section 6 of BCP 79. |  | aware will be disclosed, in accordance with Section 6 of BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF), its areas, and its working groups. Note that |  | Task Force (IETF), its areas, and its working groups. Note that |
| skipping to change at page 1, line 49 |  | skipping to change at page 1, line 49 |
| 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." |
| The list of current Internet-Drafts can be accessed at |  | The list of current Internet-Drafts can be accessed at |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  | http://www.ietf.org/ietf/1id-abstracts.txt. |
| The list of Internet-Draft Shadow Directories can be accessed at |  | The list of Internet-Draft Shadow Directories can be accessed at |
| http://www.ietf.org/shadow.html. |  | http://www.ietf.org/shadow.html. |
| This Internet-Draft will expire on July 15, 2008. |  | This Internet-Draft will expire on August 27, 2008. |
| Copyright Notice |  | Copyright Notice |
| Copyright (C) The IETF Trust (2008). |  | Copyright (C) The IETF Trust (2008). |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypermedia information |  | protocol for distributed, collaborative, hypermedia information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| skipping to change at page 3, line 9 |  | skipping to change at page 3, line 9 |
| This draft incorporates those issue resolutions that were either |  | This draft incorporates those issue resolutions that were either |
| collected in the original RFC2616 errata list |  | collected in the original RFC2616 errata list |
| (<http://purl.org/NET/http-errata>), or which were agreed upon on the |  | (<http://purl.org/NET/http-errata>), or which were agreed upon on the |
| mailing list between October 2006 and November 2007 (as published in |  | mailing list between October 2006 and November 2007 (as published in |
| "draft-lafon-rfc2616bis-03"). |  | "draft-lafon-rfc2616bis-03"). |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 2. Notational Conventions and Generic Grammar . . . . . . . . . . 6 |
| 3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 |
| 4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 7 |  | 4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 8 |
| 5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 8 |  | 5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 9 |
| 6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 10 |  | 6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 11 |
| 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 |  | 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 11 |  | 8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 12 |
| 8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 11 |  | 8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 12 |
| 8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 11 |  | 8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 12 |
| 8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 11 |  | 8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 12 |
| 8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 |
| 8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 |  | 8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 17 |  | 9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18 |
| 9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 17 |  | 9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 18 |
| 9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 17 |  | 9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 18 |
| 9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 18 |  | 9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 19 |
| 9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 18 |  | 9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 19 |
| 9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 18 |  | 9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 19 |
| 9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 19 |  | 9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 20 |
| 9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 19 |  | 9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 20 |
| 9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 19 |  | 9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 20 |
| 9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 20 |  | 9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 21 |
| 9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 20 |  | 9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 21 |
| 9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 20 |  | 9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 21 |
| 9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 20 |  | 9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 21 |
| 9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 21 |  | 9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 22 |
| 9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 21 |  | 9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 22 |
| 9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 22 |  | 9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 23 |
| 9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 22 |  | 9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 23 |
| 9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 22 |  | 9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 23 |
| 9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 23 |  | 9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 24 |
| 9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 23 |  | 9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 24 |
| 9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 23 |  | 9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 24 |
| 9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 24 |  | 9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 25 |
| 9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 24 |  | 9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 25 |
| 9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 24 |  | 9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 25 |
| 9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 24 |  | 9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 25 |
| 9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 24 |  | 9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 25 |
| 9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 24 |  | 9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 25 |
| 9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 24 |  | 9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 25 |
| 9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 25 |  | 9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 26 |
| 9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 25 |  | 9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 26 |
| 9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 25 |  | 9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 26 |
| 9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 26 |  | 9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 26 |  | 9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 27 |
| 9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 26 |  | 9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 27 |
| 9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 26 |  | 9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 27 |
| 9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 27 |  | 9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 28 |
| 9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 27 |  | 9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 28 |
| 9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 27 |  | 9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 28 |
| 9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 27 |  | 9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 28 |
| 9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 27 |  | 9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 28 |
| 9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 27 |  | 9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 28 |
| 9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 28 |  | 9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 29 |
| 9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 28 |  | 9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 29 |
| 9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 28 |  | 9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 29 |
| 9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 28 |  | 9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 29 |
| 9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 28 |  | 9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 29 |
| 10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 29 |  | 10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 30 |
| 10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 30 |
| 10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 30 |
| 10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 |  | 10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 |
| 10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 34 |
| 10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 34 |
| 10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 34 |  | 10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 35 |
| 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 |  | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 |
| 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 |  | 12. Security Considerations . . . . . . . . . . . . . . . . . . . 35 |
| 12.1. Transfer of Sensitive Information . . . . . . . . . . . . 34 |  | 12.1. Transfer of Sensitive Information . . . . . . . . . . . . 35 |
| 12.2. Encoding Sensitive Information in URI's . . . . . . . . . 35 |  | 12.2. Encoding Sensitive Information in URIs . . . . . . . . . . 36 |
| 12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 36 |  | 12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 37 |
| 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 |  | 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 |
| 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 |  | 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 |
| 14.1. Normative References . . . . . . . . . . . . . . . . . . . 36 |  | 14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 |
| 14.2. Informative References . . . . . . . . . . . . . . . . . . 37 |  | 14.2. Informative References . . . . . . . . . . . . . . . . . . 38 |
| Appendix A. Compatibility with Previous Versions . . . . . . . . 37 |  | Appendix A. Compatibility with Previous Versions . . . . . . . . 38 |
| A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 37 |  | A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 38 |
| A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 38 |  | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 39 |
| Appendix B. Change Log (to be removed by RFC Editor before |  | Appendix B. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 39 |  | publication) . . . . . . . . . . . . . . . . . . . . 40 |
| B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 39 |  | B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 40 |
| B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 39 |  | B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 40 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 |  | B.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 41 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 47 |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 |
|  |  | Intellectual Property and Copyright Statements . . . . . . . . . . 48 |
| 1. Introduction |  | 1. Introduction |
| This document defines HTTP/1.1 request and response semantics. Each |  | This document defines HTTP/1.1 request and response semantics. Each |
| HTTP message, as defined in [Part1], is in the form of either a |  | HTTP message, as defined in [Part1], is in the form of either a |
| request or a response. An HTTP server listens on a connection for |  | request or a response. An HTTP server listens on a connection for |
| HTTP requests and responds to each request, in the order received on |  | HTTP requests and responds to each request, in the order received on |
| that connection, with one or more HTTP response messages. This |  | that connection, with one or more HTTP response messages. This |
| document defines the commonly agreed upon semantics of the HTTP |  | document defines the commonly agreed upon semantics of the HTTP |
| uniform interface, the intentions defined by each request method, and |  | uniform interface, the intentions defined by each request method, and |
| skipping to change at page 6, line 42 |  | skipping to change at page 6, line 42 |
| An implementation is not compliant if it fails to satisfy one or more |  | An implementation is not compliant if it fails to satisfy one or more |
| of the MUST or REQUIRED level requirements for the protocols it |  | of the MUST or REQUIRED level requirements for the protocols it |
| implements. An implementation that satisfies all the MUST or |  | implements. An implementation that satisfies all the MUST or |
| REQUIRED level and all the SHOULD level requirements for its |  | REQUIRED level and all the SHOULD level requirements for its |
| protocols is said to be "unconditionally compliant"; one that |  | protocols is said to be "unconditionally compliant"; one that |
| satisfies all the MUST level requirements but not all the SHOULD |  | satisfies all the MUST level requirements but not all the SHOULD |
| level requirements for its protocols is said to be "conditionally |  | level requirements for its protocols is said to be "conditionally |
| compliant." |  | compliant." |
| 2. Product Tokens |  | 2. Notational Conventions and Generic Grammar |
| Product tokens are used to allow communicating applications to |  | This specification uses the ABNF syntax defined in Section 2.1 of |
| identify themselves by software name and version. Most fields using |  | [Part1] and the core rules defined in Section 2.2 of [Part1]: |
| product tokens also allow sub-products which form a significant part |  | [[abnf.dep: ABNF syntax and basic rules will be adopted from RFC |
| of the application to be listed, separated by white space. By |  | 5234, see <http://tools.ietf.org/wg/httpbis/trac/ticket/36>.]] |
| convention, the products are listed in order of their significance |  |  |
| for identifying the application. |  |  |
| product = token ["/" product-version] |  | DIGIT = <DIGIT, defined in [Part1], Section 2.2> |
| product-version = token |  | comment = <comment, defined in [Part1], Section 2.2> |
|  |  | quoted-string = <quoted-string, defined in [Part1], Section 2.2> |
|  |  | token = <token, defined in [Part1], Section 2.2> |
| Examples: |  | The ABNF rules below are defined in other parts: |
| User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |  | absoluteURI = <absoluteURI, defined in [Part1], Section 3.2.1> |
| Server: Apache/0.8.4 |  | fragment = <fragment, defined in [Part1], Section 3.2.1> |
|  |  | Host = <Host, defined in [Part1], Section 8.4> |
|  |  | HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1> |
|  |  | product = <product, defined in [Part1], Section 3.5> |
|  |  | relativeURI = <relativeURI, defined in [Part1], Section 3.2.1> |
|  |  | TE = <TE, defined in [Part1], Section 8.8> |
| Product tokens SHOULD be short and to the point. They MUST NOT be |  | Accept = <Accept, defined in [Part3], Section 6.1> |
| used for advertising or other non-essential information. Although |  | Accept-Charset = |
| any token character MAY appear in a product-version, this token |  | <Accept-Charset, defined in [Part3], Section 6.2> |
| SHOULD only be used for a version identifier (i.e., successive |  | Accept-Encoding = |
| versions of the same product SHOULD only differ in the product- |  | <Accept-Encoding, defined in [Part3], Section 6.3> |
| version portion of the product value). |  | Accept-Language = |
|  |  | <Accept-Language, defined in [Part3], Section 6.4> |
|  |  | ETag = <ETag, defined in [Part4], Section 7.1> |
|  |  | If-Match = <If-Match, defined in [Part4], Section 7.2> |
|  |  | If-Modified-Since = |
|  |  | <If-Modified-Since, defined in [Part4], Section 7.3> |
|  |  | If-None-Match = <If-None-Match, defined in [Part4], Section 7.4> |
|  |  | If-Unmodified-Since = |
|  |  | <If-Unmodified-Since, defined in [Part4], Section 7.5> |
|  |  | Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 6.1> |
|  |  | If-Range = <If-Range, defined in [Part5], Section 6.3> |
|  |  | Range = <Range, defined in [Part5], Section 6.4> |
|  |  | Age = <Age, defined in [Part6], Section 16.1> |
|  |  | Vary = <Vary, defined in [Part6], Section 16.5> |
|  |  | Authorization = <Authorization, defined in [Part7], Section 4.1> |
|  |  | Proxy-Authenticate = |
|  |  | <Proxy-Authenticate, defined in [Part7], Section 4.2> |
|  |  | Proxy-Authorization = |
|  |  | <Proxy-Authorization, defined in [Part7], Section 4.3> |
|  |  | WWW-Authenticate = |
|  |  | <WWW-Authenticate, defined in [Part7], Section 4.4> |
| 3. Method |  | 3. Method |
| The Method token indicates the method to be performed on the resource |  | The Method token indicates the method to be performed on the resource |
| identified by the Request-URI. The method is case-sensitive. |  | identified by the Request-URI. The method is case-sensitive. |
| Method = "OPTIONS" ; Section 8.2 |  | Method = "OPTIONS" ; Section 8.2 |
| | "GET" ; Section 8.3 |  | | "GET" ; Section 8.3 |
| | "HEAD" ; Section 8.4 |  | | "HEAD" ; Section 8.4 |
| | "POST" ; Section 8.5 |  | | "POST" ; Section 8.5 |
| skipping to change at page 8, line 9 |  | skipping to change at page 9, line 5 |
| those specified in Section 8. |  | those specified in Section 8. |
| 4. Request Header Fields |  | 4. Request Header Fields |
| The request-header fields allow the client to pass additional |  | The request-header fields allow the client to pass additional |
| information about the request, and about the client itself, to the |  | information about the request, and about the client itself, to the |
| server. These fields act as request modifiers, with semantics |  | server. These fields act as request modifiers, with semantics |
| equivalent to the parameters on a programming language method |  | equivalent to the parameters on a programming language method |
| invocation. |  | invocation. |
| request-header = Accept ; [Part3], Section 5.1 |  | request-header = Accept ; [Part3], Section 6.1 |
| | Accept-Charset ; [Part3], Section 5.2 |  | | Accept-Charset ; [Part3], Section 6.2 |
| | Accept-Encoding ; [Part3], Section 5.3 |  | | Accept-Encoding ; [Part3], Section 6.3 |
| | Accept-Language ; [Part3], Section 5.4 |  | | Accept-Language ; [Part3], Section 6.4 |
| | Authorization ; [Part7], Section 3.1 |  | | Authorization ; [Part7], Section 4.1 |
| | Expect ; Section 10.2 |  | | Expect ; Section 10.2 |
| | From ; Section 10.3 |  | | From ; Section 10.3 |
| | Host ; [Part1], Section 8.4 |  | | Host ; [Part1], Section 8.4 |
| | If-Match ; [Part4], Section 6.2 |  | | If-Match ; [Part4], Section 7.2 |
| | If-Modified-Since ; [Part4], Section 6.3 |  | | If-Modified-Since ; [Part4], Section 7.3 |
| | If-None-Match ; [Part4], Section 6.4 |  | | If-None-Match ; [Part4], Section 7.4 |
| | If-Range ; [Part5], Section 5.3 |  | | If-Range ; [Part5], Section 6.3 |
| | If-Unmodified-Since ; [Part4], Section 6.5 |  | | If-Unmodified-Since ; [Part4], Section 7.5 |
| | Max-Forwards ; Section 10.5 |  | | Max-Forwards ; Section 10.5 |
| | Proxy-Authorization ; [Part7], Section 3.3 |  | | Proxy-Authorization ; [Part7], Section 4.3 |
| | Range ; [Part5], Section 5.4 |  | | Range ; [Part5], Section 6.4 |
| | Referer ; Section 10.6 |  | | Referer ; Section 10.6 |
| | TE ; [Part1], Section 8.8 |  | | TE ; [Part1], Section 8.8 |
| | User-Agent ; Section 10.9 |  | | User-Agent ; Section 10.9 |
| Request-header field names can be extended reliably only in |  | Request-header field names can be extended reliably only in |
| combination with a change in the protocol version. However, new or |  | combination with a change in the protocol version. However, new or |
| experimental header fields MAY be given the semantics of request- |  | experimental header fields MAY be given the semantics of request- |
| header fields if all parties in the communication recognize them to |  | header fields if all parties in the communication recognize them to |
| be request-header fields. Unrecognized header fields are treated as |  | be request-header fields. Unrecognized header fields are treated as |
| entity-header fields. |  | entity-header fields. |
| skipping to change at page 10, line 23 |  | skipping to change at page 11, line 23 |
| with the response, since that entity is likely to include human- |  | with the response, since that entity is likely to include human- |
| readable information which will explain the unusual status. |  | readable information which will explain the unusual status. |
| 6. Response Header Fields |  | 6. Response Header Fields |
| The response-header fields allow the server to pass additional |  | The response-header fields allow the server to pass additional |
| information about the response which cannot be placed in the Status- |  | information about the response which cannot be placed in the Status- |
| Line. These header fields give information about the server and |  | Line. These header fields give information about the server and |
| about further access to the resource identified by the Request-URI. |  | about further access to the resource identified by the Request-URI. |
| response-header = Accept-Ranges ; [Part5], Section 5.1 |  | response-header = Accept-Ranges ; [Part5], Section 6.1 |
| | Age ; [Part6], Section 15.1 |  | | Age ; [Part6], Section 16.1 |
| | ETag ; [Part4], Section 6.1 |  | | ETag ; [Part4], Section 7.1 |
| | Location ; Section 10.4 |  | | Location ; Section 10.4 |
| | Proxy-Authenticate ; [Part7], Section 3.2 |  | | Proxy-Authenticate ; [Part7], Section 4.2 |
| | Retry-After ; Section 10.7 |  | | Retry-After ; Section 10.7 |
| | Server ; Section 10.8 |  | | Server ; Section 10.8 |
| | Vary ; [Part6], Section 15.5 |  | | Vary ; [Part6], Section 16.5 |
| | WWW-Authenticate ; [Part7], Section 3.4 |  | | WWW-Authenticate ; [Part7], Section 4.4 |
| Response-header field names can be extended reliably only in |  | Response-header field names can be extended reliably only in |
| combination with a change in the protocol version. However, new or |  | combination with a change in the protocol version. However, new or |
| experimental header fields MAY be given the semantics of response- |  | experimental header fields MAY be given the semantics of response- |
| header fields if all parties in the communication recognize them to |  | header fields if all parties in the communication recognize them to |
| be response-header fields. Unrecognized header fields are treated as |  | be response-header fields. Unrecognized header fields are treated as |
| entity-header fields. |  | entity-header fields. |
| 7. Entity |  | 7. Entity |
| skipping to change at page 11, line 13 |  | skipping to change at page 12, line 13 |
| present, as described in Section 4.3 of [Part1]. The entity-body is |  | present, as described in Section 4.3 of [Part1]. The entity-body is |
| obtained from the message-body by decoding any Transfer-Encoding that |  | obtained from the message-body by decoding any Transfer-Encoding that |
| might have been applied to ensure safe and proper transfer of the |  | might have been applied to ensure safe and proper transfer of the |
| message. |  | message. |
| 8. Method Definitions |  | 8. Method Definitions |
| The set of common methods for HTTP/1.1 is defined below. Although |  | The set of common methods for HTTP/1.1 is defined below. Although |
| this set can be expanded, additional methods cannot be assumed to |  | this set can be expanded, additional methods cannot be assumed to |
| share the same semantics for separately extended clients and servers. |  | share the same semantics for separately extended clients and servers. |
| The Host request-header field (Section 8.4 of [Part1]) MUST accompany |  |  |
| all HTTP/1.1 requests. |  |  |
| 8.1. Safe and Idempotent Methods |  | 8.1. Safe and Idempotent Methods |
| 8.1.1. Safe Methods |  | 8.1.1. Safe Methods |
| Implementors should be aware that the software represents the user in |  | Implementors should be aware that the software represents the user in |
| their interactions over the Internet, and should be careful to allow |  | their interactions over the Internet, and should be careful to allow |
| the user to be aware of any actions they might take which may have an |  | the user to be aware of any actions they might take which may have an |
| unexpected significance to themselves or others. |  | unexpected significance to themselves or others. |
| skipping to change at page 13, line 37 |  | skipping to change at page 14, line 34 |
| If-Match, If-None-Match, or If-Range header field. A conditional GET |  | If-Match, If-None-Match, or If-Range header field. A conditional GET |
| method requests that the entity be transferred only under the |  | method requests that the entity be transferred only under the |
| circumstances described by the conditional header field(s). The |  | circumstances described by the conditional header field(s). The |
| conditional GET method is intended to reduce unnecessary network |  | conditional GET method is intended to reduce unnecessary network |
| usage by allowing cached entities to be refreshed without requiring |  | usage by allowing cached entities to be refreshed without requiring |
| multiple requests or transferring data already held by the client. |  | multiple requests or transferring data already held by the client. |
| The semantics of the GET method change to a "partial GET" if the |  | The semantics of the GET method change to a "partial GET" if the |
| request message includes a Range header field. A partial GET |  | request message includes a Range header field. A partial GET |
| requests that only part of the entity be transferred, as described in |  | requests that only part of the entity be transferred, as described in |
| Section 5.4 of [Part5]. The partial GET method is intended to reduce |  | Section 6.4 of [Part5]. The partial GET method is intended to reduce |
| unnecessary network usage by allowing partially-retrieved entities to |  | unnecessary network usage by allowing partially-retrieved entities to |
| be completed without transferring data already held by the client. |  | be completed without transferring data already held by the client. |
| The response to a GET request is cacheable if and only if it meets |  | The response to a GET request is cacheable if and only if it meets |
| the requirements for HTTP caching described in [Part6]. |  | the requirements for HTTP caching described in [Part6]. |
| See Section 12.2 for security considerations when used for forms. |  | See Section 12.2 for security considerations when used for forms. |
| 8.4. HEAD |  | 8.4. HEAD |
| skipping to change at page 15, line 14 |  | skipping to change at page 16, line 14 |
| 8.6. PUT |  | 8.6. PUT |
| The PUT method requests that the enclosed entity be stored under the |  | The PUT method requests that the enclosed entity be stored under the |
| supplied Request-URI. If the Request-URI refers to an already |  | supplied Request-URI. If the Request-URI refers to an already |
| existing resource, the enclosed entity SHOULD be considered as a |  | existing resource, the enclosed entity SHOULD be considered as a |
| modified version of the one residing on the origin server. If the |  | modified version of the one residing on the origin server. If the |
| Request-URI does not point to an existing resource, and that URI is |  | Request-URI does not point to an existing resource, and that URI is |
| capable of being defined as a new resource by the requesting user |  | capable of being defined as a new resource by the requesting user |
| agent, the origin server can create the resource with that URI. If a |  | agent, the origin server can create the resource with that URI. If a |
| new resource is created, the origin server MUST inform the user agent |  | new resource is created at the Request-URI, the origin server MUST |
| via the 201 (Created) response. If an existing resource is modified, |  | inform the user agent via the 201 (Created) response. If an existing |
| either the 200 (OK) or 204 (No Content) response codes SHOULD be sent |  | resource is modified, either the 200 (OK) or 204 (No Content) |
| to indicate successful completion of the request. If the resource |  | response codes SHOULD be sent to indicate successful completion of |
| could not be created or modified with the Request-URI, an appropriate |  | the request. If the resource could not be created or modified with |
| error response SHOULD be given that reflects the nature of the |  | the Request-URI, an appropriate error response SHOULD be given that |
| problem. The recipient of the entity MUST NOT ignore any Content-* |  | reflects the nature of the problem. The recipient of the entity MUST |
| (e.g. Content-Range) headers that it does not understand or |  | NOT ignore any Content-* (e.g. Content-Range) headers that it does |
| implement and MUST return a 501 (Not Implemented) response in such |  | not understand or implement and MUST return a 501 (Not Implemented) |
| cases. |  | response in such cases. |
| If the request passes through a cache and the Request-URI identifies |  | If the request passes through a cache and the Request-URI identifies |
| one or more currently cached entities, those entries SHOULD be |  | one or more currently cached entities, those entries SHOULD be |
| treated as stale. Responses to this method are not cacheable. |  | treated as stale. Responses to this method are not cacheable. |
| The fundamental difference between the POST and PUT requests is |  | The fundamental difference between the POST and PUT requests is |
| reflected in the different meaning of the Request-URI. The URI in a |  | reflected in the different meaning of the Request-URI. The URI in a |
| POST request identifies the resource that will handle the enclosed |  | POST request identifies the resource that will handle the enclosed |
| entity. That resource might be a data-accepting process, a gateway |  | entity. That resource might be a data-accepting process, a gateway |
| to some other protocol, or a separate entity that accepts |  | to some other protocol, or a separate entity that accepts |
| skipping to change at page 18, line 8 |  | skipping to change at page 19, line 8 |
| been received and has not yet been rejected by the server. The |  | been received and has not yet been rejected by the server. The |
| client SHOULD continue by sending the remainder of the request or, if |  | client SHOULD continue by sending the remainder of the request or, if |
| the request has already been completed, ignore this response. The |  | the request has already been completed, ignore this response. The |
| server MUST send a final response after the request has been |  | server MUST send a final response after the request has been |
| completed. See Section 7.2.3 of [Part1] for detailed discussion of |  | completed. See Section 7.2.3 of [Part1] for detailed discussion of |
| the use and handling of this status code. |  | the use and handling of this status code. |
| 9.1.2. 101 Switching Protocols |  | 9.1.2. 101 Switching Protocols |
| The server understands and is willing to comply with the client's |  | The server understands and is willing to comply with the client's |
| request, via the Upgrade message header field (Section 5.4 of |  | request, via the Upgrade message header field (Section 6.4 of |
| [Part5]), for a change in the application protocol being used on this |  | [Part5]), for a change in the application protocol being used on this |
| connection. The server will switch protocols to those defined by the |  | connection. The server will switch protocols to those defined by the |
| response's Upgrade header field immediately after the empty line |  | response's Upgrade header field immediately after the empty line |
| which terminates the 101 response. |  | which terminates the 101 response. |
| The protocol SHOULD be switched only when it is advantageous to do |  | The protocol SHOULD be switched only when it is advantageous to do |
| so. For example, switching to a newer version of HTTP is |  | so. For example, switching to a newer version of HTTP is |
| advantageous over older versions, and switching to a real-time, |  | advantageous over older versions, and switching to a real-time, |
| synchronous protocol might be advantageous when delivering resources |  | synchronous protocol might be advantageous when delivering resources |
| that use such features. |  | that use such features. |
| skipping to change at page 19, line 8 |  | skipping to change at page 20, line 8 |
| SHOULD include an entity containing a list of resource |  | SHOULD include an entity containing a list of resource |
| characteristics and location(s) from which the user or user agent can |  | characteristics and location(s) from which the user or user agent can |
| choose the one most appropriate. The entity format is specified by |  | choose the one most appropriate. The entity format is specified by |
| the media type given in the Content-Type header field. The origin |  | the media type given in the Content-Type header field. The origin |
| server MUST create the resource before returning the 201 status code. |  | server MUST create the resource before returning the 201 status code. |
| If the action cannot be carried out immediately, the server SHOULD |  | If the action cannot be carried out immediately, the server SHOULD |
| respond with 202 (Accepted) response instead. |  | respond with 202 (Accepted) response instead. |
| A 201 response MAY contain an ETag response header field indicating |  | A 201 response MAY contain an ETag response header field indicating |
| the current value of the entity tag for the requested variant just |  | the current value of the entity tag for the requested variant just |
| created, see Section 6.1 of [Part4]. |  | created, see Section 7.1 of [Part4]. |
| 9.2.3. 202 Accepted |  | 9.2.3. 202 Accepted |
| The request has been accepted for processing, but the processing has |  | The request has been accepted for processing, but the processing has |
| not been completed. The request might or might not eventually be |  | not been completed. The request might or might not eventually be |
| acted upon, as it might be disallowed when processing actually takes |  | acted upon, as it might be disallowed when processing actually takes |
| place. There is no facility for re-sending a status code from an |  | place. There is no facility for re-sending a status code from an |
| asynchronous operation such as this. |  | asynchronous operation such as this. |
| The 202 response is intentionally non-committal. Its purpose is to |  | The 202 response is intentionally non-committal. Its purpose is to |
| skipping to change at page 20, line 41 |  | skipping to change at page 21, line 41 |
| Note: previous versions of this specification recommended a |  | Note: previous versions of this specification recommended a |
| maximum of five redirections. Content developers should be aware |  | maximum of five redirections. Content developers should be aware |
| that there might be clients that implement such a fixed |  | that there might be clients that implement such a fixed |
| limitation. |  | limitation. |
| 9.3.1. 300 Multiple Choices |  | 9.3.1. 300 Multiple Choices |
| The requested resource corresponds to any one of a set of |  | The requested resource corresponds to any one of a set of |
| representations, each with its own specific location, and agent- |  | representations, each with its own specific location, and agent- |
| driven negotiation information (Section 4 of [Part3]) is being |  | driven negotiation information (Section 5 of [Part3]) is being |
| provided so that the user (or user agent) can select a preferred |  | provided so that the user (or user agent) can select a preferred |
| representation and redirect its request to that location. |  | representation and redirect its request to that location. |
| Unless it was a HEAD request, the response SHOULD include an entity |  | Unless it was a HEAD request, the response SHOULD include an entity |
| containing a list of resource characteristics and location(s) from |  | containing a list of resource characteristics and location(s) from |
| which the user or user agent can choose the one most appropriate. |  | which the user or user agent can choose the one most appropriate. |
| The entity format is specified by the media type given in the |  | The entity format is specified by the media type given in the |
| Content-Type header field. Depending upon the format and the |  | Content-Type header field. Depending upon the format and the |
| capabilities of the user agent, selection of the most appropriate |  | capabilities of the user agent, selection of the most appropriate |
| choice MAY be performed automatically. However, this specification |  | choice MAY be performed automatically. However, this specification |
| skipping to change at page 27, line 25 |  | skipping to change at page 28, line 25 |
| buffers for reading or manipulating the Request-URI. |  | buffers for reading or manipulating the Request-URI. |
| 9.4.16. 415 Unsupported Media Type |  | 9.4.16. 415 Unsupported Media Type |
| The server is refusing to service the request because the entity of |  | The server is refusing to service the request because the entity of |
| the request is in a format not supported by the requested resource |  | the request is in a format not supported by the requested resource |
| for the requested method. |  | for the requested method. |
| 9.4.17. 416 Requested Range Not Satisfiable |  | 9.4.17. 416 Requested Range Not Satisfiable |
| The request included a Range request-header field (Section 5.4 of |  | The request included a Range request-header field (Section 6.4 of |
| [Part5]) and none of the range-specifier values in this field overlap |  | [Part5]) and none of the range-specifier values in this field overlap |
| the current extent of the selected resource. |  | the current extent of the selected resource. |
| 9.4.18. 417 Expectation Failed |  | 9.4.18. 417 Expectation Failed |
| The expectation given in an Expect request-header field (see |  | The expectation given in an Expect request-header field (see |
| Section 10.2) could not be met by this server, or, if the server is a |  | Section 10.2) could not be met by this server, or, if the server is a |
| proxy, the server has unambiguous evidence that the request could not |  | proxy, the server has unambiguous evidence that the request could not |
| be met by the next-hop server. |  | be met by the next-hop server. |
| skipping to change at page 28, line 43 |  | skipping to change at page 29, line 43 |
| The server, while acting as a gateway or proxy, did not receive a |  | The server, while acting as a gateway or proxy, did not receive a |
| timely response from the upstream server specified by the URI (e.g. |  | timely response from the upstream server specified by the URI (e.g. |
| HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed |  | HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed |
| to access in attempting to complete the request. |  | to access in attempting to complete the request. |
| Note: Note to implementors: some deployed proxies are known to |  | Note: Note to implementors: some deployed proxies are known to |
| return 400 or 500 when DNS lookups time out. |  | return 400 or 500 when DNS lookups time out. |
| 9.5.6. 505 HTTP Version Not Supported |  | 9.5.6. 505 HTTP Version Not Supported |
| The server does not support, or refuses to support, the HTTP protocol |  | The server does not support, or refuses to support, the protocol |
| version that was used in the request message. The server is |  | version that was used in the request message. The server is |
| indicating that it is unable or unwilling to complete the request |  | indicating that it is unable or unwilling to complete the request |
| using the same major version as the client, as described in Section |  | using the same major version as the client, as described in Section |
| 3.1 of [Part1], other than with this error message. The response |  | 3.1 of [Part1], other than with this error message. The response |
| SHOULD contain an entity describing why that version is not supported |  | SHOULD contain an entity describing why that version is not supported |
| and what other protocols are supported by that server. |  | and what other protocols are supported by that server. |
| 10. Header Field Definitions |  | 10. Header Field Definitions |
| This section defines the syntax and semantics of HTTP/1.1 header |  | This section defines the syntax and semantics of HTTP/1.1 header |
| skipping to change at page 30, line 43 |  | skipping to change at page 31, line 43 |
| 10.3. From |  | 10.3. From |
| The From request-header field, if given, SHOULD contain an Internet |  | The From request-header field, if given, SHOULD contain an Internet |
| e-mail address for the human user who controls the requesting user |  | e-mail address for the human user who controls the requesting user |
| agent. The address SHOULD be machine-usable, as defined by "mailbox" |  | agent. The address SHOULD be machine-usable, as defined by "mailbox" |
| in Section 3.4 of [RFC2822]: |  | in Section 3.4 of [RFC2822]: |
| From = "From" ":" mailbox |  | From = "From" ":" mailbox |
|  |  | mailbox = <mailbox, defined in [RFC2822], Section 3.4> |
| An example is: |  | An example is: |
| From: webmaster@example.org |  | From: webmaster@example.org |
| This header field MAY be used for logging purposes and as a means for |  | This header field MAY be used for logging purposes and as a means for |
| identifying the source of invalid or unwanted requests. It SHOULD |  | identifying the source of invalid or unwanted requests. It SHOULD |
| NOT be used as an insecure form of access protection. The |  | NOT be used as an insecure form of access protection. The |
| interpretation of this field is that the request is being performed |  | interpretation of this field is that the request is being performed |
| on behalf of the person given, who accepts responsibility for the |  | on behalf of the person given, who accepts responsibility for the |
| method performed. In particular, robot agents SHOULD include this |  | method performed. In particular, robot agents SHOULD include this |
| skipping to change at page 31, line 35 |  | skipping to change at page 32, line 37 |
| by the request. For 3xx responses, the location SHOULD indicate the |  | by the request. For 3xx responses, the location SHOULD indicate the |
| server's preferred URI for automatic redirection to the resource. |  | server's preferred URI for automatic redirection to the resource. |
| The field value consists of a single absolute URI. |  | The field value consists of a single absolute URI. |
| Location = "Location" ":" absoluteURI [ "#" fragment ] |  | Location = "Location" ":" absoluteURI [ "#" fragment ] |
| An example is: |  | An example is: |
| Location: http://www.example.org/pub/WWW/People.html |  | Location: http://www.example.org/pub/WWW/People.html |
| Note: The Content-Location header field (Section 5.7 of [Part3]) |  | Note: The Content-Location header field (Section 6.7 of [Part3]) |
| differs from Location in that the Content-Location identifies the |  | differs from Location in that the Content-Location identifies the |
| original location of the entity enclosed in the request. It is |  | original location of the entity enclosed in the request. It is |
| therefore possible for a response to contain header fields for |  | therefore possible for a response to contain header fields for |
| both Location and Content-Location. |  | both Location and Content-Location. |
| There are circumstances in which a fragment identifier in a Location |  | There are circumstances in which a fragment identifier in a Location |
| URL would not be appropriate: |  | URL would not be appropriate: |
| o With a 201 Created response, because in this usage the Location |  | o With a 201 Created response, because in this usage the Location |
| header specifies the URL for the entire created resource. |  | header specifies the URL for the entire created resource. |
| skipping to change at page 33, line 19 |  | skipping to change at page 34, line 19 |
| The Retry-After response-header field can be used with a 503 (Service |  | The Retry-After response-header field can be used with a 503 (Service |
| Unavailable) response to indicate how long the service is expected to |  | Unavailable) response to indicate how long the service is expected to |
| be unavailable to the requesting client. This field MAY also be used |  | be unavailable to the requesting client. This field MAY also be used |
| with any 3xx (Redirection) response to indicate the minimum time the |  | with any 3xx (Redirection) response to indicate the minimum time the |
| user-agent is asked wait before issuing the redirected request. The |  | user-agent is asked wait before issuing the redirected request. The |
| value of this field can be either an HTTP-date or an integer number |  | value of this field can be either an HTTP-date or an integer number |
| of seconds (in decimal) after the time of the response. |  | of seconds (in decimal) after the time of the response. |
| Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) |  | Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) |
|  |  | Time spans are non-negative decimal integers, representing time in |
|  |  | seconds. |
|  |  | delta-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. |
| 10.8. Server |  | 10.8. Server |
| The Server response-header field contains information about the |  | The Server response-header field contains information about the |
| software used by the origin server to handle the request. The field |  | software used by the origin server to handle the request. The field |
| can contain multiple product tokens (Section 2) and comments |  | can contain multiple product tokens (Section 3.5 of [Part1]) and |
| identifying the server and any significant subproducts. The product |  | comments identifying the server and any significant subproducts. The |
| tokens are listed in order of their significance for identifying the |  | product tokens are listed in order of their significance for |
| application. |  | identifying the application. |
| Server = "Server" ":" 1*( product | comment ) |  | Server = "Server" ":" 1*( product | comment ) |
| Example: |  | Example: |
| Server: CERN/3.0 libwww/2.17 |  | Server: CERN/3.0 libwww/2.17 |
| If the response is being forwarded through a proxy, the proxy |  | If the response is being forwarded through a proxy, the proxy |
| application MUST NOT modify the Server response-header. Instead, it |  | application MUST NOT modify the Server response-header. Instead, it |
| MUST include a Via field (as described in Section 8.9 of [Part1]). |  | MUST include a Via field (as described in Section 8.9 of [Part1]). |
| skipping to change at page 34, line 13 |  | skipping to change at page 35, line 15 |
| option. |  | option. |
| 10.9. User-Agent |  | 10.9. User-Agent |
| The User-Agent request-header field contains information about the |  | The User-Agent request-header field contains information about the |
| user agent originating the request. This is for statistical |  | user agent originating the request. This is for statistical |
| purposes, the tracing of protocol violations, and automated |  | purposes, the tracing of protocol violations, and automated |
| recognition of user agents for the sake of tailoring responses to |  | recognition of user agents for the sake of tailoring responses to |
| avoid particular user agent limitations. User agents SHOULD include |  | avoid particular user agent limitations. User agents SHOULD include |
| this field with requests. The field can contain multiple product |  | this field with requests. The field can contain multiple product |
| tokens (Section 2) and comments identifying the agent and any |  | tokens (Section 3.5 of [Part1]) and comments identifying the agent |
| subproducts which form a significant part of the user agent. By |  | and any subproducts which form a significant part of the user agent. |
| convention, the product tokens are listed in order of their |  | By convention, the product tokens are listed in order of their |
| significance for identifying the application. |  | significance for identifying the application. |
| User-Agent = "User-Agent" ":" 1*( product | comment ) |  | User-Agent = "User-Agent" ":" 1*( product | comment ) |
| Example: |  | Example: |
| User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |  | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
| 11. IANA Considerations |  | 11. IANA Considerations |
| TBD. |  | [[anchor1: TBD.]] |
| 12. Security Considerations |  | 12. Security Considerations |
| This section is meant to inform application developers, information |  | This section is meant to inform application developers, information |
| providers, and users of the security limitations in HTTP/1.1 as |  | providers, and users of the security limitations in HTTP/1.1 as |
| described by this document. The discussion does not include |  | described by this document. The discussion does not include |
| definitive solutions to the problems revealed, though it does make |  | definitive solutions to the problems revealed, though it does make |
| some suggestions for reducing security risks. |  | some suggestions for reducing security risks. |
| 12.1. Transfer of Sensitive Information |  | 12.1. Transfer of Sensitive Information |
| skipping to change at page 35, line 35 |  | skipping to change at page 36, line 37 |
| We suggest, though do not require, that a convenient toggle interface |  | We suggest, though do not require, that a convenient toggle interface |
| be provided for the user to enable or disable the sending of From and |  | be provided for the user to enable or disable the sending of From and |
| Referer information. |  | Referer information. |
| The User-Agent (Section 10.9) or Server (Section 10.8) header fields |  | The User-Agent (Section 10.9) or Server (Section 10.8) header fields |
| can sometimes be used to determine that a specific client or server |  | can sometimes be used to determine that a specific client or server |
| have a particular security hole which might be exploited. |  | have a particular security hole which might be exploited. |
| Unfortunately, this same information is often used for other valuable |  | Unfortunately, this same information is often used for other valuable |
| purposes for which HTTP currently has no better mechanism. |  | purposes for which HTTP currently has no better mechanism. |
| 12.2. Encoding Sensitive Information in URI's |  | 12.2. Encoding Sensitive Information in URIs |
| Because the source of a link might be private information or might |  | Because the source of a link might be private information or might |
| reveal an otherwise private information source, it is strongly |  | reveal an otherwise private information source, it is strongly |
| recommended that the user be able to select whether or not the |  | recommended that the user be able to select whether or not the |
| Referer field is sent. For example, a browser client could have a |  | Referer field is sent. For example, a browser client could have a |
| toggle switch for browsing openly/anonymously, which would |  | toggle switch for browsing openly/anonymously, which would |
| respectively enable/disable the sending of Referer and From |  | respectively enable/disable the sending of Referer and From |
| information. |  | information. |
| Clients SHOULD NOT include a Referer header field in a (non-secure) |  | Clients SHOULD NOT include a Referer header field in a (non-secure) |
| HTTP request if the referring page was transferred with a secure |  | HTTP request if the referring page was transferred with a secure |
| protocol. |  | protocol. |
| Authors of services which use the HTTP protocol SHOULD NOT use GET |  | Authors of services should not use GET-based forms for the submission |
| based forms for the submission of sensitive data, because this will |  | of sensitive data because that data will be encoded in the Request- |
| cause this data to be encoded in the Request-URI. Many existing |  | URI. Many existing servers, proxies, and user agents log or display |
| servers, proxies, and user agents will log the request URI in some |  | the Request-URI in places where it might be visible to third parties. |
| place where it might be visible to third parties. Servers can use |  | Such services can use POST-based form submission instead. |
| POST-based form submission instead |  |  |
| 12.3. Location Headers and Spoofing |  | 12.3. Location Headers and Spoofing |
| If a single server supports multiple organizations that do not trust |  | If a single server supports multiple organizations that do not trust |
| one another, then it MUST check the values of Location and Content- |  | one another, then it MUST check the values of Location and Content- |
| Location headers in responses that are generated under control of |  | Location headers in responses that are generated under control of |
| said organizations to make sure that they do not attempt to |  | said organizations to make sure that they do not attempt to |
| invalidate resources over which they have no authority. |  | invalidate resources over which they have no authority. |
| 13. Acknowledgments |  | 13. Acknowledgments |
| 14. References |  | 14. References |
| 14.1. Normative References |  | 14.1. Normative References |
| [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |  | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |
| and Message Parsing", draft-ietf-httpbis-p1-messaging-01 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-02 |
| (work in progress), January 2008. |  | (work in progress), February 2008. |
| [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |  | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |
| and Content Negotiation", draft-ietf-httpbis-p3-payload-01 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-02 |
| (work in progress), January 2008. |  | (work in progress), February 2008. |
| [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional |  | and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional |
| Requests", draft-ietf-httpbis-p4-conditional-01 (work in |  | Requests", draft-ietf-httpbis-p4-conditional-02 (work in |
| progress), January 2008. |  | progress), February 2008. |
| [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |  | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |
| Partial Responses", draft-ietf-httpbis-p5-range-01 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-02 (work |
| in progress), January 2008. |  | in progress), February 2008. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |  | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |
| draft-ietf-httpbis-p6-cache-01 (work in progress), |  | draft-ietf-httpbis-p6-cache-02 (work in progress), |
| January 2008. |  | February 2008. |
| [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", |  | and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", |
| draft-ietf-httpbis-p7-auth-01 (work in progress), |  | draft-ietf-httpbis-p7-auth-02 (work in progress), |
| January 2008. |  | February 2008. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| 14.2. Informative References |  | 14.2. Informative References |
| [Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web |  | [Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web |
| proxy servers", draft-luotonen-web-proxy-tunneling-01 |  | proxy servers", draft-luotonen-web-proxy-tunneling-01 |
| (work in progress), August 1998. |  | (work in progress), August 1998. |
| skipping to change at page 39, line 46 |  | skipping to change at page 41, line 5 |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>: |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>: |
| "Informative references" |  | "Informative references" |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant |
| cross-references" |  | cross-references" |
| Other changes: |  | Other changes: |
| o Move definitions of 304 and 412 condition codes to [Part4] |  | o Move definitions of 304 and 412 condition codes to [Part4] |
|  |  | B.3. Since draft-ietf-httpbis-p2-semantics-01 |
|  |  | Closed issues: |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side |
|  |  | effects" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate |
|  |  | Host header requirements" |
|  |  | Ongoing work on ABNF conversion |
|  |  | (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>): |
|  |  | o Move "Product Tokens" section (back) into Part 1, as "token" is |
|  |  | used in the definition of the Upgrade header. |
|  |  | o Add explicit references to BNF syntax and rules imported from |
|  |  | other parts of the specification. |
|  |  | o Copy definition of delta-seconds from Part6 instead of referencing |
|  |  | it. |
| Index |  | Index |
| 1 |  | 1 |
| 100 Continue (status code) 17 |  | 100 Continue (status code) 18 |
| 101 Switching Protocols (status code) 18 |  | 101 Switching Protocols (status code) 19 |
| 2 |  | 2 |
| 200 OK (status code) 18 |  | 200 OK (status code) 19 |
| 201 Created (status code) 18 |  | 201 Created (status code) 19 |
| 202 Accepted (status code) 19 |  | 202 Accepted (status code) 20 |
| 203 Non-Authoritative Information (status code) 19 |  | 203 Non-Authoritative Information (status code) 20 |
| 204 No Content (status code) 19 |  | 204 No Content (status code) 20 |
| 205 Reset Content (status code) 20 |  | 205 Reset Content (status code) 21 |
| 206 Partial Content (status code) 20 |  | 206 Partial Content (status code) 21 |
| 3 |  | 3 |
| 300 Multiple Choices (status code) 20 |  | 300 Multiple Choices (status code) 21 |
| 301 Moved Permanently (status code) 21 |  | 301 Moved Permanently (status code) 22 |
| 302 Found (status code) 21 |  | 302 Found (status code) 22 |
| 303 See Other (status code) 22 |  | 303 See Other (status code) 23 |
| 304 Not Modified (status code) 22 |  | 304 Not Modified (status code) 23 |
| 305 Use Proxy (status code) 22 |  | 305 Use Proxy (status code) 23 |
| 306 (Unused) (status code) 23 |  | 306 (Unused) (status code) 24 |
| 307 Temporary Redirect (status code) 23 |  | 307 Temporary Redirect (status code) 24 |
| 4 |  | 4 |
| 400 Bad Request (status code) 24 |  | 400 Bad Request (status code) 25 |
| 401 Unauthorized (status code) 24 |  | 401 Unauthorized (status code) 25 |
| 402 Payment Required (status code) 24 |  | 402 Payment Required (status code) 25 |
| 403 Forbidden (status code) 24 |  | 403 Forbidden (status code) 25 |
| 404 Not Found (status code) 24 |  | 404 Not Found (status code) 25 |
| 405 Method Not Allowed (status code) 24 |  | 405 Method Not Allowed (status code) 25 |
| 406 Not Acceptable (status code) 24 |  | 406 Not Acceptable (status code) 25 |
| 407 Proxy Authentication Required (status code) 25 |  | 407 Proxy Authentication Required (status code) 26 |
| 408 Request Timeout (status code) 25 |  | 408 Request Timeout (status code) 26 |
| 409 Conflict (status code) 25 |  | 409 Conflict (status code) 26 |
| 410 Gone (status code) 26 |  | 410 Gone (status code) 27 |
| 411 Length Required (status code) 26 |  | 411 Length Required (status code) 27 |
| 412 Precondition Failed (status code) 26 |  | 412 Precondition Failed (status code) 27 |
| 413 Request Entity Too Large (status code) 26 |  | 413 Request Entity Too Large (status code) 27 |
| 414 Request-URI Too Long (status code) 27 |  | 414 Request-URI Too Long (status code) 28 |
| 415 Unsupported Media Type (status code) 27 |  | 415 Unsupported Media Type (status code) 28 |
| 416 Requested Range Not Satisfiable (status code) 27 |  | 416 Requested Range Not Satisfiable (status code) 28 |
| 417 Expectation Failed (status code) 27 |  | 417 Expectation Failed (status code) 28 |
| 5 |  | 5 |
| 500 Internal Server Error (status code) 27 |  | 500 Internal Server Error (status code) 28 |
| 501 Not Implemented (status code) 28 |  | 501 Not Implemented (status code) 29 |
| 502 Bad Gateway (status code) 28 |  | 502 Bad Gateway (status code) 29 |
| 503 Service Unavailable (status code) 28 |  | 503 Service Unavailable (status code) 29 |
| 504 Gateway Timeout (status code) 28 |  | 504 Gateway Timeout (status code) 29 |
| 505 HTTP Version Not Supported (status code) 28 |  | 505 HTTP Version Not Supported (status code) 29 |
| A |  | A |
| Allow header 29 |  | Allow header 30 |
| C |  | C |
| CONNECT method 17 |  | CONNECT method 18 |
| D |  | D |
| DELETE method 16 |  | DELETE method 17 |
| E |  | E |
| Expect header 29 |  | Expect header 30 |
| F |  | F |
| From header 30 |  | From header 31 |
| G |  | G |
| GET method 13 |  | GET method 14 |
| Grammar |  | Grammar |
| Allow 29 |  | Allow 30 |
| Expect 29 |  | delta-seconds 34 |
| expect-params 29 |  | Expect 30 |
| expectation 29 |  | expect-params 30 |
| expectation-extension 29 |  | expectation 30 |
| extension-code 9 |  | expectation-extension 30 |
| extension-method 7 |  | extension-code 10 |
| From 30 |  | extension-method 8 |
| Location 31 |  | From 31 |
| Max-Forwards 32 |  | Location 32 |
| Method 7 |  | Max-Forwards 33 |
| product 6 |  | Method 8 |
| product-version 6 |  | Reason-Phrase 10 |
| Reason-Phrase 9 |  | Referer 33 |
| Referer 32 |  | request-header 9 |
| request-header 8 |  | response-header 11 |
| response-header 10 |  | Retry-After 34 |
| Retry-After 33 |  | Server 34 |
| Server 33 |  | Status-Code 10 |
| Status-Code 9 |  | User-Agent 35 |
| User-Agent 34 |  |  |
| H |  | H |
| HEAD method 13 |  | HEAD method 14 |
| Headers |  | Headers |
| Allow 29 |  | Allow 30 |
| Expect 29 |  | Expect 30 |
| From 30 |  | From 31 |
| Location 31 |  | Location 32 |
| Max-Forwards 32 |  | Max-Forwards 33 |
| Referer 32 |  | Referer 33 |
| Retry-After 33 |  | Retry-After 34 |
| Server 33 |  | Server 34 |
| User-Agent 34 |  | User-Agent 35 |
| L |  | L |
| LINK method 38 |  | LINK method 39 |
| Location header 31 |  | Location header 32 |
| M |  | M |
| Max-Forwards header 32 |  | Max-Forwards header 33 |
| Methods |  | Methods |
| CONNECT 17 |  | CONNECT 18 |
| DELETE 16 |  | DELETE 17 |
| GET 13 |  | GET 14 |
| HEAD 13 |  | HEAD 14 |
| LINK 38 |  | LINK 39 |
| OPTIONS 12 |  | OPTIONS 13 |
| PATCH 38 |  | PATCH 39 |
| POST 14 |  | POST 15 |
| PUT 15 |  | PUT 16 |
| TRACE 16 |  | TRACE 17 |
| UNLINK 38 |  | UNLINK 39 |
| O |  | O |
| OPTIONS method 12 |  | OPTIONS method 13 |
| P |  | P |
| PATCH method 38 |  | PATCH method 39 |
| POST method 14 |  | POST method 15 |
| PUT method 15 |  | PUT method 16 |
| R |  | R |
| Referer header 32 |  | Referer header 33 |
| Retry-After header 33 |  | Retry-After header 34 |
| S |  | S |
| Server header 33 |  | Server header 34 |
| Status Codes |  | Status Codes |
| 100 Continue 17 |  | 100 Continue 18 |
| 101 Switching Protocols 18 |  | 101 Switching Protocols 19 |
| 200 OK 18 |  | 200 OK 19 |
| 201 Created 18 |  | 201 Created 19 |
| 202 Accepted 19 |  | 202 Accepted 20 |
| 203 Non-Authoritative Information 19 |  | 203 Non-Authoritative Information 20 |
| 204 No Content 19 |  | 204 No Content 20 |
| 205 Reset Content 20 |  | 205 Reset Content 21 |
| 206 Partial Content 20 |  | 206 Partial Content 21 |
| 300 Multiple Choices 20 |  | 300 Multiple Choices 21 |
| 301 Moved Permanently 21 |  | 301 Moved Permanently 22 |
| 302 Found 21 |  | 302 Found 22 |
| 303 See Other 22 |  | 303 See Other 23 |
| 304 Not Modified 22 |  | 304 Not Modified 23 |
| 305 Use Proxy 22 |  | 305 Use Proxy 23 |
| 306 (Unused) 23 |  | 306 (Unused) 24 |
| 307 Temporary Redirect 23 |  | 307 Temporary Redirect 24 |
| 400 Bad Request 24 |  | 400 Bad Request 25 |
| 401 Unauthorized 24 |  | 401 Unauthorized 25 |
| 402 Payment Required 24 |  | 402 Payment Required 25 |
| 403 Forbidden 24 |  | 403 Forbidden 25 |
| 404 Not Found 24 |  | 404 Not Found 25 |
| 405 Method Not Allowed 24 |  | 405 Method Not Allowed 25 |
| 406 Not Acceptable 24 |  | 406 Not Acceptable 25 |
| 407 Proxy Authentication Required 25 |  | 407 Proxy Authentication Required 26 |
| 408 Request Timeout 25 |  | 408 Request Timeout 26 |
| 409 Conflict 25 |  | 409 Conflict 26 |
| 410 Gone 26 |  | 410 Gone 27 |
| 411 Length Required 26 |  | 411 Length Required 27 |
| 412 Precondition Failed 26 |  | 412 Precondition Failed 27 |
| 413 Request Entity Too Large 26 |  | 413 Request Entity Too Large 27 |
| 414 Request-URI Too Long 27 |  | 414 Request-URI Too Long 28 |
| 415 Unsupported Media Type 27 |  | 415 Unsupported Media Type 28 |
| 416 Requested Range Not Satisfiable 27 |  | 416 Requested Range Not Satisfiable 28 |
| 417 Expectation Failed 27 |  | 417 Expectation Failed 28 |
| 500 Internal Server Error 27 |  | 500 Internal Server Error 28 |
| 501 Not Implemented 28 |  | 501 Not Implemented 29 |
| 502 Bad Gateway 28 |  | 502 Bad Gateway 29 |
| 503 Service Unavailable 28 |  | 503 Service Unavailable 29 |
| 504 Gateway Timeout 28 |  | 504 Gateway Timeout 29 |
| 505 HTTP Version Not Supported 28 |  | 505 HTTP Version Not Supported 29 |
| T |  | T |
| TRACE method 16 |  | TRACE method 17 |
| U |  | U |
| UNLINK method 38 |  | UNLINK method 39 |
| User-Agent header 34 |  | User-Agent header 35 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Day Software |  | Day Software |
| 23 Corporate Plaza DR, Suite 280 |  | 23 Corporate Plaza DR, Suite 280 |
| Newport Beach, CA 92660 |  | Newport Beach, CA 92660 |
| USA |  | USA |
| Phone: +1-949-706-5300 |  | Phone: +1-949-706-5300 |
End of changes. 65 change blocks.
| 323 lines changed or deleted |  | 378 lines changed or added |
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/