| draft-ietf-httpbis-p2-semantics-02.txt |  | draft-ietf-httpbis-p2-semantics-03.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 |  | Updates: 2817 (if approved) One Laptop per Child |
| Expires: August 27, 2008 J. Mogul |  | Intended status: Standards Track J. Mogul |
| HP |  | Expires: December 19, 2008 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 |
| February 24, 2008 |  | June 17, 2008 |
| HTTP/1.1, part 2: Message Semantics |  | HTTP/1.1, part 2: Message Semantics |
| draft-ietf-httpbis-p2-semantics-02 |  | draft-ietf-httpbis-p2-semantics-03 |
| 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 August 27, 2008. |  | This Internet-Draft will expire on December 19, 2008. |
| Copyright Notice |  |  |
| 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 |
| information initiative since 1990. This document is Part 2 of the |  | information initiative since 1990. This document is Part 2 of the |
| seven-part specification that defines the protocol referred to as |  | seven-part specification that defines the protocol referred to as |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines |
| the semantics of HTTP messages as expressed by request methods, |  | the semantics of HTTP messages as expressed by request methods, |
| skipping to change at page 2, line 29 |  | skipping to change at page 2, line 25 |
| fields. |  | fields. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft should take place on the HTTPBIS working |
| group mailing list (ietf-http-wg@w3.org). The current issues list is |  | group mailing list (ietf-http-wg@w3.org). The current issues list is |
| at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related |  | at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://www.tools.ietf.org/wg/httpbis/>. |  | <http://www.tools.ietf.org/wg/httpbis/>. |
| This draft incorporates those issue resolutions that were either |  | The changes in this draft are summarized in Appendix B.4. |
| collected in the original RFC2616 errata list |  |  |
| (<http://purl.org/NET/http-errata>), or which were agreed upon on the |  |  |
| mailing list between October 2006 and November 2007 (as published in |  |  |
| "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. Notational Conventions and Generic Grammar . . . . . . . . . . 6 |  | 2. Notational Conventions and Generic Grammar . . . . . . . . . . 6 |
| 3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 |  | 3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 |
| 4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 8 |  | 4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 8 |
| 5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 9 |  | 5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 9 |
|  |  | 5.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 11 |
| 6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 11 |  | 6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 11 |
| 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 12 |  | 8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 12 |
| 8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 12 |  | 8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 12 |
| 8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 12 |  | 8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 12 |
| 8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 12 |  | 8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 13 |
| 8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 |
| 8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 |  | 8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 |
| 8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18 |  | 9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18 |
| 9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 18 |  | 9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 18 |
| 9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 18 |  | 9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 19 |
| 9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 19 |  | 9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 19 |
| 9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 19 |  | 9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 19 |
| 9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 19 |  | 9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 20 |
| 9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 20 |  | 9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 20 |
| 9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 20 |  | 9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 20 |
| 9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 20 |  | 9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 21 |
| 9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 21 |  | 9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 21 |
| 9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 21 |  | 9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 21 |
| 9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 21 |  | 9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 21 |
| 9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 21 |  | 9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 22 |
| 9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 22 |  | 9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 22 |
| 9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 22 |  | 9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 23 |
| 9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 23 |  | 9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 23 |
| 9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 23 |  | 9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 24 |
| 9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 23 |  | 9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 24 |
| 9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 24 |  | 9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 24 |
| 9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 24 |  | 9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 24 |
| 9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 24 |  | 9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 25 |
| 9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 25 |  | 9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 25 |
| 9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 25 |  | 9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 25 |
| 9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 25 |  | 9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 25 |
| 9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 25 |  | 9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 25 |
| 9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 25 |  | 9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 26 |
| 9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 25 |  | 9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 26 |
| 9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 25 |  | 9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 26 |
| 9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 26 |  | 9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 26 |
| 9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 26 |  | 9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 27 |
| 9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 26 |  | 9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 27 |
| 9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 27 |  | 9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 28 |
| 9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 27 |  | 9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 28 |
| 9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 27 |  | 9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 28 |
| 9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 28 |  | 9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 28 |
| 9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 28 |  | 9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 28 |
| 9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 28 |  | 9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 28 |
| 9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 28 |  | 9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 29 |
| 9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 28 |  | 9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 29 |
| 9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 28 |  | 9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 29 |
| 9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 29 |  | 9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 29 |
| 9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 29 |  | 9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 29 |
| 9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 29 |  | 9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 29 |
| 9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 29 |  | 9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 30 |
| 9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 29 |  | 9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 30 |
| 10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 30 |  | 10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 30 |
| 10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 30 |  | 10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 30 |
| 10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 30 |  | 10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 31 |
| 10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 |
| 10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 34 |  | 10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 34 |
| 10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 34 |  | 10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 34 |
| 10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 35 |  | 10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 35 |
| 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 |  | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 |
| 12. Security Considerations . . . . . . . . . . . . . . . . . . . 35 |  | 11.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 35 |
| 12.1. Transfer of Sensitive Information . . . . . . . . . . . . 35 |  | 11.2. Message Header Registration . . . . . . . . . . . . . . . 37 |
| 12.2. Encoding Sensitive Information in URIs . . . . . . . . . . 36 |  | 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37 |
| 12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 37 |  | 12.1. Transfer of Sensitive Information . . . . . . . . . . . . 37 |
| 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 |  | 12.2. Encoding Sensitive Information in URIs . . . . . . . . . . 38 |
| 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 |  | 12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 39 |
| 14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 |  | 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 |
| 14.2. Informative References . . . . . . . . . . . . . . . . . . 38 |  | 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 |
| Appendix A. Compatibility with Previous Versions . . . . . . . . 38 |  | 14.1. Normative References . . . . . . . . . . . . . . . . . . . 39 |
| A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 38 |  | 14.2. Informative References . . . . . . . . . . . . . . . . . . 40 |
| A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 39 |  | Appendix A. Compatibility with Previous Versions . . . . . . . . 40 |
|  |  | A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 40 |
|  |  | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 41 |
| Appendix B. Change Log (to be removed by RFC Editor before |  | Appendix B. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 40 |  | publication) . . . . . . . . . . . . . . . . . . . . 42 |
| B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 40 |  | B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 42 |
| B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 40 |  | B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 42 |
| B.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 41 |  | B.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 43 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |  | B.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 43 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 48 |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 |
|  |  | Intellectual Property and Copyright Statements . . . . . . . . . . 51 |
| 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 8, line 11 |  | skipping to change at page 8, line 11 |
| Proxy-Authorization = |  | Proxy-Authorization = |
| <Proxy-Authorization, defined in [Part7], Section 4.3> |  | <Proxy-Authorization, defined in [Part7], Section 4.3> |
| WWW-Authenticate = |  | WWW-Authenticate = |
| <WWW-Authenticate, defined in [Part7], Section 4.4> |  | <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 = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 8.2 |
| | "GET" ; Section 8.3 |  | | %x47.45.54 ; "GET", Section 8.3 |
| | "HEAD" ; Section 8.4 |  | | %x48.45.41.44 ; "HEAD", Section 8.4 |
| | "POST" ; Section 8.5 |  | | %x50.4F.53.54 ; "POST", Section 8.5 |
| | "PUT" ; Section 8.6 |  | | %x50.55.54 ; "PUT", Section 8.6 |
| | "DELETE" ; Section 8.7 |  | | %x44.45.4C.45.54.45 ; "DELETE", Section 8.7 |
| | "TRACE" ; Section 8.8 |  | | %x54.52.41.43.45 ; "TRACE", Section 8.8 |
| | "CONNECT" ; Section 8.9 |  | | %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 8.9 |
| | extension-method |  | | extension-method |
| extension-method = token |  | extension-method = token |
| The list of methods allowed by a resource can be specified in an |  | The list of methods allowed by a resource can be specified in an |
| Allow header field (Section 10.1). The return code of the response |  | Allow header field (Section 10.1). The return code of the response |
| always notifies the client whether a method is currently allowed on a |  | always notifies the client whether a method is currently allowed on a |
| resource, since the set of allowed methods can change dynamically. |  | resource, since the set of allowed methods can change dynamically. |
| An origin server SHOULD return the status code 405 (Method Not |  | An origin server SHOULD return the status code 405 (Method Not |
| Allowed) if the method is known by the origin server but not allowed |  | Allowed) if the method is known by the origin server but not allowed |
| for the requested resource, and 501 (Not Implemented) if the method |  | for the requested resource, and 501 (Not Implemented) if the method |
| skipping to change at page 11, line 16 |  | skipping to change at page 11, line 16 |
| digit, and treat any unrecognized response as being equivalent to the |  | digit, and treat any unrecognized response as being equivalent to the |
| x00 status code of that class, with the exception that an |  | x00 status code of that class, with the exception that an |
| unrecognized response MUST NOT be cached. For example, if an |  | unrecognized response MUST NOT be cached. For example, if an |
| unrecognized status code of 431 is received by the client, it can |  | unrecognized status code of 431 is received by the client, it can |
| safely assume that there was something wrong with its request and |  | safely assume that there was something wrong with its request and |
| treat the response as if it had received a 400 status code. In such |  | treat the response as if it had received a 400 status code. In such |
| cases, user agents SHOULD present to the user the entity returned |  | cases, user agents SHOULD present to the user the entity returned |
| 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. |
|  |  | 5.1. Status Code Registry |
|  |  | The HTTP Status Code Registry defines the name space for the Status- |
|  |  | Code token in the Status line of an HTTP response. |
|  |  | Values to be added to this name space are subject to IETF review |
|  |  | ([RFC5226], Section 4.1). Any document registering new status codes |
|  |  | should be traceable through statuses of either 'Obsoletes' or |
|  |  | 'Updates' to this document. |
|  |  | The registry itself is maintained at |
|  |  | <http://www.iana.org/assignments/http-status-codes>. |
| 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 6.1 |  | response-header = Accept-Ranges ; [Part5], Section 6.1 |
| | Age ; [Part6], Section 16.1 |  | | Age ; [Part6], Section 16.1 |
|  |  | | Allow ; Section 10.1 |
| | ETag ; [Part4], Section 7.1 |  | | ETag ; [Part4], Section 7.1 |
| | Location ; Section 10.4 |  | | Location ; Section 10.4 |
| | Proxy-Authenticate ; [Part7], Section 4.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 16.5 |  | | Vary ; [Part6], Section 16.5 |
| | WWW-Authenticate ; [Part7], Section 4.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 |
| skipping to change at page 16, line 7 |  | skipping to change at page 16, line 20 |
| status of the request and refers to the new resource, and a Location |  | status of the request and refers to the new resource, and a Location |
| header (see Section 10.4). |  | header (see Section 10.4). |
| Responses to this method are not cacheable, unless the response |  | Responses to this method are not cacheable, unless the response |
| includes appropriate Cache-Control or Expires header fields. |  | includes appropriate Cache-Control or Expires header fields. |
| However, the 303 (See Other) response can be used to direct the user |  | However, the 303 (See Other) response can be used to direct the user |
| agent to retrieve a cacheable resource. |  | agent to retrieve a cacheable resource. |
| 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 at 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 at the Request-URI, the origin server MUST |  | new resource is created at the Request-URI, the origin server MUST |
| inform the user agent via the 201 (Created) response. If an existing |  | inform the user agent via the 201 (Created) response. If an existing |
| resource is modified, either the 200 (OK) or 204 (No Content) |  | resource is modified, either the 200 (OK) or 204 (No Content) |
| response codes SHOULD be sent to indicate successful completion of |  | response codes SHOULD be sent to indicate successful completion of |
| skipping to change at page 17, line 47 |  | skipping to change at page 18, line 13 |
| TRACE allows the client to see what is being received at the other |  | TRACE allows the client to see what is being received at the other |
| end of the request chain and use that data for testing or diagnostic |  | end of the request chain and use that data for testing or diagnostic |
| information. The value of the Via header field (Section 8.9 of |  | information. The value of the Via header field (Section 8.9 of |
| [Part1]) is of particular interest, since it acts as a trace of the |  | [Part1]) is of particular interest, since it acts as a trace of the |
| request chain. Use of the Max-Forwards header field allows the |  | request chain. Use of the Max-Forwards header field allows the |
| client to limit the length of the request chain, which is useful for |  | client to limit the length of the request chain, which is useful for |
| testing a chain of proxies forwarding messages in an infinite loop. |  | testing a chain of proxies forwarding messages in an infinite loop. |
| If the request is valid, the response SHOULD contain the entire |  | If the request is valid, the response SHOULD contain the entire |
| request message in the entity-body, with a Content-Type of "message/ |  | request message in the entity-body, with a Content-Type of "message/ |
| http". Responses to this method MUST NOT be cached. |  | http" (see Appendix A.1 of [Part1]). Responses to this method MUST |
|  |  | NOT be cached. |
| 8.9. CONNECT |  | 8.9. CONNECT |
| This specification reserves the method name CONNECT for use with a |  | This specification reserves the method name CONNECT for use with a |
| proxy that can dynamically switch to being a tunnel (e.g. SSL |  | proxy that can dynamically switch to being a tunnel (e.g. SSL |
| tunneling [Luo1998]). |  | tunneling [Luo1998]). |
| 9. Status Code Definitions |  | 9. Status Code Definitions |
| Each Status-Code is described below, including a description of which |  | Each Status-Code is described below, including a description of which |
| skipping to change at page 23, line 17 |  | skipping to change at page 23, line 36 |
| allowed to change the method on the redirected request. However, |  | allowed to change the method on the redirected request. However, |
| most existing user agent implementations treat 302 as if it were a |  | most existing user agent implementations treat 302 as if it were a |
| 303 response, performing a GET on the Location field-value |  | 303 response, performing a GET on the Location field-value |
| regardless of the original request method. The status codes 303 |  | regardless of the original request method. The status codes 303 |
| and 307 have been added for servers that wish to make |  | and 307 have been added for servers that wish to make |
| unambiguously clear which kind of reaction is expected of the |  | unambiguously clear which kind of reaction is expected of the |
| client. |  | client. |
| 9.3.4. 303 See Other |  | 9.3.4. 303 See Other |
| The response to the request can be found under a different URI and |  | The server directs the user agent to a different resource, indicated |
| SHOULD be retrieved using a GET method on that resource. This method |  | by a URI in the Location header field, that provides an indirect |
| exists primarily to allow the output of a POST-activated script to |  | response to the original request. The user agent MAY perform a GET |
| redirect the user agent to a selected resource. The new URI is not a |  | request on the URI in the Location field in order to obtain a |
| substitute reference for the originally requested resource. The 303 |  | representation corresponding to the response, be redirected again, or |
| response MUST NOT be cached, but the response to the second |  | end with an error status. The Location URI is not a substitute |
| (redirected) request might be cacheable. |  | reference for the originally requested resource. |
| The different URI SHOULD be given by the Location field in the |  | The 303 status is generally applicable to any HTTP method. It is |
| response. Unless the request method was HEAD, the entity of the |  | primarily used to allow the output of a POST action to redirect the |
| response SHOULD contain a short hypertext note with a hyperlink to |  | user agent to a selected resource, since doing so provides the |
| the new URI(s). |  | information corresponding to the POST response in a form that can be |
|  |  | separately identified, bookmarked, and cached independent of the |
|  |  | original request. |
| Note: Many pre-HTTP/1.1 user agents do not understand the 303 |  | A 303 response to a GET request indicates that the requested resource |
| status. When interoperability with such clients is a concern, the |  | does not have a representation of its own that can be transferred by |
| 302 status code may be used instead, since most user agents react |  | the server over HTTP. The Location URI indicates a resource that is |
| to a 302 response as described here for 303. |  | descriptive of the requested resource such that the follow-on |
|  |  | representation may be useful without implying that it adequately |
|  |  | represents the previously requested resource. Note that answers to |
|  |  | the questions of what can be represented, what representations are |
|  |  | adequate, and what might be a useful description are outside the |
|  |  | scope of HTTP and thus entirely determined by the resource owner(s). |
|  |  | A 303 response SHOULD NOT be cached unless it is indicated as |
|  |  | cacheable by Cache-Control or Expires header fields. Except for |
|  |  | responses to a HEAD request, the entity of a 303 response SHOULD |
|  |  | contain a short hypertext note with a hyperlink to the Location URI. |
| 9.3.5. 304 Not Modified |  | 9.3.5. 304 Not Modified |
| The response to the request has not been modified since the |  | The response to the request has not been modified since the |
| conditions indicated by the client's conditional GET request, as |  | conditions indicated by the client's conditional GET request, as |
| defined in [Part4]. |  | defined in [Part4]. |
| 9.3.6. 305 Use Proxy |  | 9.3.6. 305 Use Proxy |
| The requested resource MUST be accessed through the proxy given by |  | The 305 status was defined in a previous version of this |
| the Location field. The Location field gives the URI of the proxy. |  | specification (see Appendix A.2), and is now deprecated. |
| The recipient is expected to repeat this single request via the |  |  |
| proxy. 305 responses MUST only be generated by origin servers. |  |  |
| Note: [RFC2068] was not clear that 305 was intended to redirect a |  |  |
| single request, and to be generated by origin servers only. Not |  |  |
| observing these limitations has significant security consequences. |  |  |
| 9.3.7. 306 (Unused) |  | 9.3.7. 306 (Unused) |
| The 306 status code was used in a previous version of the |  | The 306 status code was used in a previous version of the |
| specification, is no longer used, and the code is reserved. |  | specification, is no longer used, and the code is reserved. |
| 9.3.8. 307 Temporary Redirect |  | 9.3.8. 307 Temporary Redirect |
| The requested resource resides temporarily under a different URI. |  | The requested resource resides temporarily under a different URI. |
| Since the redirection MAY be altered on occasion, the client SHOULD |  | Since the redirection MAY be altered on occasion, the client SHOULD |
| skipping to change at page 30, line 16 |  | skipping to change at page 30, line 36 |
| This section defines the syntax and semantics of HTTP/1.1 header |  | This section defines the syntax and semantics of HTTP/1.1 header |
| fields related to request and response semantics. |  | fields related to request and response semantics. |
| For entity-header fields, both sender and recipient refer to either |  | For entity-header fields, both sender and recipient refer to either |
| the client or the server, depending on who sends and who receives the |  | the client or the server, depending on who sends and who receives the |
| entity. |  | entity. |
| 10.1. Allow |  | 10.1. Allow |
| The Allow entity-header field lists the set of methods supported by |  | The Allow response-header field lists the set of methods advertised |
| the resource identified by the Request-URI. The purpose of this |  | as supported by the resource identified by the Request-URI. The |
| field is strictly to inform the recipient of valid methods associated |  | purpose of this field is strictly to inform the recipient of valid |
| with the resource. An Allow header field MUST be present in a 405 |  | methods associated with the resource. An Allow header field MUST be |
| (Method Not Allowed) response. |  | present in a 405 (Method Not Allowed) response. |
| Allow = "Allow" ":" #Method |  | Allow = "Allow" ":" #Method |
| Example of use: |  | Example of use: |
| Allow: GET, HEAD, PUT |  | Allow: GET, HEAD, PUT |
| This field cannot prevent a client from trying other methods. |  | The actual set of allowed methods is defined by the origin server at |
| However, the indications given by the Allow header field value SHOULD |  | the time of each request. |
| be followed. The actual set of allowed methods is defined by the |  |  |
| origin server at the time of each request. |  |  |
| The Allow header field MAY be provided with a PUT request to |  |  |
| recommend the methods to be supported by the new or modified |  |  |
| resource. The server is not required to support these methods and |  |  |
| SHOULD include an Allow header in the response giving the actual |  |  |
| supported methods. |  |  |
| A proxy MUST NOT modify the Allow header field even if it does not |  | A proxy MUST NOT modify the Allow header field even if it does not |
| understand all the methods specified, since the user agent might have |  | understand all the methods specified, since the user agent might have |
| other means of communicating with the origin server. |  | other means of communicating with the origin server. |
| 10.2. Expect |  | 10.2. Expect |
| The Expect request-header field is used to indicate that particular |  | The Expect request-header field is used to indicate that particular |
| server behaviors are required by the client. |  | server behaviors are required by the client. |
| skipping to change at page 32, line 23 |  | skipping to change at page 32, line 36 |
| used. |  | used. |
| The client SHOULD NOT send the From header field without the user's |  | The client SHOULD NOT send the From header field without the user's |
| approval, as it might conflict with the user's privacy interests or |  | approval, as it might conflict with the user's privacy interests or |
| their site's security policy. It is strongly recommended that the |  | their site's security policy. It is strongly recommended that the |
| user be able to disable, enable, and modify the value of this field |  | user be able to disable, enable, and modify the value of this field |
| at any time prior to a request. |  | at any time prior to a request. |
| 10.4. Location |  | 10.4. Location |
| The Location response-header field is used to redirect the recipient |  | The Location response-header field is used for the identification of |
| to a location other than the Request-URI for completion of the |  | a new resource or to redirect the recipient to a location other than |
| request or identification of a new resource. For 201 (Created) |  | the Request-URI for completion of the request. For 201 (Created) |
| responses, the Location is that of the new resource which was created |  | responses, the Location is that of the new resource which was created |
| 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 |
| skipping to change at page 35, line 28 |  | skipping to change at page 35, line 44 |
| 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 |
| [[anchor1: TBD.]] |  | 11.1. Status Code Registry |
|  |  | The registration procedure for HTTP Status Codes -- previously |
|  |  | defined in Section 7.1 of [RFC2817] -- is now defined by Section 5.1 |
|  |  | of this document. |
|  |  | The HTTP Status Code Registry located at |
|  |  | <http://www.iana.org/assignments/http-status-codes> should be updated |
|  |  | with the registrations below: |
|  |  | +-------+---------------------------------+----------------+ |
|  |  | | Value | Description | Reference | |
|  |  | +-------+---------------------------------+----------------+ |
|  |  | | 100 | Continue | Section 9.1.1 | |
|  |  | | 101 | Switching Protocols | Section 9.1.2 | |
|  |  | | 200 | OK | Section 9.2.1 | |
|  |  | | 201 | Created | Section 9.2.2 | |
|  |  | | 202 | Accepted | Section 9.2.3 | |
|  |  | | 203 | Non-Authoritative Information | Section 9.2.4 | |
|  |  | | 204 | No Content | Section 9.2.5 | |
|  |  | | 205 | Reset Content | Section 9.2.6 | |
|  |  | | 206 | Partial Content | Section 9.2.7 | |
|  |  | | 300 | Multiple Choices | Section 9.3.1 | |
|  |  | | 301 | Moved Permanently | Section 9.3.2 | |
|  |  | | 302 | Found | Section 9.3.3 | |
|  |  | | 303 | See Other | Section 9.3.4 | |
|  |  | | 304 | Not Modified | Section 9.3.5 | |
|  |  | | 305 | Use Proxy | Section 9.3.6 | |
|  |  | | 306 | (Unused) | Section 9.3.7 | |
|  |  | | 307 | Temporary Redirect | Section 9.3.8 | |
|  |  | | 400 | Bad Request | Section 9.4.1 | |
|  |  | | 401 | Unauthorized | Section 9.4.2 | |
|  |  | | 402 | Payment Required | Section 9.4.3 | |
|  |  | | 403 | Forbidden | Section 9.4.4 | |
|  |  | | 404 | Not Found | Section 9.4.5 | |
|  |  | | 405 | Method Not Allowed | Section 9.4.6 | |
|  |  | | 406 | Not Acceptable | Section 9.4.7 | |
|  |  | | 407 | Proxy Authentication Required | Section 9.4.8 | |
|  |  | | 408 | Request Timeout | Section 9.4.9 | |
|  |  | | 409 | Conflict | Section 9.4.10 | |
|  |  | | 410 | Gone | Section 9.4.11 | |
|  |  | | 411 | Length Required | Section 9.4.12 | |
|  |  | | 412 | Precondition Failed | Section 9.4.13 | |
|  |  | | 413 | Request Entity Too Large | Section 9.4.14 | |
|  |  | | 414 | Request-URI Too Long | Section 9.4.15 | |
|  |  | | 415 | Unsupported Media Type | Section 9.4.16 | |
|  |  | | 416 | Requested Range Not Satisfiable | Section 9.4.17 | |
|  |  | | 417 | Expectation Failed | Section 9.4.18 | |
|  |  | | 500 | Internal Server Error | Section 9.5.1 | |
|  |  | | 501 | Not Implemented | Section 9.5.2 | |
|  |  | | 502 | Bad Gateway | Section 9.5.3 | |
|  |  | | 503 | Service Unavailable | Section 9.5.4 | |
|  |  | | 504 | Gateway Timeout | Section 9.5.5 | |
|  |  | | 505 | HTTP Version Not Supported | Section 9.5.6 | |
|  |  | +-------+---------------------------------+----------------+ |
|  |  | 11.2. Message Header Registration |
|  |  | The Message Header Registry located at <http://www.iana.org/ |
|  |  | assignments/message-headers/message-header-index.html> should be |
|  |  | updated with the permanent registrations below (see [RFC3864]): |
|  |  | +-------------------+----------+----------+--------------+ |
|  |  | | Header Field Name | Protocol | Status | Reference | |
|  |  | +-------------------+----------+----------+--------------+ |
|  |  | | Allow | http | standard | Section 10.1 | |
|  |  | | Expect | http | standard | Section 10.2 | |
|  |  | | From | http | standard | Section 10.3 | |
|  |  | | Location | http | standard | Section 10.4 | |
|  |  | | Max-Forwards | http | standard | Section 10.5 | |
|  |  | | Referer | http | standard | Section 10.6 | |
|  |  | | Retry-After | http | standard | Section 10.7 | |
|  |  | | Server | http | standard | Section 10.8 | |
|  |  | | User-Agent | http | standard | Section 10.9 | |
|  |  | +-------------------+----------+----------+--------------+ |
|  |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
|  |  | Engineering Task Force". |
| 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 37, line 26 |  | skipping to change at page 39, line 22 |
| 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-02 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-03 |
| (work in progress), February 2008. |  | (work in progress), June 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-02 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-03 |
| (work in progress), February 2008. |  | (work in progress), June 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-02 (work in |  | Requests", draft-ietf-httpbis-p4-conditional-03 (work in |
| progress), February 2008. |  | progress), June 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-02 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-03 (work |
| in progress), February 2008. |  | in progress), June 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-02 (work in progress), |  | draft-ietf-httpbis-p6-cache-03 (work in progress), |
| February 2008. |  | June 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-02 (work in progress), |  | draft-ietf-httpbis-p7-auth-03 (work in progress), |
| February 2008. |  | June 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 38, line 33 |  | skipping to change at page 40, line 28 |
| Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. |  | Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. |
| [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |  | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |
| Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |  | Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |
| RFC 2068, January 1997. |  | RFC 2068, January 1997. |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
|  |  | [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within |
|  |  | HTTP/1.1", RFC 2817, May 2000. |
| [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, |  | [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, |
| April 2001. |  | April 2001. |
|  |  | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
|  |  | Procedures for Message Header Fields", BCP 90, RFC 3864, |
|  |  | September 2004. |
|  |  | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |
|  |  | IANA Considerations Section in RFCs", BCP 26, RFC 5226, |
|  |  | May 2008. |
| Appendix A. Compatibility with Previous Versions |  | Appendix A. Compatibility with Previous Versions |
| A.1. Changes from RFC 2068 |  | A.1. Changes from RFC 2068 |
| Clarified which error code should be used for inbound server failures |  | Clarified which error code should be used for inbound server failures |
| (e.g. DNS failures). (Section 9.5.5). |  | (e.g. DNS failures). (Section 9.5.5). |
| 201 (Created) had a race that required an Etag be sent when a |  | 201 (Created) had a race that required an Etag be sent when a |
| resource is first created. (Section 9.2.2). |  | resource is first created. (Section 9.2.2). |
| skipping to change at page 39, line 34 |  | skipping to change at page 41, line 39 |
| 7. Allow servers to defend against denial-of-service attacks and |  | 7. Allow servers to defend against denial-of-service attacks and |
| broken clients. |  | broken clients. |
| This change adds the Expect header and 417 status code. |  | This change adds the Expect header and 417 status code. |
| Clean up confusion between 403 and 404 responses. (Section 9.4.4, |  | Clean up confusion between 403 and 404 responses. (Section 9.4.4, |
| 9.4.5, and 9.4.11) |  | 9.4.5, and 9.4.11) |
| The PATCH, LINK, UNLINK methods were defined but not commonly |  | The PATCH, LINK, UNLINK methods were defined but not commonly |
| implemented in previous versions of this specification. See |  | implemented in previous versions of this specification. See Section |
| [RFC2068]. |  | 19.6.1 of [RFC2068]. |
| A.2. Changes from RFC 2616 |  | A.2. Changes from RFC 2616 |
|  |  | This document takes over the Status Code Registry, previously defined |
|  |  | in Section 7.1 of [RFC2817]. (Section 5.1) |
| Clarify definition of POST. (Section 8.5) |  | Clarify definition of POST. (Section 8.5) |
| Failed to consider that there are many other request methods that are |  | Failed to consider that there are many other request methods that are |
| safe to automatically redirect, and further that the user agent is |  | safe to automatically redirect, and further that the user agent is |
| able to make that determination based on the request method |  | able to make that determination based on the request method |
| semantics. (Sections 9.3.2, 9.3.3 and 9.3.8 ) |  | semantics. (Sections 9.3.2, 9.3.3 and 9.3.8 ) |
|  |  | Deprecate 305 Use Proxy status code, because user agents did not |
|  |  | implement it. It used to indicate that the requested resource must |
|  |  | be accessed through the proxy given by the Location field. The |
|  |  | Location field gave the URI of the proxy. The recipient was expected |
|  |  | to repeat this single request via the proxy. (Section 9.3.6) |
|  |  | Reclassify Allow header as response header, removing the option to |
|  |  | specify it in a PUT request. Relax the server requirement on the |
|  |  | contents of the Allow header and remove requirement on clients to |
|  |  | always trust the header value. (Section 10.1) |
| Correct syntax of Location header to allow fragment, as referred |  | Correct syntax of Location header to allow fragment, as referred |
| symbol wasn't what was expected, and add some clarifications as to |  | symbol wasn't what was expected, and add some clarifications as to |
| when it would not be appropriate. (Section 10.4) |  | when it would not be appropriate. (Section 10.4) |
| In the description of the Server header, the Via field was described |  | In the description of the Server header, the Via field was described |
| as a SHOULD. The requirement was and is stated correctly in the |  | as a SHOULD. The requirement was and is stated correctly in the |
| description of the Via header in Section 8.9 of [Part1]. |  | description of the Via header in Section 8.9 of [Part1]. |
| (Section 10.8) |  | (Section 10.8) |
| Appendix B. Change Log (to be removed by RFC Editor before publication) |  | Appendix B. Change Log (to be removed by RFC Editor before publication) |
| B.1. Since RFC2616 |  | B.1. Since RFC2616 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| B.2. Since draft-ietf-httpbis-p2-semantics-00 |  | B.2. Since draft-ietf-httpbis-p2-semantics-00 |
| skipping to change at page 41, line 27 |  | skipping to change at page 43, line 39 |
| o Move "Product Tokens" section (back) into Part 1, as "token" is |  | o Move "Product Tokens" section (back) into Part 1, as "token" is |
| used in the definition of the Upgrade header. |  | used in the definition of the Upgrade header. |
| o Add explicit references to BNF syntax and rules imported from |  | o Add explicit references to BNF syntax and rules imported from |
| other parts of the specification. |  | other parts of the specification. |
| o Copy definition of delta-seconds from Part6 instead of referencing |  | o Copy definition of delta-seconds from Part6 instead of referencing |
| it. |  | it. |
|  |  | B.4. Since draft-ietf-httpbis-p2-semantics-02 |
|  |  | Closed issues: |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring |
|  |  | Allow in 405 responses" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status |
|  |  | Code Registry" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/61>: |
|  |  | "Redirection vs. Location" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/70>: |
|  |  | "Cacheability of 303 response" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use |
|  |  | Proxy" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/105>: |
|  |  | "Classification for Allow header" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - |
|  |  | 'store under' vs 'store at'" |
|  |  | Ongoing work on IANA Message Header Registration |
|  |  | (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40>): |
|  |  | o Reference RFC 3984, and update header registrations for headers |
|  |  | defined in this document. |
|  |  | Ongoing work on ABNF conversion |
|  |  | (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>): |
|  |  | o Replace string literals when the string really is case-sensitive |
|  |  | (method). |
| Index |  | Index |
| 1 |  | 1 |
| 100 Continue (status code) 18 |  | 100 Continue (status code) 19 |
| 101 Switching Protocols (status code) 19 |  | 101 Switching Protocols (status code) 19 |
| 2 |  | 2 |
| 200 OK (status code) 19 |  | 200 OK (status code) 19 |
| 201 Created (status code) 19 |  | 201 Created (status code) 20 |
| 202 Accepted (status code) 20 |  | 202 Accepted (status code) 20 |
| 203 Non-Authoritative Information (status code) 20 |  | 203 Non-Authoritative Information (status code) 20 |
| 204 No Content (status code) 20 |  | 204 No Content (status code) 21 |
| 205 Reset Content (status code) 21 |  | 205 Reset Content (status code) 21 |
| 206 Partial Content (status code) 21 |  | 206 Partial Content (status code) 21 |
| 3 |  | 3 |
| 300 Multiple Choices (status code) 21 |  | 300 Multiple Choices (status code) 22 |
| 301 Moved Permanently (status code) 22 |  | 301 Moved Permanently (status code) 22 |
| 302 Found (status code) 22 |  | 302 Found (status code) 23 |
| 303 See Other (status code) 23 |  | 303 See Other (status code) 23 |
| 304 Not Modified (status code) 23 |  | 304 Not Modified (status code) 24 |
| 305 Use Proxy (status code) 23 |  | 305 Use Proxy (status code) 24 |
| 306 (Unused) (status code) 24 |  | 306 (Unused) (status code) 24 |
| 307 Temporary Redirect (status code) 24 |  | 307 Temporary Redirect (status code) 24 |
| 4 |  | 4 |
| 400 Bad Request (status code) 25 |  | 400 Bad Request (status code) 25 |
| 401 Unauthorized (status code) 25 |  | 401 Unauthorized (status code) 25 |
| 402 Payment Required (status code) 25 |  | 402 Payment Required (status code) 25 |
| 403 Forbidden (status code) 25 |  | 403 Forbidden (status code) 25 |
| 404 Not Found (status code) 25 |  | 404 Not Found (status code) 26 |
| 405 Method Not Allowed (status code) 25 |  | 405 Method Not Allowed (status code) 26 |
| 406 Not Acceptable (status code) 25 |  | 406 Not Acceptable (status code) 26 |
| 407 Proxy Authentication Required (status code) 26 |  | 407 Proxy Authentication Required (status code) 26 |
| 408 Request Timeout (status code) 26 |  | 408 Request Timeout (status code) 27 |
| 409 Conflict (status code) 26 |  | 409 Conflict (status code) 27 |
| 410 Gone (status code) 27 |  | 410 Gone (status code) 27 |
| 411 Length Required (status code) 27 |  | 411 Length Required (status code) 28 |
| 412 Precondition Failed (status code) 27 |  | 412 Precondition Failed (status code) 28 |
| 413 Request Entity Too Large (status code) 27 |  | 413 Request Entity Too Large (status code) 28 |
| 414 Request-URI Too Long (status code) 28 |  | 414 Request-URI Too Long (status code) 28 |
| 415 Unsupported Media Type (status code) 28 |  | 415 Unsupported Media Type (status code) 28 |
| 416 Requested Range Not Satisfiable (status code) 28 |  | 416 Requested Range Not Satisfiable (status code) 28 |
| 417 Expectation Failed (status code) 28 |  | 417 Expectation Failed (status code) 29 |
| 5 |  | 5 |
| 500 Internal Server Error (status code) 28 |  | 500 Internal Server Error (status code) 29 |
| 501 Not Implemented (status code) 29 |  | 501 Not Implemented (status code) 29 |
| 502 Bad Gateway (status code) 29 |  | 502 Bad Gateway (status code) 29 |
| 503 Service Unavailable (status code) 29 |  | 503 Service Unavailable (status code) 29 |
| 504 Gateway Timeout (status code) 29 |  | 504 Gateway Timeout (status code) 30 |
| 505 HTTP Version Not Supported (status code) 29 |  | 505 HTTP Version Not Supported (status code) 30 |
| A |  | A |
| Allow header 30 |  | Allow header 30 |
| C |  | C |
| CONNECT method 18 |  | CONNECT method 18 |
| D |  | D |
| DELETE method 17 |  | DELETE method 17 |
| E |  | E |
| Expect header 30 |  | Expect header 31 |
| F |  | F |
| From header 31 |  | From header 31 |
| G |  | G |
| GET method 14 |  | GET method 14 |
| Grammar |  | Grammar |
| Allow 30 |  | Allow 30 |
| delta-seconds 34 |  | delta-seconds 34 |
| Expect 30 |  | Expect 31 |
| expect-params 30 |  | expect-params 31 |
| expectation 30 |  | expectation 31 |
| expectation-extension 30 |  | expectation-extension 31 |
| extension-code 10 |  | extension-code 10 |
| extension-method 8 |  | extension-method 8 |
| From 31 |  | From 32 |
| Location 32 |  | Location 32 |
| Max-Forwards 33 |  | Max-Forwards 33 |
| Method 8 |  | Method 8 |
| Reason-Phrase 10 |  | Reason-Phrase 10 |
| Referer 33 |  | Referer 34 |
| request-header 9 |  | request-header 9 |
| response-header 11 |  | response-header 11 |
| Retry-After 34 |  | Retry-After 34 |
| Server 34 |  | Server 35 |
| Status-Code 10 |  | Status-Code 10 |
| User-Agent 35 |  | User-Agent 35 |
| H |  | H |
| HEAD method 14 |  | HEAD method 15 |
| Headers |  | Headers |
| Allow 30 |  | Allow 30 |
| Expect 30 |  | Expect 31 |
| From 31 |  | From 31 |
| Location 32 |  | Location 32 |
| Max-Forwards 33 |  | Max-Forwards 33 |
| Referer 33 |  | Referer 33 |
| Retry-After 34 |  | Retry-After 34 |
| Server 34 |  | Server 34 |
| User-Agent 35 |  | User-Agent 35 |
| L |  | L |
| LINK method 39 |  | LINK method 41 |
| Location header 32 |  | Location header 32 |
| M |  | M |
| Max-Forwards header 33 |  | Max-Forwards header 33 |
| Methods |  | Methods |
| CONNECT 18 |  | CONNECT 18 |
| DELETE 17 |  | DELETE 17 |
| GET 14 |  | GET 14 |
| HEAD 14 |  | HEAD 15 |
| LINK 39 |  | LINK 41 |
| OPTIONS 13 |  | OPTIONS 13 |
| PATCH 39 |  | PATCH 41 |
| POST 15 |  | POST 15 |
| PUT 16 |  | PUT 16 |
| TRACE 17 |  | TRACE 17 |
| UNLINK 39 |  | UNLINK 41 |
| O |  | O |
| OPTIONS method 13 |  | OPTIONS method 13 |
| P |  | P |
| PATCH method 39 |  | PATCH method 41 |
| POST method 15 |  | POST method 15 |
| PUT method 16 |  | PUT method 16 |
| R |  | R |
| Referer header 33 |  | Referer header 33 |
| Retry-After header 34 |  | Retry-After header 34 |
| S |  | S |
| Server header 34 |  | Server header 34 |
| Status Codes |  | Status Codes |
| 100 Continue 18 |  | 100 Continue 19 |
| 101 Switching Protocols 19 |  | 101 Switching Protocols 19 |
| 200 OK 19 |  | 200 OK 19 |
| 201 Created 19 |  | 201 Created 20 |
| 202 Accepted 20 |  | 202 Accepted 20 |
| 203 Non-Authoritative Information 20 |  | 203 Non-Authoritative Information 20 |
| 204 No Content 20 |  | 204 No Content 21 |
| 205 Reset Content 21 |  | 205 Reset Content 21 |
| 206 Partial Content 21 |  | 206 Partial Content 21 |
| 300 Multiple Choices 21 |  | 300 Multiple Choices 22 |
| 301 Moved Permanently 22 |  | 301 Moved Permanently 22 |
| 302 Found 22 |  | 302 Found 23 |
| 303 See Other 23 |  | 303 See Other 23 |
| 304 Not Modified 23 |  | 304 Not Modified 24 |
| 305 Use Proxy 23 |  | 305 Use Proxy 24 |
| 306 (Unused) 24 |  | 306 (Unused) 24 |
| 307 Temporary Redirect 24 |  | 307 Temporary Redirect 24 |
| 400 Bad Request 25 |  | 400 Bad Request 25 |
| 401 Unauthorized 25 |  | 401 Unauthorized 25 |
| 402 Payment Required 25 |  | 402 Payment Required 25 |
| 403 Forbidden 25 |  | 403 Forbidden 25 |
| 404 Not Found 25 |  | 404 Not Found 26 |
| 405 Method Not Allowed 25 |  | 405 Method Not Allowed 26 |
| 406 Not Acceptable 25 |  | 406 Not Acceptable 26 |
| 407 Proxy Authentication Required 26 |  | 407 Proxy Authentication Required 26 |
| 408 Request Timeout 26 |  | 408 Request Timeout 27 |
| 409 Conflict 26 |  | 409 Conflict 27 |
| 410 Gone 27 |  | 410 Gone 27 |
| 411 Length Required 27 |  | 411 Length Required 28 |
| 412 Precondition Failed 27 |  | 412 Precondition Failed 28 |
| 413 Request Entity Too Large 27 |  | 413 Request Entity Too Large 28 |
| 414 Request-URI Too Long 28 |  | 414 Request-URI Too Long 28 |
| 415 Unsupported Media Type 28 |  | 415 Unsupported Media Type 28 |
| 416 Requested Range Not Satisfiable 28 |  | 416 Requested Range Not Satisfiable 28 |
| 417 Expectation Failed 28 |  | 417 Expectation Failed 29 |
| 500 Internal Server Error 28 |  | 500 Internal Server Error 29 |
| 501 Not Implemented 29 |  | 501 Not Implemented 29 |
| 502 Bad Gateway 29 |  | 502 Bad Gateway 29 |
| 503 Service Unavailable 29 |  | 503 Service Unavailable 29 |
| 504 Gateway Timeout 29 |  | 504 Gateway Timeout 30 |
| 505 HTTP Version Not Supported 29 |  | 505 HTTP Version Not Supported 30 |
| T |  | T |
| TRACE method 17 |  | TRACE method 17 |
| U |  | U |
| UNLINK method 39 |  | UNLINK method 41 |
| User-Agent header 35 |  | 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 |
| skipping to change at page 48, line 44 |  | skipping to change at line 2290 |
| attempt made to obtain a general license or permission for the use of |  | attempt made to obtain a general license or permission for the use of |
| such proprietary rights by implementers or users of this |  | such proprietary rights by implementers or users of this |
| specification can be obtained from the IETF on-line IPR repository at |  | specification can be obtained from the IETF on-line IPR repository at |
| http://www.ietf.org/ipr. |  | http://www.ietf.org/ipr. |
| The IETF invites any interested party to bring to its attention any |  | The IETF invites any interested party to bring to its attention any |
| copyrights, patents or patent applications, or other proprietary |  | copyrights, patents or patent applications, or other proprietary |
| rights that may cover technology that may be required to implement |  | rights that may cover technology that may be required to implement |
| this standard. Please address the information to the IETF at |  | this standard. Please address the information to the IETF at |
| ietf-ipr@ietf.org. |  | ietf-ipr@ietf.org. |
| Acknowledgment |  |  |
| Funding for the RFC Editor function is provided by the IETF |  |  |
| Administrative Support Activity (IASA). |  |  |
End of changes. 88 change blocks.
| 180 lines changed or deleted |  | 326 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/