| draft-ietf-httpbis-p2-semantics-00.txt |  | draft-ietf-httpbis-p2-semantics-01.txt |
--- | --- | --- | --- | ---
| Network Working Group R. Fielding, Ed. |  | Network Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2068, 2616 J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| (if approved) One Laptop per Child |  | Intended status: Standards Track One Laptop per Child |
| Intended status: Standards Track J. Mogul |  | Expires: July 15, 2008 J. Mogul |
| Expires: June 22, 2008 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 |
| December 20, 2007 |  | Y. Lafon, Ed. |
|  |  | W3C |
|  |  | J. Reschke, Ed. |
|  |  | greenbytes |
|  |  | January 12, 2008 |
| HTTP/1.1, part 2: Message Semantics |  | HTTP/1.1, part 2: Message Semantics |
| draft-ietf-httpbis-p2-semantics-00 |  | draft-ietf-httpbis-p2-semantics-01 |
| 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 45 |  | 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 June 22, 2008. |  | This Internet-Draft will expire on July 15, 2008. |
| Copyright Notice |  | Copyright Notice |
| Copyright (C) The IETF Trust (2007). |  | 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, |
| request-header fields, response status codes, and response-header |  | request-header fields, response status codes, and response-header |
| fields. |  | fields. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| This version of the HTTP specification contains only minimal |  |  |
| editorial changes from [RFC2616] (abstract, introductory paragraph, |  |  |
| and authors' addresses). All other changes are due to partitioning |  |  |
| the original into seven mostly independent parts. The intent is for |  |  |
| readers of future drafts to able to use draft 00 as the basis for |  |  |
| comparison when the WG makes later changes to the specification text. |  |  |
| This draft will shortly be followed by draft 01 (containing the first |  |  |
| round of changes that have already been agreed to on the mailing |  |  |
| list). There is no point in reviewing this draft other than to |  |  |
| verify that the partitioning has been done correctly. Roy T. |  |  |
| Fielding, Yves Lafon, and Julian Reschke will be the editors after |  |  |
| draft 00 is submitted. |  |  |
| 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://www3.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://www3.tools.ietf.org/wg/httpbis/>. |  | <http://www.tools.ietf.org/wg/httpbis/>. |
|  |  | This draft incorporates those issue resolutions that were either |
|  |  | 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 6 |  | 3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 7 |  | 4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 7 |
| 6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 9 |  | 5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 8 |
| 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 |  | 6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 10 |
| 8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 10 |  | 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 |
| 8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 10 |  | 8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 11 |
| 8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 10 |  | 8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 11 |
| 8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 10 |  | 8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 11 |
| 8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 11 |
| 8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 15 |  | 8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 |
| 8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 15 |  | 8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 16 |  | 8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 16 |  | 9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 17 |
| 9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 16 |  | 9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 17 |
| 9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 17 |  | 9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 17 |
| 9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 17 |  | 9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 18 |
| 9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 18 |
| 9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 17 |  | 9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 18 |  | 9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 18 |
| 9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 18 |  | 9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 19 |
| 9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 18 |  | 9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 19 |
| 9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 19 |  | 9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 19 |
| 9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 19 |  | 9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 20 |
| 9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 19 |  | 9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 20 |
| 9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 19 |  | 9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 20 |
| 9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 20 |  | 9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 20 |
| 9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 20 |  | 9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 21 |
| 9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 21 |  | 9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 21 |
| 9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 21 |  | 9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 22 |
| 9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 21 |  | 9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 22 |
| 9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 22 |  | 9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 22 |
| 9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 22 |  | 9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 23 |
| 9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 22 |  | 9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 23 |
| 9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 23 |  | 9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 23 |
| 9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 23 |  | 9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 24 |
| 9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 23 |  | 9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 24 |
| 9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 23 |  | 9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 24 |
| 9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 23 |  | 9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 24 |
| 9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 23 |  | 9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 24 |
| 9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 23 |  | 9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 24 |
| 9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 24 |  | 9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 24 |
| 9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 24 |  | 9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 25 |
| 9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 24 |  | 9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 25 |
| 9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 25 |
| 9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 25 |  | 9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 26 |
| 9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 25 |  | 9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 26 |
| 9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 25 |  | 9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 26 |
| 9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 26 |  | 9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 26 |
| 9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 26 |  | 9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 27 |
| 9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 26 |  | 9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 27 |
| 9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 26 |  | 9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 27 |
| 9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 26 |  | 9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 27 |
| 9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 26 |  | 9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 27 |
| 9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 27 |  | 9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 27 |
| 9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 27 |  | 9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 28 |
| 9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 27 |  | 9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 28 |
| 9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 27 |  | 9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 28 |
| 9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 27 |  | 9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 28 |
| 10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 28 |  | 9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 28 |
| 10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 29 |
| 10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 30 |  | 10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 |
| 10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 30 |  | 10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 31 |
| 10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 |  | 10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 34 |
| 12. Security Considerations . . . . . . . . . . . . . . . . . . . 33 |  | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 |
| 12.1. Transfer of Sensitive Information . . . . . . . . . . . . 33 |  | 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 |
| 12.2. Encoding Sensitive Information in URI's . . . . . . . . . 34 |  | 12.1. Transfer of Sensitive Information . . . . . . . . . . . . 34 |
| 12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 34 |  | 12.2. Encoding Sensitive Information in URI's . . . . . . . . . 35 |
| 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 |  | 12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 36 |
| 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 |  | 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 |
| Appendix A. Changes from RFC 2068 . . . . . . . . . . . . . . . . 36 |  | 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 |  | 14.1. Normative References . . . . . . . . . . . . . . . . . . . 36 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 |  | 14.2. Informative References . . . . . . . . . . . . . . . . . . 37 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 43 |  | Appendix A. Compatibility with Previous Versions . . . . . . . . 37 |
|  |  | A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 37 |
|  |  | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 38 |
|  |  | Appendix B. Change Log (to be removed by RFC Editor before |
|  |  | publication) . . . . . . . . . . . . . . . . . . . . 39 |
|  |  | B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 39 |
|  |  | B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 39 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 |
|  |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 |
|  |  | Intellectual Property and Copyright Statements . . . . . . . . . . 47 |
| 1. Introduction |  | 1. Introduction |
| This document will define aspects of HTTP related to request and |  | This document defines HTTP/1.1 request and response semantics. Each |
| response semantics. Right now it only includes the extracted |  | HTTP message, as defined in [Part1], is in the form of either a |
| relevant sections of RFC 2616 with only minor edits. |  | request or a response. An HTTP server listens on a connection for |
|  |  | HTTP requests and responds to each request, in the order received on |
|  |  | that connection, with one or more HTTP response messages. This |
|  |  | document defines the commonly agreed upon semantics of the HTTP |
|  |  | uniform interface, the intentions defined by each request method, and |
|  |  | the various response messages that might be expected as a result of |
|  |  | applying that method for the requested resource. |
| The HTTP protocol is a request/response protocol. A client sends a |  | This document is currently disorganized in order to minimize the |
| request to the server in the form of a request method, URI, and |  | changes between drafts and enable reviewers to see the smaller errata |
| protocol version, followed by a MIME-like message containing request |  | changes. The next draft will reorganize the sections to better |
| modifiers, client information, and possible body content over a |  | reflect the content. In particular, the sections will be ordered |
| connection with a server. The server responds with a status line, |  | according to the typical processing of an HTTP request message (after |
| including the message's protocol version and a success or error code, |  | message parsing): resource mapping, general header fields, methods, |
| followed by a MIME-like message containing server information, entity |  | request modifiers, response status, and resource metadata. The |
| metainformation, and possible entity-body content. The relationship |  | current mess reflects how widely dispersed these topics and |
| between HTTP and MIME is described in Appendix A of [Part3]. |  | associated requirements had become in [RFC2616]. |
|  |  | 1.1. Requirements |
|  |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
|  |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
|  |  | document are to be interpreted as described in [RFC2119]. |
|  |  | An implementation is not compliant if it fails to satisfy one or more |
|  |  | of the MUST or REQUIRED level requirements for the protocols it |
|  |  | implements. An implementation that satisfies all the MUST or |
|  |  | REQUIRED level and all the SHOULD level requirements for its |
|  |  | protocols is said to be "unconditionally compliant"; one that |
|  |  | satisfies all the MUST level requirements but not all the SHOULD |
|  |  | level requirements for its protocols is said to be "conditionally |
|  |  | compliant." |
| 2. Product Tokens |  | 2. Product Tokens |
| Product tokens are used to allow communicating applications to |  | Product tokens are used to allow communicating applications to |
| identify themselves by software name and version. Most fields using |  | identify themselves by software name and version. Most fields using |
| product tokens also allow sub-products which form a significant part |  | product tokens also allow sub-products which form a significant part |
| of the application to be listed, separated by white space. By |  | of the application to be listed, separated by white space. By |
| convention, the products are listed in order of their significance |  | convention, the products are listed in order of their significance |
| for identifying the application. |  | for identifying the application. |
| skipping to change at page 7, line 35 |  | skipping to change at page 8, line 39 |
| 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. |
| 5. Status Code and Reason Phrase |  | 5. Status Code and Reason Phrase |
| The Status-Code element is a 3-digit integer result code of the |  | The Status-Code element is a 3-digit integer result code of the |
| attempt to understand and satisfy the request. These codes are fully |  | attempt to understand and satisfy the request. The status codes |
| defined in Section 9. The Reason-Phrase is intended to give a short |  | listed below are defined in Section 9. The Reason-Phrase is intended |
| textual description of the Status-Code. The Status-Code is intended |  | to give a short textual description of the Status-Code. The Status- |
| for use by automata and the Reason-Phrase is intended for the human |  | Code is intended for use by automata and the Reason-Phrase is |
| user. The client is not required to examine or display the Reason- |  | intended for the human user. The client is not required to examine |
| Phrase. |  | or display the Reason-Phrase. |
| The individual values of the numeric status codes defined for |  | The individual values of the numeric status codes defined for |
| HTTP/1.1, and an example set of corresponding Reason-Phrase's, are |  | HTTP/1.1, and an example set of corresponding Reason-Phrase's, are |
| presented below. The reason phrases listed here are only |  | presented below. The reason phrases listed here are only |
| recommendations -- they MAY be replaced by local equivalents without |  | recommendations -- they MAY be replaced by local equivalents without |
| affecting the protocol. |  | affecting the protocol. |
| Status-Code = |  | Status-Code = |
| "100" ; Section 9.1.1: Continue |  | "100" ; Section 9.1.1: Continue |
| | "101" ; Section 9.1.2: Switching Protocols |  | | "101" ; Section 9.1.2: Switching Protocols |
| skipping to change at page 9, line 24 |  | skipping to change at page 10, line 24 |
| 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 5.1 |
| | Age ; [Part6], Section 3.1 |  | | Age ; [Part6], Section 15.1 |
| | ETag ; [Part4], Section 6.1 |  | | ETag ; [Part4], Section 6.1 |
| | Location ; Section 10.4 |  | | Location ; Section 10.4 |
| | Proxy-Authenticate ; [Part7], Section 3.2 |  | | Proxy-Authenticate ; [Part7], Section 3.2 |
| | Retry-After ; Section 10.7 |  | | Retry-After ; Section 10.7 |
| | Server ; Section 10.8 |  | | Server ; Section 10.8 |
| | Vary ; [Part6], Section 3.5 |  | | Vary ; [Part6], Section 15.5 |
| | WWW-Authenticate ; [Part7], Section 3.4 |  | | WWW-Authenticate ; [Part7], Section 3.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 13, line 19 |  | skipping to change at page 14, line 19 |
| information contained in the response MAY be used to update a |  | information contained in the response MAY be used to update a |
| previously cached entity from that resource. If the new field values |  | previously cached entity from that resource. If the new field values |
| indicate that the cached entity differs from the current entity (as |  | indicate that the cached entity differs from the current entity (as |
| would be indicated by a change in Content-Length, Content-MD5, ETag |  | would be indicated by a change in Content-Length, Content-MD5, ETag |
| or Last-Modified), then the cache MUST treat the cache entry as |  | or Last-Modified), then the cache MUST treat the cache entry as |
| stale. |  | stale. |
| 8.5. POST |  | 8.5. POST |
| The POST method is used to request that the origin server accept the |  | The POST method is used to request that the origin server accept the |
| entity enclosed in the request as a new subordinate of the resource |  | entity enclosed in the request as data to be processed by the |
| identified by the Request-URI in the Request-Line. POST is designed |  | resource identified by the Request-URI in the Request-Line. POST is |
| to allow a uniform method to cover the following functions: |  | designed to allow a uniform method to cover the following functions: |
| o Annotation of existing resources; |  | o Annotation of existing resources; |
| o Posting a message to a bulletin board, newsgroup, mailing list, or |  | o Posting a message to a bulletin board, newsgroup, mailing list, or |
| similar group of articles; |  | similar group of articles; |
| o Providing a block of data, such as the result of submitting a |  | o Providing a block of data, such as the result of submitting a |
| form, to a data-handling process; |  | form, to a data-handling process; |
| o Extending a database through an append operation. |  | o Extending a database through an append operation. |
| The actual function performed by the POST method is determined by the |  | The actual function performed by the POST method is determined by the |
| server and is usually dependent on the Request-URI. The posted |  | server and is usually dependent on the Request-URI. |
| entity is subordinate to that URI in the same way that a file is |  |  |
| subordinate to a directory containing it, a news article is |  |  |
| subordinate to a newsgroup to which it is posted, or a record is |  |  |
| subordinate to a database. |  |  |
| The action performed by the POST method might not result in a |  | The action performed by the POST method might not result in a |
| resource that can be identified by a URI. In this case, either 200 |  | resource that can be identified by a URI. In this case, either 200 |
| (OK) or 204 (No Content) is the appropriate response status, |  | (OK) or 204 (No Content) is the appropriate response status, |
| depending on whether or not the response includes an entity that |  | depending on whether or not the response includes an entity that |
| describes the result. |  | describes the result. |
| If a resource has been created on the origin server, the response |  | If a resource has been created on the origin server, the response |
| SHOULD be 201 (Created) and contain an entity which describes the |  | SHOULD be 201 (Created) and contain an entity which describes the |
| 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. |
| POST requests MUST obey the message transmission requirements set out |  |  |
| in Section 7.2 of [Part1]. |  |  |
| See Section 12.2 for security considerations. |  |  |
| 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, the origin server MUST inform the user agent |
| skipping to change at page 15, line 11 |  | skipping to change at page 15, line 51 |
| A single resource MAY be identified by many different URIs. For |  | A single resource MAY be identified by many different URIs. For |
| example, an article might have a URI for identifying "the current |  | example, an article might have a URI for identifying "the current |
| version" which is separate from the URI identifying each particular |  | version" which is separate from the URI identifying each particular |
| version. In this case, a PUT request on a general URI might result |  | version. In this case, a PUT request on a general URI might result |
| in several other URIs being defined by the origin server. |  | in several other URIs being defined by the origin server. |
| HTTP/1.1 does not define how a PUT method affects the state of an |  | HTTP/1.1 does not define how a PUT method affects the state of an |
| origin server. |  | origin server. |
| PUT requests MUST obey the message transmission requirements set out |  |  |
| in Section 7.2 of [Part1]. |  |  |
| Unless otherwise specified for a particular entity-header, the |  | Unless otherwise specified for a particular entity-header, the |
| entity-headers in the PUT request SHOULD be applied to the resource |  | entity-headers in the PUT request SHOULD be applied to the resource |
| created or modified by the PUT. |  | created or modified by the PUT. |
| 8.7. DELETE |  | 8.7. DELETE |
| The DELETE method requests that the origin server delete the resource |  | The DELETE method requests that the origin server delete the resource |
| identified by the Request-URI. This method MAY be overridden by |  | identified by the Request-URI. This method MAY be overridden by |
| human intervention (or other means) on the origin server. The client |  | human intervention (or other means) on the origin server. The client |
| cannot be guaranteed that the operation has been carried out, even if |  | cannot be guaranteed that the operation has been carried out, even if |
| skipping to change at page 20, line 31 |  | skipping to change at page 21, line 24 |
| URIs. Clients with link editing capabilities ought to automatically |  | URIs. Clients with link editing capabilities ought to automatically |
| re-link references to the Request-URI to one or more of the new |  | re-link references to the Request-URI to one or more of the new |
| references returned by the server, where possible. This response is |  | references returned by the server, where possible. This response is |
| cacheable unless indicated otherwise. |  | cacheable unless indicated otherwise. |
| The new permanent URI SHOULD be given by the Location field in the |  | The new permanent URI SHOULD be given by the Location field in the |
| response. Unless the request method was HEAD, the entity of the |  | response. Unless the request method was HEAD, the entity of the |
| response SHOULD contain a short hypertext note with a hyperlink to |  | response SHOULD contain a short hypertext note with a hyperlink to |
| the new URI(s). |  | the new URI(s). |
| If the 301 status code is received in response to a request other |  | If the 301 status code is received in response to a request method |
| than GET or HEAD, the user agent MUST NOT automatically redirect the |  | that is known to be "safe", as defined in Section 8.1.1, then the |
| request unless it can be confirmed by the user, since this might |  | request MAY be automatically redirected by the user agent without |
| change the conditions under which the request was issued. |  | confirmation. Otherwise, the user agent MUST NOT automatically |
|  |  | redirect the request unless it can be confirmed by the user, since |
|  |  | this might change the conditions under which the request was issued. |
| Note: When automatically redirecting a POST request after |  | Note: When automatically redirecting a POST request after |
| receiving a 301 status code, some existing HTTP/1.0 user agents |  | receiving a 301 status code, some existing HTTP/1.0 user agents |
| will erroneously change it into a GET request. |  | will erroneously change it into a GET request. |
| 9.3.3. 302 Found |  | 9.3.3. 302 Found |
| The requested resource resides temporarily under a different URI. |  | The requested resource resides temporarily under a different URI. |
| Since the redirection might be altered on occasion, the client SHOULD |  | Since the redirection might be altered on occasion, the client SHOULD |
| continue to use the Request-URI for future requests. This response |  | continue to use the Request-URI for future requests. This response |
| is only cacheable if indicated by a Cache-Control or Expires header |  | is only cacheable if indicated by a Cache-Control or Expires header |
| field. |  | field. |
| The temporary URI SHOULD be given by the Location field in the |  | The temporary URI SHOULD be given by the Location field in the |
| response. Unless the request method was HEAD, the entity of the |  | response. Unless the request method was HEAD, the entity of the |
| response SHOULD contain a short hypertext note with a hyperlink to |  | response SHOULD contain a short hypertext note with a hyperlink to |
| the new URI(s). |  | the new URI(s). |
| If the 302 status code is received in response to a request other |  | If the 302 status code is received in response to a request method |
| than GET or HEAD, the user agent MUST NOT automatically redirect the |  | that is known to be "safe", as defined in Section 8.1.1, then the |
| request unless it can be confirmed by the user, since this might |  | request MAY be automatically redirected by the user agent without |
| change the conditions under which the request was issued. |  | confirmation. Otherwise, the user agent MUST NOT automatically |
|  |  | redirect the request unless it can be confirmed by the user, since |
|  |  | this might change the conditions under which the request was issued. |
| Note: RFC 1945 and RFC 2068 specify that the client is not allowed |  | Note: [RFC1945] and [RFC2068] specify that the client is not |
| to change the method on the redirected request. However, most |  | allowed to change the method on the redirected request. However, |
| existing user agent implementations treat 302 as if it were a 303 |  | most existing user agent implementations treat 302 as if it were a |
| response, performing a GET on the Location field-value regardless |  | 303 response, performing a GET on the Location field-value |
| of the original request method. The status codes 303 and 307 have |  | regardless of the original request method. The status codes 303 |
| been added for servers that wish to make unambiguously clear which |  | and 307 have been added for servers that wish to make |
| kind of reaction is expected of the client. |  | unambiguously clear which kind of reaction is expected of the |
|  |  | 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 response to the request can be found under a different URI and |
| SHOULD be retrieved using a GET method on that resource. This method |  | SHOULD be retrieved using a GET method on that resource. This method |
| exists primarily to allow the output of a POST-activated script to |  | exists primarily to allow the output of a POST-activated script to |
| redirect the user agent to a selected resource. The new URI is not a |  | redirect the user agent to a selected resource. The new URI is not a |
| substitute reference for the originally requested resource. The 303 |  | substitute reference for the originally requested resource. The 303 |
| response MUST NOT be cached, but the response to the second |  | response MUST NOT be cached, but the response to the second |
| (redirected) request might be cacheable. |  | (redirected) request might be cacheable. |
| skipping to change at page 21, line 51 |  | skipping to change at page 22, line 48 |
| 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 requested resource MUST be accessed through the proxy given by |
| the Location field. The Location field gives the URI of the proxy. |  | the Location field. The Location field gives the URI of the proxy. |
| The recipient is expected to repeat this single request via the |  | The recipient is expected to repeat this single request via the |
| proxy. 305 responses MUST only be generated by origin servers. |  | proxy. 305 responses MUST only be generated by origin servers. |
| Note: RFC 2068 was not clear that 305 was intended to redirect a |  | Note: [RFC2068] was not clear that 305 was intended to redirect a |
| single request, and to be generated by origin servers only. Not |  | single request, and to be generated by origin servers only. Not |
| observing these limitations has significant security consequences. |  | 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 |
| skipping to change at page 22, line 27 |  | skipping to change at page 23, line 26 |
| field. |  | field. |
| The temporary URI SHOULD be given by the Location field in the |  | The temporary URI SHOULD be given by the Location field in the |
| response. Unless the request method was HEAD, the entity of the |  | response. Unless the request method was HEAD, the entity of the |
| response SHOULD contain a short hypertext note with a hyperlink to |  | response SHOULD contain a short hypertext note with a hyperlink to |
| the new URI(s) , since many pre-HTTP/1.1 user agents do not |  | the new URI(s) , since many pre-HTTP/1.1 user agents do not |
| understand the 307 status. Therefore, the note SHOULD contain the |  | understand the 307 status. Therefore, the note SHOULD contain the |
| information necessary for a user to repeat the original request on |  | information necessary for a user to repeat the original request on |
| the new URI. |  | the new URI. |
| If the 307 status code is received in response to a request other |  | If the 307 status code is received in response to a request method |
| than GET or HEAD, the user agent MUST NOT automatically redirect the |  | that is known to be "safe", as defined in Section 8.1.1, then the |
| request unless it can be confirmed by the user, since this might |  | request MAY be automatically redirected by the user agent without |
| change the conditions under which the request was issued. |  | confirmation. Otherwise, the user agent MUST NOT automatically |
|  |  | redirect the request unless it can be confirmed by the user, since |
|  |  | this might change the conditions under which the request was issued. |
| 9.4. Client Error 4xx |  | 9.4. Client Error 4xx |
| The 4xx class of status code is intended for cases in which the |  | The 4xx class of status code is intended for cases in which the |
| client seems to have erred. Except when responding to a HEAD |  | client seems to have erred. Except when responding to a HEAD |
| request, the server SHOULD include an entity containing an |  | request, the server SHOULD include an entity containing an |
| explanation of the error situation, and whether it is a temporary or |  | explanation of the error situation, and whether it is a temporary or |
| permanent condition. These status codes are applicable to any |  | permanent condition. These status codes are applicable to any |
| request method. User agents SHOULD display any included entity to |  | request method. User agents SHOULD display any included entity to |
| the user. |  | the user. |
| skipping to change at page 28, line 7 |  | skipping to change at page 29, line 7 |
| The server does not support, or refuses to support, the HTTP protocol |  | The server does not support, or refuses to support, the HTTP 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 all standard |  | This section defines the syntax and semantics of HTTP/1.1 header |
| HTTP/1.1 header fields. For entity-header fields, both sender and |  | fields related to request and response semantics. |
| recipient refer to either the client or the server, depending on who |  |  |
| sends and who receives the entity. |  | For entity-header fields, both sender and recipient refer to either |
|  |  | the client or the server, depending on who sends and who receives the |
|  |  | entity. |
| 10.1. Allow |  | 10.1. Allow |
| The Allow entity-header field lists the set of methods supported by |  | The Allow entity-header field lists the set of methods supported by |
| the resource identified by the Request-URI. The purpose of this |  | the resource identified by the Request-URI. The purpose of this |
| field is strictly to inform the recipient of valid methods associated |  | field is strictly to inform the recipient of valid methods associated |
| with the resource. An Allow header field MUST be present in a 405 |  | with the resource. An Allow header field MUST be present in a 405 |
| (Method Not Allowed) response. |  | (Method Not Allowed) response. |
| Allow = "Allow" ":" #Method |  | Allow = "Allow" ":" #Method |
| skipping to change at page 29, line 29 |  | skipping to change at page 30, line 31 |
| The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST |  | The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST |
| return a 417 (Expectation Failed) status if it receives a request |  | return a 417 (Expectation Failed) status if it receives a request |
| with an expectation that it cannot meet. However, the Expect |  | with an expectation that it cannot meet. However, the Expect |
| request-header itself is end-to-end; it MUST be forwarded if the |  | request-header itself is end-to-end; it MUST be forwarded if the |
| request is forwarded. |  | request is forwarded. |
| Many older HTTP/1.0 and HTTP/1.1 applications do not understand the |  | Many older HTTP/1.0 and HTTP/1.1 applications do not understand the |
| Expect header. |  | Expect header. |
| See Section 7.2.3 of [Part1] for the use of the 100 (continue) |  | See Section 7.2.3 of [Part1] for the use of the 100 (Continue) |
| status. |  | status. |
| 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 RFC 822 [RFC822] as updated by RFC 1123 [RFC1123]: |  | in Section 3.4 of [RFC2822]: |
| From = "From" ":" mailbox |  | From = "From" ":" mailbox |
| An example is: |  | An example is: |
| From: webmaster@w3.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 |
| header so that the person responsible for running the robot can be |  | header so that the person responsible for running the robot can be |
| contacted if problems occur on the receiving end. |  | contacted if problems occur on the receiving end. |
| skipping to change at page 30, line 27 |  | skipping to change at page 31, line 29 |
| 10.4. Location |  | 10.4. Location |
| The Location response-header field is used to redirect the recipient |  | The Location response-header field is used to redirect the recipient |
| to a location other than the Request-URI for completion of the |  | to a location other than the Request-URI for completion of the |
| request or identification of a new resource. For 201 (Created) |  | request or identification of a new resource. 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 |  | Location = "Location" ":" absoluteURI [ "#" fragment ] |
| An example is: |  | An example is: |
| Location: http://www.w3.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 5.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 |
|  |  | URL would not be appropriate: |
|  |  | o With a 201 Created response, because in this usage the Location |
|  |  | header specifies the URL for the entire created resource. |
|  |  | o With a 300 Multiple Choices, since the choice decision is intended |
|  |  | to be made on resource characteristics and not fragment |
|  |  | characteristics. |
|  |  | o With 305 Use Proxy. |
| 10.5. Max-Forwards |  | 10.5. Max-Forwards |
| The Max-Forwards request-header field provides a mechanism with the |  | The Max-Forwards request-header field provides a mechanism with the |
| TRACE (Section 8.8) and OPTIONS (Section 8.2) methods to limit the |  | TRACE (Section 8.8) and OPTIONS (Section 8.2) methods to limit the |
| number of proxies or gateways that can forward the request to the |  | number of proxies or gateways that can forward the request to the |
| next inbound server. This can be useful when the client is |  | next inbound server. This can be useful when the client is |
| attempting to trace a request chain which appears to be failing or |  | attempting to trace a request chain which appears to be failing or |
| looping in mid-chain. |  | looping in mid-chain. |
| Max-Forwards = "Max-Forwards" ":" 1*DIGIT |  | Max-Forwards = "Max-Forwards" ":" 1*DIGIT |
| skipping to change at page 31, line 33 |  | skipping to change at page 32, line 49 |
| server to generate lists of back-links to resources for interest, |  | server to generate lists of back-links to resources for interest, |
| logging, optimized caching, etc. It also allows obsolete or mistyped |  | logging, optimized caching, etc. It also allows obsolete or mistyped |
| links to be traced for maintenance. The Referer field MUST NOT be |  | links to be traced for maintenance. The Referer field MUST NOT be |
| sent if the Request-URI was obtained from a source that does not have |  | sent if the Request-URI was obtained from a source that does not have |
| its own URI, such as input from the user keyboard. |  | its own URI, such as input from the user keyboard. |
| Referer = "Referer" ":" ( absoluteURI | relativeURI ) |  | Referer = "Referer" ":" ( absoluteURI | relativeURI ) |
| Example: |  | Example: |
| Referer: http://www.w3.org/hypertext/DataSources/Overview.html |  | Referer: http://www.example.org/hypertext/Overview.html |
| If the field value is a relative URI, it SHOULD be interpreted |  | If the field value is a relative URI, it SHOULD be interpreted |
| relative to the Request-URI. The URI MUST NOT include a fragment. |  | relative to the Request-URI. The URI MUST NOT include a fragment. |
| See Section 12.2 for security considerations. |  | See Section 12.2 for security considerations. |
| 10.7. Retry-After |  | 10.7. Retry-After |
| 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 |
| skipping to change at page 32, line 26 |  | skipping to change at page 33, line 43 |
| application. |  | 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 |
| SHOULD 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]). |
| Note: Revealing the specific software version of the server might |  | Note: Revealing the specific software version of the server might |
| allow the server machine to become more vulnerable to attacks |  | allow the server machine to become more vulnerable to attacks |
| against software that is known to contain security holes. Server |  | against software that is known to contain security holes. Server |
| implementors are encouraged to make this field a configurable |  | implementors are encouraged to make this field a configurable |
| 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 |
| skipping to change at page 34, line 46 |  | skipping to change at page 36, line 17 |
| 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 |
| Based on an XML translation of RFC 2616 by Julian Reschke. |  |  |
| 14. References |  | 14. References |
| [Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web |  | 14.1. Normative References |
| proxy servers", Work in Progress. |  |  |
| [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| part 1: URIs, Connections, and Message Parsing", |  | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |
| draft-ietf-httpbis-p1-messaging-00 (work in progress), |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-01 |
| December 2007. |  | (work in progress), January 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., and T. Berners-Lee, "HTTP/1.1, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| part 3: Message Payload and Content Negotiation", |  | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |
| draft-ietf-httpbis-p3-payload-00 (work in progress), |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-01 |
| December 2007. |  | (work in progress), January 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., and T. Berners-Lee, "HTTP/1.1, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| part 4: Conditional Requests", |  | and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional |
| draft-ietf-httpbis-p4-conditional-00 (work in progress), |  | Requests", draft-ietf-httpbis-p4-conditional-01 (work in |
| December 2007. |  | progress), January 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., and T. Berners-Lee, "HTTP/1.1, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| part 5: Range Requests and Partial Responses", |  | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |
| draft-ietf-httpbis-p5-range-00 (work in progress), |  | Partial Responses", draft-ietf-httpbis-p5-range-01 (work |
| December 2007. |  | in progress), January 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., and T. Berners-Lee, "HTTP/1.1, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| part 6: Caching", draft-ietf-httpbis-p6-cache-00 (work in |  | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |
| progress), December 2007. |  | draft-ietf-httpbis-p6-cache-01 (work in progress), |
|  |  | January 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., and T. Berners-Lee, "HTTP/1.1, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| part 7: Authentication", draft-ietf-httpbis-p7-auth-00 |  | and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", |
| (work in progress), December 2007. |  | draft-ietf-httpbis-p7-auth-01 (work in progress), |
|  |  | January 2008. |
| [RFC1123] Braden, R., "Requirements for Internet Hosts - Application |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| and Support", STD 3, RFC 1123, October 1989. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
|  |  | 14.2. Informative References |
|  |  | [Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web |
|  |  | proxy servers", draft-luotonen-web-proxy-tunneling-01 |
|  |  | (work in progress), August 1998. |
|  |  | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext |
|  |  | 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. |
| [RFC822] Crocker, D., "Standard for the format of ARPA Internet |  | [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, |
| text messages", STD 11, RFC 822, August 1982. |  | April 2001. |
| Appendix A. Changes from RFC 2068 |  | Appendix A. Compatibility with Previous Versions |
|  |  | 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). |
| CREATE had a race that required an Etag be sent when a resource is |  | 201 (Created) had a race that required an Etag be sent when a |
| first created. (Section 9.2.2). |  | resource is first created. (Section 9.2.2). |
| Rewrite of message transmission requirements to make it much harder |  | Rewrite of message transmission requirements to make it much harder |
| for implementors to get it wrong, as the consequences of errors here |  | for implementors to get it wrong, as the consequences of errors here |
| can have significant impact on the Internet, and to deal with the |  | can have significant impact on the Internet, and to deal with the |
| following problems: |  | following problems: |
| 1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where |  | 1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where |
| this was incorrectly placing a requirement on the behavior of an |  | this was incorrectly placing a requirement on the behavior of an |
| implementation of a future version of HTTP/1.x |  | implementation of a future version of HTTP/1.x |
| 2. Made it clear that user-agents should retry requests, not |  | 2. Made it clear that user-agents should retry requests, not |
| "clients" in general. |  | "clients" in general. |
| 3. Converted requirements for clients to ignore unexpected 100 |  | 3. Converted requirements for clients to ignore unexpected 100 |
| (Continue) responses, and for proxies to forward 100 responses, |  | (Continue) responses, and for proxies to forward 100 responses, |
| into a general requirement for 1xx responses. |  | into a general requirement for 1xx responses. |
| 4. Modified some TCP-specific language, to make it clearer that non- |  | 4. Modified some TCP-specific language, to make it clearer that non- |
| TCP transports are possible for HTTP. |  | TCP transports are possible for HTTP. |
| skipping to change at page 36, line 48 |  | skipping to change at page 38, line 29 |
| 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 RFC 2068 |  | implemented in previous versions of this specification. See |
| [RFC2068]. |  | [RFC2068]. |
|  |  | A.2. Changes from RFC 2616 |
|  |  | Clarify definition of POST. (Section 8.5) |
|  |  | Failed to consider that there are many other request methods that are |
|  |  | safe to automatically redirect, and further that the user agent is |
|  |  | able to make that determination based on the request method |
|  |  | semantics. (Sections 9.3.2, 9.3.3 and 9.3.8 ) |
|  |  | Correct syntax of Location header to allow fragment, as referred |
|  |  | symbol wasn't what was expected, and add some clarifications as to |
|  |  | when it would not be appropriate. (Section 10.4) |
|  |  | In the description of the Server header, the Via field was described |
|  |  | as a SHOULD. The requirement was and is stated correctly in the |
|  |  | description of the Via header in Section 8.9 of [Part1]. |
|  |  | (Section 10.8) |
|  |  | Appendix B. Change Log (to be removed by RFC Editor before publication) |
|  |  | B.1. Since RFC2616 |
|  |  | Extracted relevant partitions from [RFC2616]. |
|  |  | B.2. Since draft-ietf-httpbis-p2-semantics-00 |
|  |  | Closed issues: |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a |
|  |  | MUST" (<http://purl.org/NET/http-errata#via-must>) |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/6>: "Fragments |
|  |  | allowed in Location" |
|  |  | (<http://purl.org/NET/http-errata#location-fragments>) |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe |
|  |  | Methods vs Redirection" |
|  |  | (<http://purl.org/NET/http-errata#saferedirect>) |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/17>: "Revise |
|  |  | description of the POST method" |
|  |  | (<http://purl.org/NET/http-errata#post>) |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative |
|  |  | and Informative references" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606 |
|  |  | Compliance" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>: |
|  |  | "Informative references" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant |
|  |  | cross-references" |
|  |  | Other changes: |
|  |  | o Move definitions of 304 and 412 condition codes to [Part4] |
| Index |  | Index |
| 1 |  | 1 |
| 100 Continue (status code) 16 |  | 100 Continue (status code) 17 |
| 101 Switching Protocols (status code) 17 |  | 101 Switching Protocols (status code) 18 |
| 2 |  | 2 |
| 200 OK (status code) 17 |  | 200 OK (status code) 18 |
| 201 Created (status code) 17 |  | 201 Created (status code) 18 |
| 202 Accepted (status code) 18 |  | 202 Accepted (status code) 19 |
| 203 Non-Authoritative Information (status code) 18 |  | 203 Non-Authoritative Information (status code) 19 |
| 204 No Content (status code) 18 |  | 204 No Content (status code) 19 |
| 205 Reset Content (status code) 19 |  | 205 Reset Content (status code) 20 |
| 206 Partial Content (status code) 19 |  | 206 Partial Content (status code) 20 |
| 3 |  | 3 |
| 300 Multiple Choices (status code) 19 |  | 300 Multiple Choices (status code) 20 |
| 301 Moved Permanently (status code) 20 |  | 301 Moved Permanently (status code) 21 |
| 302 Found (status code) 20 |  | 302 Found (status code) 21 |
| 303 See Other (status code) 21 |  | 303 See Other (status code) 22 |
| 304 Not Modified (status code) 21 |  | 304 Not Modified (status code) 22 |
| 305 Use Proxy (status code) 21 |  | 305 Use Proxy (status code) 22 |
| 306 (Unused) (status code) 22 |  | 306 (Unused) (status code) 23 |
| 307 Temporary Redirect (status code) 22 |  | 307 Temporary Redirect (status code) 23 |
| 4 |  | 4 |
| 400 Bad Request (status code) 23 |  | 400 Bad Request (status code) 24 |
| 401 Unauthorized (status code) 23 |  | 401 Unauthorized (status code) 24 |
| 402 Payment Required (status code) 23 |  | 402 Payment Required (status code) 24 |
| 403 Forbidden (status code) 23 |  | 403 Forbidden (status code) 24 |
| 404 Not Found (status code) 23 |  | 404 Not Found (status code) 24 |
| 405 Method Not Allowed (status code) 23 |  | 405 Method Not Allowed (status code) 24 |
| 406 Not Acceptable (status code) 23 |  | 406 Not Acceptable (status code) 24 |
| 407 Proxy Authentication Required (status code) 24 |  | 407 Proxy Authentication Required (status code) 25 |
| 408 Request Timeout (status code) 24 |  | 408 Request Timeout (status code) 25 |
| 409 Conflict (status code) 24 |  | 409 Conflict (status code) 25 |
| 410 Gone (status code) 25 |  | 410 Gone (status code) 26 |
| 411 Length Required (status code) 25 |  | 411 Length Required (status code) 26 |
| 412 Precondition Failed (status code) 25 |  | 412 Precondition Failed (status code) 26 |
| 413 Request Entity Too Large (status code) 25 |  | 413 Request Entity Too Large (status code) 26 |
| 414 Request-URI Too Long (status code) 26 |  | 414 Request-URI Too Long (status code) 27 |
| 415 Unsupported Media Type (status code) 26 |  | 415 Unsupported Media Type (status code) 27 |
| 416 Requested Range Not Satisfiable (status code) 26 |  | 416 Requested Range Not Satisfiable (status code) 27 |
| 417 Expectation Failed (status code) 26 |  | 417 Expectation Failed (status code) 27 |
| 5 |  | 5 |
| 500 Internal Server Error (status code) 26 |  | 500 Internal Server Error (status code) 27 |
| 501 Not Implemented (status code) 27 |  | 501 Not Implemented (status code) 28 |
| 502 Bad Gateway (status code) 27 |  | 502 Bad Gateway (status code) 28 |
| 503 Service Unavailable (status code) 27 |  | 503 Service Unavailable (status code) 28 |
| 504 Gateway Timeout (status code) 27 |  | 504 Gateway Timeout (status code) 28 |
| 505 HTTP Version Not Supported (status code) 27 |  | 505 HTTP Version Not Supported (status code) 28 |
| A |  | A |
| Allow header 28 |  | Allow header 29 |
| C |  | C |
| CONNECT method 16 |  | CONNECT method 17 |
| D |  | D |
| DELETE method 15 |  | DELETE method 16 |
| E |  | E |
| Expect header 28 |  | Expect header 29 |
| F |  | F |
| From header 29 |  | From header 30 |
| G |  | G |
| GET method 12 |  | GET method 13 |
| Grammar |  | Grammar |
| Allow 28 |  | Allow 29 |
| Expect 28 |  | Expect 29 |
| expect-params 28 |  | expect-params 29 |
| expectation 28 |  | expectation 29 |
| expectation-extension 28 |  | expectation-extension 29 |
| extension-code 8 |  | extension-code 9 |
| extension-method 6 |  | extension-method 7 |
| From 29 |  | From 30 |
| Location 30 |  | Location 31 |
| Max-Forwards 30 |  | Max-Forwards 32 |
| Method 6 |  | Method 7 |
| product 5 |  | product 6 |
| product-version 5 |  | product-version 6 |
| Reason-Phrase 8 |  | Reason-Phrase 9 |
| Referer 31 |  | Referer 32 |
| request-header 7 |  | request-header 8 |
| response-header 9 |  | response-header 10 |
| Retry-After 31 |  | Retry-After 33 |
| Server 32 |  | Server 33 |
| Status-Code 8 |  | Status-Code 9 |
| User-Agent 32 |  | User-Agent 34 |
| H |  | H |
| HEAD method 12 |  | HEAD method 13 |
| Headers |  | Headers |
| Allow 28 |  | Allow 29 |
| Expect 28 |  | Expect 29 |
| From 29 |  | From 30 |
| Location 30 |  | Location 31 |
| Max-Forwards 30 |  | Max-Forwards 32 |
| Referer 31 |  | Referer 32 |
| Retry-After 31 |  | Retry-After 33 |
| Server 32 |  | Server 33 |
| User-Agent 32 |  | User-Agent 34 |
| L |  | L |
| LINK method 36 |  | LINK method 38 |
| Location header 30 |  | Location header 31 |
| M |  | M |
| Max-Forwards header 30 |  | Max-Forwards header 32 |
| Methods |  | Methods |
| CONNECT 16 |  | CONNECT 17 |
| DELETE 15 |  | DELETE 16 |
| GET 12 |  | GET 13 |
| HEAD 12 |  | HEAD 13 |
| LINK 36 |  | LINK 38 |
| OPTIONS 11 |  | OPTIONS 12 |
| PATCH 36 |  | PATCH 38 |
| POST 13 |  | POST 14 |
| PUT 14 |  | PUT 15 |
| TRACE 15 |  | TRACE 16 |
| UNLINK 36 |  | UNLINK 38 |
| O |  | O |
| OPTIONS method 11 |  | OPTIONS method 12 |
| P |  | P |
| PATCH method 36 |  | PATCH method 38 |
| POST method 13 |  | POST method 14 |
| PUT method 14 |  | PUT method 15 |
| R |  | R |
| Referer header 31 |  | Referer header 32 |
| Retry-After header 31 |  | Retry-After header 33 |
| S |  | S |
| Server header 32 |  | Server header 33 |
| Status Codes |  | Status Codes |
| 100 Continue 16 |  | 100 Continue 17 |
| 101 Switching Protocols 17 |  | 101 Switching Protocols 18 |
| 200 OK 17 |  | 200 OK 18 |
| 201 Created 17 |  | 201 Created 18 |
| 202 Accepted 18 |  | 202 Accepted 19 |
| 203 Non-Authoritative Information 18 |  | 203 Non-Authoritative Information 19 |
| 204 No Content 18 |  | 204 No Content 19 |
| 205 Reset Content 19 |  | 205 Reset Content 20 |
| 206 Partial Content 19 |  | 206 Partial Content 20 |
| 300 Multiple Choices 19 |  | 300 Multiple Choices 20 |
| 301 Moved Permanently 20 |  | 301 Moved Permanently 21 |
| 302 Found 20 |  | 302 Found 21 |
| 303 See Other 21 |  | 303 See Other 22 |
| 304 Not Modified 21 |  | 304 Not Modified 22 |
| 305 Use Proxy 21 |  | 305 Use Proxy 22 |
| 306 (Unused) 22 |  | 306 (Unused) 23 |
| 307 Temporary Redirect 22 |  | 307 Temporary Redirect 23 |
| 400 Bad Request 23 |  | 400 Bad Request 24 |
| 401 Unauthorized 23 |  | 401 Unauthorized 24 |
| 402 Payment Required 23 |  | 402 Payment Required 24 |
| 403 Forbidden 23 |  | 403 Forbidden 24 |
| 404 Not Found 23 |  | 404 Not Found 24 |
| 405 Method Not Allowed 23 |  | 405 Method Not Allowed 24 |
| 406 Not Acceptable 23 |  | 406 Not Acceptable 24 |
| 407 Proxy Authentication Required 24 |  | 407 Proxy Authentication Required 25 |
| 408 Request Timeout 24 |  | 408 Request Timeout 25 |
| 409 Conflict 24 |  | 409 Conflict 25 |
| 410 Gone 25 |  | 410 Gone 26 |
| 411 Length Required 25 |  | 411 Length Required 26 |
| 412 Precondition Failed 25 |  | 412 Precondition Failed 26 |
| 413 Request Entity Too Large 25 |  | 413 Request Entity Too Large 26 |
| 414 Request-URI Too Long 26 |  | 414 Request-URI Too Long 27 |
| 415 Unsupported Media Type 26 |  | 415 Unsupported Media Type 27 |
| 416 Requested Range Not Satisfiable 26 |  | 416 Requested Range Not Satisfiable 27 |
| 417 Expectation Failed 26 |  | 417 Expectation Failed 27 |
| 500 Internal Server Error 26 |  | 500 Internal Server Error 27 |
| 501 Not Implemented 27 |  | 501 Not Implemented 28 |
| 502 Bad Gateway 27 |  | 502 Bad Gateway 28 |
| 503 Service Unavailable 27 |  | 503 Service Unavailable 28 |
| 504 Gateway Timeout 27 |  | 504 Gateway Timeout 28 |
| 505 HTTP Version Not Supported 27 |  | 505 HTTP Version Not Supported 28 |
| T |  | T |
| TRACE method 15 |  | TRACE method 16 |
| U |  | U |
| UNLINK method 36 |  | UNLINK method 38 |
| User-Agent header 32 |  | User-Agent header 34 |
| 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 |
| skipping to change at page 43, line 5 |  | skipping to change at page 45, line 31 |
| World Wide Web Consortium |  | World Wide Web Consortium |
| MIT Computer Science and Artificial Intelligence Laboratory |  | MIT Computer Science and Artificial Intelligence Laboratory |
| The Stata Center, Building 32 |  | The Stata Center, Building 32 |
| 32 Vassar Street |  | 32 Vassar Street |
| Cambridge, MA 02139 |  | Cambridge, MA 02139 |
| USA |  | USA |
| Email: timbl@w3.org |  | Email: timbl@w3.org |
| URI: http://www.w3.org/People/Berners-Lee/ |  | URI: http://www.w3.org/People/Berners-Lee/ |
|  |  | Yves Lafon (editor) |
|  |  | World Wide Web Consortium |
|  |  | W3C / ERCIM |
|  |  | 2004, rte des Lucioles |
|  |  | Sophia-Antipolis, AM 06902 |
|  |  | France |
|  |  | Email: ylafon@w3.org |
|  |  | URI: http://www.raubacapeu.net/people/yves/ |
|  |  | Julian F. Reschke (editor) |
|  |  | greenbytes GmbH |
|  |  | Hafenweg 16 |
|  |  | Muenster, NW 48155 |
|  |  | Germany |
|  |  | Phone: +49 251 2807760 |
|  |  | Fax: +49 251 2807761 |
|  |  | Email: julian.reschke@greenbytes.de |
|  |  | URI: http://greenbytes.de/tech/webdav/ |
| Full Copyright Statement |  | Full Copyright Statement |
| Copyright (C) The IETF Trust (2007). |  | Copyright (C) The IETF Trust (2008). |
| This document is subject to the rights, licenses and restrictions |  | This document is subject to the rights, licenses and restrictions |
| contained in BCP 78, and except as set forth therein, the authors |  | contained in BCP 78, and except as set forth therein, the authors |
| retain all their rights. |  | retain all their rights. |
| This document and the information contained herein are provided on an |  | This document and the information contained herein are provided on an |
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |  | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |  | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |
| THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |  | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |
| OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |  | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |
End of changes. 74 change blocks.
| 357 lines changed or deleted |  | 481 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/