| draft-ietf-httpbis-p2-semantics-05.txt |  | draft-ietf-httpbis-p2-semantics-06.txt |
--- | --- | --- | --- | ---
| Network Working Group R. Fielding, Ed. |  | HTTPbis 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 |
| Updates: 2817 (if approved) One Laptop per Child |  | Updates: 2817 (if approved) One Laptop per Child |
| Intended status: Standards Track J. Mogul |  | Intended status: Standards Track J. Mogul |
| Expires: May 20, 2009 HP |  | Expires: September 10, 2009 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 |
| November 16, 2008 |  | March 9, 2009 |
| HTTP/1.1, part 2: Message Semantics |  | HTTP/1.1, part 2: Message Semantics |
| draft-ietf-httpbis-p2-semantics-05 |  | draft-ietf-httpbis-p2-semantics-06 |
| Status of this Memo |  | Status of this Memo |
| By submitting this Internet-Draft, each author represents that any |  | This Internet-Draft is submitted to IETF in full conformance with the |
| applicable patent or other IPR claims of which he or she is aware |  | provisions of BCP 78 and BCP 79. This document may contain material |
| have been or will be disclosed, and any of which he or she becomes |  | from IETF Documents or IETF Contributions published or made publicly |
| aware will be disclosed, in accordance with Section 6 of BCP 79. |  | available before November 10, 2008. The person(s) controlling the |
|  |  | copyright in some of this material may not have granted the IETF |
|  |  | Trust the right to allow modifications of such material outside the |
|  |  | IETF Standards Process. Without obtaining an adequate license from |
|  |  | the person(s) controlling the copyright in such materials, this |
|  |  | document may not be modified outside the IETF Standards Process, and |
|  |  | derivative works of it may not be created outside the IETF Standards |
|  |  | Process, except to format it for publication as an RFC or to |
|  |  | translate it into languages other than English. |
| 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 |
| other groups may also distribute working documents as Internet- |  | other groups may also distribute working documents as Internet- |
| Drafts. |  | Drafts. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| skipping to change at page 1, line 42 |  | skipping to change at page 2, line 4 |
| 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 |
| other groups may also distribute working documents as Internet- |  | other groups may also distribute working documents as Internet- |
| Drafts. |  | Drafts. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| 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 May 20, 2009. |  | This Internet-Draft will expire on September 10, 2009. |
|  |  | Copyright Notice |
|  |  | Copyright (c) 2009 IETF Trust and the persons identified as the |
|  |  | document authors. All rights reserved. |
|  |  | This document is subject to BCP 78 and the IETF Trust's Legal |
|  |  | Provisions Relating to IETF Documents in effect on the date of |
|  |  | publication of this document (http://trustee.ietf.org/license-info). |
|  |  | Please review these documents carefully, as they describe your rights |
|  |  | and restrictions with respect to this document. |
| 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 25 |  | skipping to change at page 2, line 43 |
| 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://tools.ietf.org/wg/httpbis/trac/report/11> and related |  | at <http://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://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix B.6. |  | The changes in this draft are summarized in Appendix C.7. |
| 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 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |
| 3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 |  | 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 |
| 3.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 8 |  | 1.2.2. ABNF Rules defined in other Parts of the |
| 4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 9 |  | Specification . . . . . . . . . . . . . . . . . . . . 7 |
| 5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 10 |  | 2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 |
| 5.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 12 |  | 2.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 8 |
| 6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 12 |  | 3. Request Header Fields . . . . . . . . . . . . . . . . . . . . 9 |
| 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 10 |
| 8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 13 |  | 4.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 12 |
| 8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 13 |  | 5. Response Header Fields . . . . . . . . . . . . . . . . . . . . 12 |
| 8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 13 |  | 6. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 14 |  | 7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 13 |
| 8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 13 |
| 8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 |  | 7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 13 |
| 8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 14 |
| 8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 7.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 |
| 8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 19 |  | 7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 19 |  | 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 19 |  | 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 20 |  | 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 19 |
| 9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 20 |  | 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 19 |
| 9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 20 |
| 9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 20 |  | 8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 20 |
| 9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 21 |  | 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 20 |
| 9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 21 |  | 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 21 |  | 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 21 |
| 9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 22 |  | 8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 21 |
| 9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 22 |  | 8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 21 |
| 9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 22 |  | 8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 22 |
| 9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 22 |  | 8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 22 |
| 9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 23 |  | 8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 22 |
| 9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 23 |  | 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 22 |
| 9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 24 |  | 8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 23 |
| 9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 25 |  | 8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 23 |
| 9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 25 |  | 8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 24 |
| 9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 25 |  | 8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 24 |
| 9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 25 |  | 8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 25 |
| 9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 25 |  | 8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 25 |
| 9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 26 |  | 8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 25 |
| 9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 26 |  | 8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 25 |
| 9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 26 |  | 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 26 |
| 9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 26 |  | 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 26 |
| 9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 26 |  | 8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 26 |
| 9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 27 |  | 8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 26 |
| 9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 27 |  | 8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 26 |
| 9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 27 |  | 8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 27 |
| 9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 27 |  | 8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 27 |
| 9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 27 |  | 8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 27 |
| 9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 27 |
| 9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 28 |  | 8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 28 |
| 9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 28 |  | 8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 28 |
| 9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 29 |  | 8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 28 |
| 9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 29 |  | 8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 29 |
| 9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 29 |  | 8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 29 |
| 9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 29 |  | 8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 29 |
| 9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 29 |  | 8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 29 |
| 9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 29 |  | 8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 29 |
| 9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 30 |  | 8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 29 |
| 9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 30 |  | 8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 30 |
| 9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 30 |  | 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 30 |
| 9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 30 |  | 8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 30 |
| 9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 30 |  | 8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 30 |
| 9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 31 |  | 8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 30 |
| 10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 31 |  | 8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 30 |
| 10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 31 |
| 10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 31 |
| 10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 31 |
| 10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 31 |
| 10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 34 |  | 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 34 |  | 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 35 |  | 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 35 |  | 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 34 |
| 10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 36 |  | 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 35 |
| 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 |  | 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 35 |
| 11.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 36 |  | 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 36 |
| 11.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 37 |  | 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 36 |
| 11.3. Message Header Registration . . . . . . . . . . . . . . . 39 |  | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 |
| 12. Security Considerations . . . . . . . . . . . . . . . . . . . 39 |  | 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 37 |
| 12.1. Transfer of Sensitive Information . . . . . . . . . . . . 39 |  | 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 37 |
| 12.2. Encoding Sensitive Information in URIs . . . . . . . . . . 40 |  | 10.3. Message Header Registration . . . . . . . . . . . . . . . 39 |
| 12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 41 |  | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 |
| 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 |  | 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 39 |
| 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |  | 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 40 |
| 14.1. Normative References . . . . . . . . . . . . . . . . . . . 41 |  | 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 41 |
| 14.2. Informative References . . . . . . . . . . . . . . . . . . 42 |  | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 |
|  |  | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |
|  |  | 13.1. Normative References . . . . . . . . . . . . . . . . . . . 41 |
|  |  | 13.2. Informative References . . . . . . . . . . . . . . . . . . 42 |
| Appendix A. Compatibility with Previous Versions . . . . . . . . 42 |  | Appendix A. Compatibility with Previous Versions . . . . . . . . 42 |
| A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 42 |  | A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 42 |
| A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 43 |  | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 43 |
| Appendix B. Change Log (to be removed by RFC Editor before |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 44 |
| publication) . . . . . . . . . . . . . . . . . . . . 44 |  | Appendix C. Change Log (to be removed by RFC Editor before |
| B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 44 |  | publication) . . . . . . . . . . . . . . . . . . . . 47 |
| B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 44 |  | C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 47 |
| B.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 45 |  | C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 47 |
| B.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 45 |  | C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 47 |
| B.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 46 |  | C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 48 |
| B.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 46 |  | C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 49 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 |  | C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 49 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 |  | C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 49 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 54 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 |
|  |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 |
| 1. Introduction |  | 1. Introduction |
| This document defines HTTP/1.1 request and response semantics. Each |  | This document defines HTTP/1.1 request and response semantics. Each |
| HTTP message, as defined in [Part1], is in the form of either a |  | HTTP message, as defined in [Part1], is in the form of either a |
| request or a response. An HTTP server listens on a connection for |  | request or a response. An HTTP server listens on a connection for |
| HTTP requests and responds to each request, in the order received on |  | HTTP requests and responds to each request, in the order received on |
| that connection, with one or more HTTP response messages. This |  | that connection, with one or more HTTP response messages. This |
| document defines the commonly agreed upon semantics of the HTTP |  | document defines the commonly agreed upon semantics of the HTTP |
| uniform interface, the intentions defined by each request method, and |  | uniform interface, the intentions defined by each request method, and |
| skipping to change at page 6, line 42 |  | skipping to change at page 6, line 42 |
| An implementation is not compliant if it fails to satisfy one or more |  | An implementation is not compliant if it fails to satisfy one or more |
| of the MUST or REQUIRED level requirements for the protocols it |  | of the MUST or REQUIRED level requirements for the protocols it |
| implements. An implementation that satisfies all the MUST or |  | implements. An implementation that satisfies all the MUST or |
| REQUIRED level and all the SHOULD level requirements for its |  | REQUIRED level and all the SHOULD level requirements for its |
| protocols is said to be "unconditionally compliant"; one that |  | protocols is said to be "unconditionally compliant"; one that |
| satisfies all the MUST level requirements but not all the SHOULD |  | satisfies all the MUST level requirements but not all the SHOULD |
| level requirements for its protocols is said to be "conditionally |  | level requirements for its protocols is said to be "conditionally |
| compliant." |  | compliant." |
| 2. Notational Conventions and Generic Grammar |  | 1.2. Syntax Notation |
| This specification uses the ABNF syntax defined in Section 2.1 of |  | This specification uses the ABNF syntax defined in Section 1.2 of |
| [Part1] and the core rules defined in Section 2.2 of [Part1]: |  | [Part1] (which extends the syntax defined in [RFC5234] with a list |
|  |  | rule). Appendix B shows the collected ABNF, with the list rule |
|  |  | expanded. |
| DIGIT = <DIGIT, defined in [Part1], Section 2.2> |  | The following core rules are included by reference, as defined in |
| comment = <comment, defined in [Part1], Section 2.2> |  | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |
| quoted-string = <quoted-string, defined in [Part1], Section 2.2> |  | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |
| token = <token, defined in [Part1], Section 2.2> |  | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |
| OWS = <OWS, defined in [Part1], Section 2.2> |  | sequence of data), SP (space), VCHAR (any visible USASCII character), |
| RWS = <RWS, defined in [Part1], Section 2.2> |  | and WSP (whitespace). |
|  |  | 1.2.1. Core Rules |
|  |  | The core rules below are defined in Section 1.2.2 of [Part1]: |
|  |  | comment = <comment, defined in [Part1], Section 1.2.2> |
|  |  | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |
|  |  | token = <token, defined in [Part1], Section 1.2.2> |
|  |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
|  |  | RWS = <RWS, defined in [Part1], Section 1.2.2> |
|  |  | obs-text = <obs-text, defined in [Part1], Section 1.2.2> |
|  |  | 1.2.2. ABNF Rules defined in other Parts of the Specification |
| The ABNF rules below are defined in other parts: |  | The ABNF rules below are defined in other parts: |
| absolute-URI = <absolute-URI, defined in [Part1], Section 3.2> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.1> |
| fragment = <fragment, defined in [Part1], Section 3.2> |  | fragment = <fragment, defined in [Part1], Section 2.1> |
| Host = <Host, defined in [Part1], Section 3.2> |  | Host = <Host, defined in [Part1], Section 2.1> |
| HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1> |  | HTTP-date = <HTTP-date, defined in [Part1], Section 3.2.1> |
| product = <product, defined in [Part1], Section 3.5> |  | partial-URI = <partial-URI, defined in [Part1], Section 2.1> |
| relativeURI = <relativeURI, defined in [Part1], Section 3.2> |  | product = <product, defined in [Part1], Section 3.4> |
| TE = <TE, defined in [Part1], Section 8.8> |  | TE = <TE, defined in [Part1], Section 8.8> |
| Accept = <Accept, defined in [Part3], Section 6.1> |  | Accept = <Accept, defined in [Part3], Section 5.1> |
| Accept-Charset = |  | Accept-Charset = |
| <Accept-Charset, defined in [Part3], Section 6.2> |  | <Accept-Charset, defined in [Part3], Section 5.2> |
| Accept-Encoding = |  | Accept-Encoding = |
| <Accept-Encoding, defined in [Part3], Section 6.3> |  | <Accept-Encoding, defined in [Part3], Section 5.3> |
| Accept-Language = |  | Accept-Language = |
| <Accept-Language, defined in [Part3], Section 6.4> |  | <Accept-Language, defined in [Part3], Section 5.4> |
| ETag = <ETag, defined in [Part4], Section 7.1> |  | ETag = <ETag, defined in [Part4], Section 6.1> |
| If-Match = <If-Match, defined in [Part4], Section 7.2> |  | If-Match = <If-Match, defined in [Part4], Section 6.2> |
| If-Modified-Since = |  | If-Modified-Since = |
| <If-Modified-Since, defined in [Part4], Section 7.3> |  | <If-Modified-Since, defined in [Part4], Section 6.3> |
| If-None-Match = <If-None-Match, defined in [Part4], Section 7.4> |  | If-None-Match = <If-None-Match, defined in [Part4], Section 6.4> |
| If-Unmodified-Since = |  | If-Unmodified-Since = |
| <If-Unmodified-Since, defined in [Part4], Section 7.5> |  | <If-Unmodified-Since, defined in [Part4], Section 6.5> |
| Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 6.1> |  | Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 5.1> |
| If-Range = <If-Range, defined in [Part5], Section 6.3> |  | If-Range = <If-Range, defined in [Part5], Section 5.3> |
| Range = <Range, defined in [Part5], Section 6.4> |  | Range = <Range, defined in [Part5], Section 5.4> |
|  |  | Age = <Age, defined in [Part6], Section 3.1> |
|  |  | Vary = <Vary, defined in [Part6], Section 3.5> |
| Age = <Age, defined in [Part6], Section 16.1> |  | Authorization = <Authorization, defined in [Part7], Section 3.1> |
| Vary = <Vary, defined in [Part6], Section 16.5> |  |  |
| Authorization = <Authorization, defined in [Part7], Section 4.1> |  |  |
| Proxy-Authenticate = |  | Proxy-Authenticate = |
| <Proxy-Authenticate, defined in [Part7], Section 4.2> |  | <Proxy-Authenticate, defined in [Part7], Section 3.2> |
| Proxy-Authorization = |  | Proxy-Authorization = |
| <Proxy-Authorization, defined in [Part7], Section 4.3> |  | <Proxy-Authorization, defined in [Part7], Section 3.3> |
| WWW-Authenticate = |  | WWW-Authenticate = |
| <WWW-Authenticate, defined in [Part7], Section 4.4> |  | <WWW-Authenticate, defined in [Part7], Section 3.4> |
| 3. Method |  | 2. 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-target. The method is case-sensitive. |
| Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 8.2 |  | Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 7.2 |
| / %x47.45.54 ; "GET", Section 8.3 |  | / %x47.45.54 ; "GET", Section 7.3 |
| / %x48.45.41.44 ; "HEAD", Section 8.4 |  | / %x48.45.41.44 ; "HEAD", Section 7.4 |
| / %x50.4F.53.54 ; "POST", Section 8.5 |  | / %x50.4F.53.54 ; "POST", Section 7.5 |
| / %x50.55.54 ; "PUT", Section 8.6 |  | / %x50.55.54 ; "PUT", Section 7.6 |
| / %x44.45.4C.45.54.45 ; "DELETE", Section 8.7 |  | / %x44.45.4C.45.54.45 ; "DELETE", Section 7.7 |
| / %x54.52.41.43.45 ; "TRACE", Section 8.8 |  | / %x54.52.41.43.45 ; "TRACE", Section 7.8 |
| / %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 8.9 |  | / %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 7.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 9.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 |
| is unrecognized or not implemented by the origin server. The methods |  | is unrecognized or not implemented by the origin server. The methods |
| GET and HEAD MUST be supported by all general-purpose servers. All |  | GET and HEAD MUST be supported by all general-purpose servers. All |
| other methods are OPTIONAL; however, if the above methods are |  | other methods are OPTIONAL; however, if the above methods are |
| implemented, they MUST be implemented with the same semantics as |  | implemented, they MUST be implemented with the same semantics as |
| those specified in Section 8. |  | those specified in Section 7. |
| 3.1. Method Registry |  | 2.1. Method Registry |
| The HTTP Method Registry defines the name space for the Method token |  | The HTTP Method Registry defines the name space for the Method token |
| in the Request line of an HTTP request. |  | in the Request line of an HTTP request. |
| Registrations MUST include the following fields: |  | Registrations MUST include the following fields: |
| o Method Name (see Section 3) |  | o Method Name (see Section 2) |
| o Safe ("yes" or "no", see Section 8.1.1) |  |  |
|  |  | o Safe ("yes" or "no", see Section 7.1.1) |
| o Pointer to specification text |  | o Pointer to specification text |
| Values to be added to this name space are subject to IETF review |  | Values to be added to this name space are subject to IETF review |
| ([RFC5226], Section 4.1). Any document registering new method names |  | ([RFC5226], Section 4.1). Any document registering new method names |
| should be traceable through statuses of either 'Obsoletes' or |  | should be traceable through statuses of either 'Obsoletes' or |
| 'Updates' to this document. |  | 'Updates' to this document. |
| The registry itself is maintained at |  | The registry itself is maintained at |
| <http://www.iana.org/assignments/http-methods>. |  | <http://www.iana.org/assignments/http-methods>. |
| 4. Request Header Fields |  | 3. Request Header Fields |
| The request-header fields allow the client to pass additional |  | The request-header fields allow the client to pass additional |
| information about the request, and about the client itself, to the |  | information about the request, and about the client itself, to the |
| server. These fields act as request modifiers, with semantics |  | server. These fields act as request modifiers, with semantics |
| equivalent to the parameters on a programming language method |  | equivalent to the parameters on a programming language method |
| invocation. |  | invocation. |
| request-header = Accept ; [Part3], Section 6.1 |  | request-header = Accept ; [Part3], Section 5.1 |
| / Accept-Charset ; [Part3], Section 6.2 |  | / Accept-Charset ; [Part3], Section 5.2 |
| / Accept-Encoding ; [Part3], Section 6.3 |  | / Accept-Encoding ; [Part3], Section 5.3 |
| / Accept-Language ; [Part3], Section 6.4 |  | / Accept-Language ; [Part3], Section 5.4 |
| / Authorization ; [Part7], Section 4.1 |  | / Authorization ; [Part7], Section 3.1 |
| / Expect ; Section 10.2 |  | / Expect ; Section 9.2 |
| / From ; Section 10.3 |  | / From ; Section 9.3 |
| / Host ; [Part1], Section 8.4 |  | / Host ; [Part1], Section 8.4 |
| / If-Match ; [Part4], Section 7.2 |  | / If-Match ; [Part4], Section 6.2 |
| / If-Modified-Since ; [Part4], Section 7.3 |  | / If-Modified-Since ; [Part4], Section 6.3 |
| / If-None-Match ; [Part4], Section 7.4 |  | / If-None-Match ; [Part4], Section 6.4 |
| / If-Range ; [Part5], Section 6.3 |  | / If-Range ; [Part5], Section 5.3 |
| / If-Unmodified-Since ; [Part4], Section 7.5 |  | / If-Unmodified-Since ; [Part4], Section 6.5 |
| / Max-Forwards ; Section 10.5 |  | / Max-Forwards ; Section 9.5 |
| / Proxy-Authorization ; [Part7], Section 4.3 |  | / Proxy-Authorization ; [Part7], Section 3.3 |
| / Range ; [Part5], Section 6.4 |  | / Range ; [Part5], Section 5.4 |
| / Referer ; Section 10.6 |  | / Referer ; Section 9.6 |
| / TE ; [Part1], Section 8.8 |  | / TE ; [Part1], Section 8.8 |
| / User-Agent ; Section 10.9 |  | / User-Agent ; Section 9.9 |
| Request-header field names can be extended reliably only in |  | Request-header field names can be extended reliably only in |
| combination with a change in the protocol version. However, new or |  | combination with a change in the protocol version. However, new or |
| experimental header fields MAY be given the semantics of request- |  | experimental header fields MAY be given the semantics of request- |
| header fields if all parties in the communication recognize them to |  | header fields if all parties in the communication recognize them to |
| be request-header fields. Unrecognized header fields are treated as |  | be request-header fields. Unrecognized header fields are treated as |
| entity-header fields. |  | entity-header fields. |
| 5. Status Code and Reason Phrase |  | 4. 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. The status codes |  | attempt to understand and satisfy the request. The status codes |
| listed below are defined in Section 9. The Reason-Phrase is intended |  | listed below are defined in Section 8. The Reason-Phrase is intended |
| to give a short textual description of the Status-Code. The Status- |  | to give a short textual description of the Status-Code. The Status- |
| Code is intended for use by automata and the Reason-Phrase is |  | Code is intended for use by automata and the Reason-Phrase is |
| intended for the human user. The client is not required to examine |  | intended for the human user. The client is not required to examine |
| or display the Reason-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 8.1.1: Continue |
| / "101" ; Section 9.1.2: Switching Protocols |  | / "101" ; Section 8.1.2: Switching Protocols |
| / "200" ; Section 9.2.1: OK |  | / "200" ; Section 8.2.1: OK |
| / "201" ; Section 9.2.2: Created |  | / "201" ; Section 8.2.2: Created |
| / "202" ; Section 9.2.3: Accepted |  | / "202" ; Section 8.2.3: Accepted |
| / "203" ; Section 9.2.4: Non-Authoritative Information |  | / "203" ; Section 8.2.4: Non-Authoritative Information |
| / "204" ; Section 9.2.5: No Content |  | / "204" ; Section 8.2.5: No Content |
| / "205" ; Section 9.2.6: Reset Content |  | / "205" ; Section 8.2.6: Reset Content |
| / "206" ; Section 9.2.7: Partial Content |  | / "206" ; Section 8.2.7: Partial Content |
| / "300" ; Section 9.3.1: Multiple Choices |  | / "300" ; Section 8.3.1: Multiple Choices |
| / "301" ; Section 9.3.2: Moved Permanently |  | / "301" ; Section 8.3.2: Moved Permanently |
| / "302" ; Section 9.3.3: Found |  | / "302" ; Section 8.3.3: Found |
| / "303" ; Section 9.3.4: See Other |  | / "303" ; Section 8.3.4: See Other |
| / "304" ; Section 9.3.5: Not Modified |  | / "304" ; Section 8.3.5: Not Modified |
| / "305" ; Section 9.3.6: Use Proxy |  | / "305" ; Section 8.3.6: Use Proxy |
| / "307" ; Section 9.3.8: Temporary Redirect |  | / "307" ; Section 8.3.8: Temporary Redirect |
| / "400" ; Section 9.4.1: Bad Request |  | / "400" ; Section 8.4.1: Bad Request |
| / "401" ; Section 9.4.2: Unauthorized |  | / "401" ; Section 8.4.2: Unauthorized |
| / "402" ; Section 9.4.3: Payment Required |  | / "402" ; Section 8.4.3: Payment Required |
| / "403" ; Section 9.4.4: Forbidden |  | / "403" ; Section 8.4.4: Forbidden |
| / "404" ; Section 9.4.5: Not Found |  | / "404" ; Section 8.4.5: Not Found |
| / "405" ; Section 9.4.6: Method Not Allowed |  | / "405" ; Section 8.4.6: Method Not Allowed |
| / "406" ; Section 9.4.7: Not Acceptable |  | / "406" ; Section 8.4.7: Not Acceptable |
| / "407" ; Section 9.4.8: Proxy Authentication Required |  | / "407" ; Section 8.4.8: Proxy Authentication Required |
| / "408" ; Section 9.4.9: Request Time-out |  | / "408" ; Section 8.4.9: Request Time-out |
| / "409" ; Section 9.4.10: Conflict |  | / "409" ; Section 8.4.10: Conflict |
| / "410" ; Section 9.4.11: Gone |  | / "410" ; Section 8.4.11: Gone |
| / "411" ; Section 9.4.12: Length Required |  | / "411" ; Section 8.4.12: Length Required |
| / "412" ; Section 9.4.13: Precondition Failed |  | / "412" ; Section 8.4.13: Precondition Failed |
| / "413" ; Section 9.4.14: Request Entity Too Large |  | / "413" ; Section 8.4.14: Request Entity Too Large |
| / "414" ; Section 9.4.15: Request-URI Too Large |  | / "414" ; Section 8.4.15: URI Too Long |
| / "415" ; Section 9.4.16: Unsupported Media Type |  | / "415" ; Section 8.4.16: Unsupported Media Type |
| / "416" ; Section 9.4.17: Requested range not satisfiable |  | / "416" ; Section 8.4.17: Requested range not satisfiable |
| / "417" ; Section 9.4.18: Expectation Failed |  | / "417" ; Section 8.4.18: Expectation Failed |
| / "500" ; Section 9.5.1: Internal Server Error |  | / "500" ; Section 8.5.1: Internal Server Error |
| / "501" ; Section 9.5.2: Not Implemented |  | / "501" ; Section 8.5.2: Not Implemented |
| / "502" ; Section 9.5.3: Bad Gateway |  | / "502" ; Section 8.5.3: Bad Gateway |
| / "503" ; Section 9.5.4: Service Unavailable |  | / "503" ; Section 8.5.4: Service Unavailable |
| / "504" ; Section 9.5.5: Gateway Time-out |  | / "504" ; Section 8.5.5: Gateway Time-out |
| / "505" ; Section 9.5.6: HTTP Version not supported |  | / "505" ; Section 8.5.6: HTTP Version not supported |
| / extension-code |  | / extension-code |
| extension-code = 3DIGIT |  | extension-code = 3DIGIT |
| Reason-Phrase = *<TEXT, excluding CR, LF> |  | Reason-Phrase = *( WSP / VCHAR / obs-text ) |
| HTTP status codes are extensible. HTTP applications are not required |  | HTTP status codes are extensible. HTTP applications are not required |
| to understand the meaning of all registered status codes, though such |  | to understand the meaning of all registered status codes, though such |
| understanding is obviously desirable. However, applications MUST |  | understanding is obviously desirable. However, applications MUST |
| understand the class of any status code, as indicated by the first |  | understand the class of any status code, as indicated by the first |
| digit, and treat 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 |  | 4.1. Status Code Registry |
| The HTTP Status Code Registry defines the name space for the Status- |  | The HTTP Status Code Registry defines the name space for the Status- |
| Code token in the Status line of an HTTP response. |  | Code token in the Status line of an HTTP response. |
| Values to be added to this name space are subject to IETF review |  | Values to be added to this name space are subject to IETF review |
| ([RFC5226], Section 4.1). Any document registering new status codes |  | ([RFC5226], Section 4.1). Any document registering new status codes |
| should be traceable through statuses of either 'Obsoletes' or |  | should be traceable through statuses of either 'Obsoletes' or |
| 'Updates' to this document. |  | 'Updates' to this document. |
| The registry itself is maintained at |  | The registry itself is maintained at |
| <http://www.iana.org/assignments/http-status-codes>. |  | <http://www.iana.org/assignments/http-status-codes>. |
| 6. Response Header Fields |  | 5. 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- |
|  |  | target. |
| response-header = Accept-Ranges ; [Part5], Section 6.1 |  | response-header = Accept-Ranges ; [Part5], Section 5.1 |
| / Age ; [Part6], Section 16.1 |  | / Age ; [Part6], Section 3.1 |
| / Allow ; Section 10.1 |  | / Allow ; Section 9.1 |
| / ETag ; [Part4], Section 7.1 |  | / ETag ; [Part4], Section 6.1 |
| / Location ; Section 10.4 |  | / Location ; Section 9.4 |
| / Proxy-Authenticate ; [Part7], Section 4.2 |  | / Proxy-Authenticate ; [Part7], Section 3.2 |
| / Retry-After ; Section 10.7 |  | / Retry-After ; Section 9.7 |
| / Server ; Section 10.8 |  | / Server ; Section 9.8 |
| / Vary ; [Part6], Section 16.5 |  | / Vary ; [Part6], Section 3.5 |
| / WWW-Authenticate ; [Part7], Section 4.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 |  | 6. Entity |
| Request and Response messages MAY transfer an entity if not otherwise |  | Request and Response messages MAY transfer an entity if not otherwise |
| restricted by the request method or response status code. An entity |  | restricted by the request method or response status code. An entity |
| consists of entity-header fields and an entity-body, although some |  | consists of entity-header fields and an entity-body, although some |
| responses will only include the entity-headers. HTTP entity-body and |  | responses will only include the entity-headers. HTTP entity-body and |
| entity-header fields are defined in [Part3]. |  | entity-header fields are defined in [Part3]. |
| An entity-body is only present in a message when a message-body is |  | An entity-body is only present in a message when a message-body is |
| present, as described in Section 4.3 of [Part1]. The entity-body is |  | present, as described in Section 4.3 of [Part1]. The entity-body is |
| obtained from the message-body by decoding any Transfer-Encoding that |  | obtained from the message-body by decoding any Transfer-Encoding that |
| might have been applied to ensure safe and proper transfer of the |  | might have been applied to ensure safe and proper transfer of the |
| message. |  | message. |
| 8. Method Definitions |  | 7. Method Definitions |
| The set of common methods for HTTP/1.1 is defined below. Although |  | The set of common methods for HTTP/1.1 is defined below. Although |
| this set can be expanded, additional methods cannot be assumed to |  | this set can be expanded, additional methods cannot be assumed to |
| share the same semantics for separately extended clients and servers. |  | share the same semantics for separately extended clients and servers. |
| 8.1. Safe and Idempotent Methods |  | 7.1. Safe and Idempotent Methods |
| 8.1.1. Safe Methods |  | 7.1.1. Safe Methods |
| Implementors should be aware that the software represents the user in |  | Implementors should be aware that the software represents the user in |
| their interactions over the Internet, and should be careful to allow |  | their interactions over the Internet, and should be careful to allow |
| the user to be aware of any actions they might take which may have an |  | the user to be aware of any actions they might take which may have an |
| unexpected significance to themselves or others. |  | unexpected significance to themselves or others. |
| In particular, the convention has been established that the GET and |  | In particular, the convention has been established that the GET and |
| HEAD methods SHOULD NOT have the significance of taking an action |  | HEAD methods SHOULD NOT have the significance of taking an action |
| other than retrieval. These methods ought to be considered "safe". |  | other than retrieval. These methods ought to be considered "safe". |
| This allows user agents to represent other methods, such as POST, PUT |  | This allows user agents to represent other methods, such as POST, PUT |
| and DELETE, in a special way, so that the user is made aware of the |  | and DELETE, in a special way, so that the user is made aware of the |
| fact that a possibly unsafe action is being requested. |  | fact that a possibly unsafe action is being requested. |
| Naturally, it is not possible to ensure that the server does not |  | Naturally, it is not possible to ensure that the server does not |
| generate side-effects as a result of performing a GET request; in |  | generate side-effects as a result of performing a GET request; in |
| fact, some dynamic resources consider that a feature. The important |  | fact, some dynamic resources consider that a feature. The important |
| distinction here is that the user did not request the side-effects, |  | distinction here is that the user did not request the side-effects, |
| so therefore cannot be held accountable for them. |  | so therefore cannot be held accountable for them. |
| 8.1.2. Idempotent Methods |  | 7.1.2. Idempotent Methods |
| Methods can also have the property of "idempotence" in that (aside |  | Methods can also have the property of "idempotence" in that (aside |
| from error or expiration issues) the side-effects of N > 0 identical |  | from error or expiration issues) the side-effects of N > 0 identical |
| requests is the same as for a single request. The methods GET, HEAD, |  | requests is the same as for a single request. The methods GET, HEAD, |
| PUT and DELETE share this property. Also, the methods OPTIONS and |  | PUT and DELETE share this property. Also, the methods OPTIONS and |
| TRACE SHOULD NOT have side effects, and so are inherently idempotent. |  | TRACE SHOULD NOT have side effects, and so are inherently idempotent. |
| However, it is possible that a sequence of several requests is non- |  | However, it is possible that a sequence of several requests is non- |
| idempotent, even if all of the methods executed in that sequence are |  | idempotent, even if all of the methods executed in that sequence are |
| idempotent. (A sequence is idempotent if a single execution of the |  | idempotent. (A sequence is idempotent if a single execution of the |
| entire sequence always yields a result that is not changed by a |  | entire sequence always yields a result that is not changed by a |
| reexecution of all, or part, of that sequence.) For example, a |  | reexecution of all, or part, of that sequence.) For example, a |
| sequence is non-idempotent if its result depends on a value that is |  | sequence is non-idempotent if its result depends on a value that is |
| later modified in the same sequence. |  | later modified in the same sequence. |
| A sequence that never has side effects is idempotent, by definition |  | A sequence that never has side effects is idempotent, by definition |
| (provided that no concurrent operations are being executed on the |  | (provided that no concurrent operations are being executed on the |
| same set of resources). |  | same set of resources). |
| 8.2. OPTIONS |  | 7.2. OPTIONS |
| The OPTIONS method represents a request for information about the |  | The OPTIONS method represents a request for information about the |
| communication options available on the request/response chain |  | communication options available on the request/response chain |
| identified by the Request-URI. This method allows the client to |  | identified by the request-target. This method allows the client to |
| determine the options and/or requirements associated with a resource, |  | determine the options and/or requirements associated with a resource, |
| or the capabilities of a server, without implying a resource action |  | or the capabilities of a server, without implying a resource action |
| or initiating a resource retrieval. |  | or initiating a resource retrieval. |
| Responses to this method are not cacheable. |  | Responses to this method are not cacheable. |
| If the OPTIONS request includes an entity-body (as indicated by the |  | If the OPTIONS request includes an entity-body (as indicated by the |
| presence of Content-Length or Transfer-Encoding), then the media type |  | presence of Content-Length or Transfer-Encoding), then the media type |
| MUST be indicated by a Content-Type field. Although this |  | MUST be indicated by a Content-Type field. Although this |
| specification does not define any use for such a body, future |  | specification does not define any use for such a body, future |
| extensions to HTTP might use the OPTIONS body to make more detailed |  | extensions to HTTP might use the OPTIONS body to make more detailed |
| queries on the server. |  | queries on the server. |
| If the Request-URI is an asterisk ("*"), the OPTIONS request is |  | If the request-target is an asterisk ("*"), the OPTIONS request is |
| intended to apply to the server in general rather than to a specific |  | intended to apply to the server in general rather than to a specific |
| resource. Since a server's communication options typically depend on |  | resource. Since a server's communication options typically depend on |
| the resource, the "*" request is only useful as a "ping" or "no-op" |  | the resource, the "*" request is only useful as a "ping" or "no-op" |
| type of method; it does nothing beyond allowing the client to test |  | type of method; it does nothing beyond allowing the client to test |
| the capabilities of the server. For example, this can be used to |  | the capabilities of the server. For example, this can be used to |
| test a proxy for HTTP/1.1 compliance (or lack thereof). |  | test a proxy for HTTP/1.1 compliance (or lack thereof). |
| If the Request-URI is not an asterisk, the OPTIONS request applies |  | If the request-target is not an asterisk, the OPTIONS request applies |
| only to the options that are available when communicating with that |  | only to the options that are available when communicating with that |
| resource. |  | resource. |
| A 200 response SHOULD include any header fields that indicate |  | A 200 response SHOULD include any header fields that indicate |
| optional features implemented by the server and applicable to that |  | optional features implemented by the server and applicable to that |
| resource (e.g., Allow), possibly including extensions not defined by |  | resource (e.g., Allow), possibly including extensions not defined by |
| this specification. The response body, if any, SHOULD also include |  | this specification. The response body, if any, SHOULD also include |
| information about the communication options. The format for such a |  | information about the communication options. The format for such a |
| body is not defined by this specification, but might be defined by |  | body is not defined by this specification, but might be defined by |
| future extensions to HTTP. Content negotiation MAY be used to select |  | future extensions to HTTP. Content negotiation MAY be used to select |
| skipping to change at page 15, line 29 |  | skipping to change at page 15, line 29 |
| OPTIONS request on an absolute-URI for which request forwarding is |  | OPTIONS request on an absolute-URI for which request forwarding is |
| permitted, the proxy MUST check for a Max-Forwards field. If the |  | permitted, the proxy MUST check for a Max-Forwards field. If the |
| Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward |  | Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward |
| the message; instead, the proxy SHOULD respond with its own |  | the message; instead, the proxy SHOULD respond with its own |
| communication options. If the Max-Forwards field-value is an integer |  | communication options. If the Max-Forwards field-value is an integer |
| greater than zero, the proxy MUST decrement the field-value when it |  | greater than zero, the proxy MUST decrement the field-value when it |
| forwards the request. If no Max-Forwards field is present in the |  | forwards the request. If no Max-Forwards field is present in the |
| request, then the forwarded request MUST NOT include a Max-Forwards |  | request, then the forwarded request MUST NOT include a Max-Forwards |
| field. |  | field. |
| 8.3. GET |  | 7.3. GET |
| The GET method means retrieve whatever information (in the form of an |  | The GET method means retrieve whatever information (in the form of an |
| entity) is identified by the Request-URI. If the Request-URI refers |  | entity) is identified by the request-target. If the request-target |
| to a data-producing process, it is the produced data which shall be |  | refers to a data-producing process, it is the produced data which |
| returned as the entity in the response and not the source text of the |  | shall be returned as the entity in the response and not the source |
| process, unless that text happens to be the output of the process. |  | text of the process, unless that text happens to be the output of the |
|  |  | process. |
| The semantics of the GET method change to a "conditional GET" if the |  | The semantics of the GET method change to a "conditional GET" if the |
| request message includes an If-Modified-Since, If-Unmodified-Since, |  | request message includes an If-Modified-Since, If-Unmodified-Since, |
| If-Match, If-None-Match, or If-Range header field. A conditional GET |  | If-Match, If-None-Match, or If-Range header field. A conditional GET |
| method requests that the entity be transferred only under the |  | method requests that the entity be transferred only under the |
| circumstances described by the conditional header field(s). The |  | circumstances described by the conditional header field(s). The |
| conditional GET method is intended to reduce unnecessary network |  | conditional GET method is intended to reduce unnecessary network |
| usage by allowing cached entities to be refreshed without requiring |  | usage by allowing cached entities to be refreshed without requiring |
| multiple requests or transferring data already held by the client. |  | multiple requests or transferring data already held by the client. |
| The semantics of the GET method change to a "partial GET" if the |  | The semantics of the GET method change to a "partial GET" if the |
| request message includes a Range header field. A partial GET |  | request message includes a Range header field. A partial GET |
| requests that only part of the entity be transferred, as described in |  | requests that only part of the entity be transferred, as described in |
| Section 6.4 of [Part5]. The partial GET method is intended to reduce |  | Section 5.4 of [Part5]. The partial GET method is intended to reduce |
| unnecessary network usage by allowing partially-retrieved entities to |  | unnecessary network usage by allowing partially-retrieved entities to |
| be completed without transferring data already held by the client. |  | be completed without transferring data already held by the client. |
| The response to a GET request is cacheable if and only if it meets |  | The response to a GET request is cacheable if and only if it meets |
| the requirements for HTTP caching described in [Part6]. |  | the requirements for HTTP caching described in [Part6]. |
| See Section 12.2 for security considerations when used for forms. |  | See Section 11.2 for security considerations when used for forms. |
| 8.4. HEAD |  | 7.4. HEAD |
| The HEAD method is identical to GET except that the server MUST NOT |  | The HEAD method is identical to GET except that the server MUST NOT |
| return a message-body in the response. The metainformation contained |  | return a message-body in the response. The metainformation contained |
| in the HTTP headers in response to a HEAD request SHOULD be identical |  | in the HTTP headers in response to a HEAD request SHOULD be identical |
| to the information sent in response to a GET request. This method |  | to the information sent in response to a GET request. This method |
| can be used for obtaining metainformation about the entity implied by |  | can be used for obtaining metainformation about the entity implied by |
| the request without transferring the entity-body itself. This method |  | the request without transferring the entity-body itself. This method |
| is often used for testing hypertext links for validity, |  | is often used for testing hypertext links for validity, |
| accessibility, and recent modification. |  | accessibility, and recent modification. |
| The response to a HEAD request MAY be cacheable in the sense that the |  | The response to a HEAD request MAY be cacheable in the sense that the |
| 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 |  | 7.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 data to be processed by the |  | entity enclosed in the request as data to be processed by the |
| resource identified by the Request-URI in the Request-Line. POST is |  | resource identified by the request-target in the Request-Line. POST |
| designed to allow a uniform method to cover the following functions: |  | is 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. |  | server and is usually dependent on the request-target. |
| 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 9.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 |  | 7.6. PUT |
| The PUT method requests that the enclosed entity be stored at 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-target. If the request-target 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-target does not point to an existing resource, and that URI |
| capable of being defined as a new resource by the requesting user |  | is 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-target, 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 |
| the request. If the resource could not be created or modified with |  | the request. If the resource could not be created or modified with |
| the Request-URI, an appropriate error response SHOULD be given that |  | the request-target, an appropriate error response SHOULD be given |
| reflects the nature of the problem. The recipient of the entity MUST |  | that reflects the nature of the problem. The recipient of the entity |
| NOT ignore any Content-* headers (headers starting with the prefix |  | MUST NOT ignore any Content-* headers (headers starting with the |
| 'Content-') that it does not understand or implement and MUST return |  | prefix 'Content-') that it does not understand or implement and MUST |
| a 501 (Not Implemented) response in such cases. |  | return a 501 (Not Implemented) response in such cases. |
| If the request passes through a cache and the Request-URI identifies |  | If the request passes through a cache and the request-target |
| one or more currently cached entities, those entries SHOULD be |  | identifies one or more currently cached entities, those entries |
| treated as stale. Responses to this method are not cacheable. |  | SHOULD be treated as stale. Responses to this method are not |
|  |  | cacheable. |
| The fundamental difference between the POST and PUT requests is |  | The fundamental difference between the POST and PUT requests is |
| reflected in the different meaning of the Request-URI. The URI in a |  | reflected in the different meaning of the request-target. The URI in |
| POST request identifies the resource that will handle the enclosed |  | a POST request identifies the resource that will handle the enclosed |
| entity. That resource might be a data-accepting process, a gateway |  | entity. That resource might be a data-accepting process, a gateway |
| to some other protocol, or a separate entity that accepts |  | to some other protocol, or a separate entity that accepts |
| annotations. In contrast, the URI in a PUT request identifies the |  | annotations. In contrast, the URI in a PUT request identifies the |
| entity enclosed with the request -- the user agent knows what URI is |  | entity enclosed with the request -- the user agent knows what URI is |
| intended and the server MUST NOT attempt to apply the request to some |  | intended and the server MUST NOT attempt to apply the request to some |
| other resource. If the server desires that the request be applied to |  | other resource. If the server desires that the request be applied to |
| a different URI, it MUST send a 301 (Moved Permanently) response; the |  | a different URI, it MUST send a 301 (Moved Permanently) response; the |
| user agent MAY then make its own decision regarding whether or not to |  | user agent MAY then make its own decision regarding whether or not to |
| redirect the request. |  | redirect the request. |
| skipping to change at page 18, line 18 |  | skipping to change at page 18, line 22 |
| 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. |
| 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 |  | 7.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-target. 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 |
| the status code returned from the origin server indicates that the |  | the status code returned from the origin server indicates that the |
| action has been completed successfully. However, the server SHOULD |  | action has been completed successfully. However, the server SHOULD |
| NOT indicate success unless, at the time the response is given, it |  | NOT indicate success unless, at the time the response is given, it |
| intends to delete the resource or move it to an inaccessible |  | intends to delete the resource or move it to an inaccessible |
| location. |  | location. |
| A successful response SHOULD be 200 (OK) if the response includes an |  | A successful response SHOULD be 200 (OK) if the response includes an |
| entity describing the status, 202 (Accepted) if the action has not |  | entity describing the status, 202 (Accepted) if the action has not |
| yet been enacted, or 204 (No Content) if the action has been enacted |  | yet been enacted, or 204 (No Content) if the action has been enacted |
| but the response does not include an entity. |  | but the response does not include an entity. |
| If the request passes through a cache and the Request-URI identifies |  | If the request passes through a cache and the request-target |
| one or more currently cached entities, those entries SHOULD be |  | identifies one or more currently cached entities, those entries |
| treated as stale. Responses to this method are not cacheable. |  | SHOULD be treated as stale. Responses to this method are not |
|  |  | cacheable. |
| 8.8. TRACE |  | 7.8. TRACE |
| The TRACE method is used to invoke a remote, application-layer loop- |  | The TRACE method is used to invoke a remote, application-layer loop- |
| back of the request message. The final recipient of the request |  | back of the request message. The final recipient of the request |
| SHOULD reflect the message received back to the client as the entity- |  | SHOULD reflect the message received back to the client as the entity- |
| body of a 200 (OK) response. The final recipient is either the |  | body of a 200 (OK) response. The final recipient is either the |
| origin server or the first proxy or gateway to receive a Max-Forwards |  | origin server or the first proxy or gateway to receive a Max-Forwards |
| value of zero (0) in the request (see Section 10.5). A TRACE request |  | value of zero (0) in the request (see Section 9.5). A TRACE request |
| MUST NOT include an entity. |  | MUST NOT include an entity. |
| 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" (see Section 9.3.1 of [Part1]). Responses to this method MUST |  | http" (see Section 9.3.1 of [Part1]). Responses to this method MUST |
| NOT be cached. |  | NOT be cached. |
| 8.9. CONNECT |  | 7.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 [RFC2817]). |  | tunneling [RFC2817]). |
| 9. Status Code Definitions |  | 8. 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 |
| method(s) it can follow and any metainformation required in the |  | method(s) it can follow and any metainformation required in the |
| response. |  | response. |
| 9.1. Informational 1xx |  | 8.1. Informational 1xx |
| This class of status code indicates a provisional response, |  | This class of status code indicates a provisional response, |
| consisting only of the Status-Line and optional headers, and is |  | consisting only of the Status-Line and optional headers, and is |
| terminated by an empty line. There are no required headers for this |  | terminated by an empty line. There are no required headers for this |
| class of status code. Since HTTP/1.0 did not define any 1xx status |  | class of status code. Since HTTP/1.0 did not define any 1xx status |
| codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client |  | codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client |
| except under experimental conditions. |  | except under experimental conditions. |
| A client MUST be prepared to accept one or more 1xx status responses |  | A client MUST be prepared to accept one or more 1xx status responses |
| prior to a regular response, even if the client does not expect a 100 |  | prior to a regular response, even if the client does not expect a 100 |
| (Continue) status message. Unexpected 1xx status responses MAY be |  | (Continue) status message. Unexpected 1xx status responses MAY be |
| ignored by a user agent. |  | ignored by a user agent. |
| Proxies MUST forward 1xx responses, unless the connection between the |  | Proxies MUST forward 1xx responses, unless the connection between the |
| proxy and its client has been closed, or unless the proxy itself |  | proxy and its client has been closed, or unless the proxy itself |
| requested the generation of the 1xx response. (For example, if a |  | requested the generation of the 1xx response. (For example, if a |
| proxy adds a "Expect: 100-continue" field when it forwards a request, |  | proxy adds a "Expect: 100-continue" field when it forwards a request, |
| then it need not forward the corresponding 100 (Continue) |  | then it need not forward the corresponding 100 (Continue) |
| response(s).) |  | response(s).) |
| 9.1.1. 100 Continue |  | 8.1.1. 100 Continue |
| The client SHOULD continue with its request. This interim response |  | The client SHOULD continue with its request. This interim response |
| is used to inform the client that the initial part of the request has |  | is used to inform the client that the initial part of the request has |
| been received and has not yet been rejected by the server. The |  | been received and has not yet been rejected by the server. The |
| client SHOULD continue by sending the remainder of the request or, if |  | client SHOULD continue by sending the remainder of the request or, if |
| the request has already been completed, ignore this response. The |  | the request has already been completed, ignore this response. The |
| server MUST send a final response after the request has been |  | server MUST send a final response after the request has been |
| completed. See Section 7.2.3 of [Part1] for detailed discussion of |  | completed. See Section 7.2.3 of [Part1] for detailed discussion of |
| the use and handling of this status code. |  | the use and handling of this status code. |
| 9.1.2. 101 Switching Protocols |  | 8.1.2. 101 Switching Protocols |
| The server understands and is willing to comply with the client's |  | The server understands and is willing to comply with the client's |
| request, via the Upgrade message header field (Section 6.4 of |  | request, via the Upgrade message header field (Section 5.4 of |
| [Part5]), for a change in the application protocol being used on this |  | [Part5]), for a change in the application protocol being used on this |
| connection. The server will switch protocols to those defined by the |  | connection. The server will switch protocols to those defined by the |
| response's Upgrade header field immediately after the empty line |  | response's Upgrade header field immediately after the empty line |
| which terminates the 101 response. |  | which terminates the 101 response. |
| The protocol SHOULD be switched only when it is advantageous to do |  | The protocol SHOULD be switched only when it is advantageous to do |
| so. For example, switching to a newer version of HTTP is |  | so. For example, switching to a newer version of HTTP is |
| advantageous over older versions, and switching to a real-time, |  | advantageous over older versions, and switching to a real-time, |
| synchronous protocol might be advantageous when delivering resources |  | synchronous protocol might be advantageous when delivering resources |
| that use such features. |  | that use such features. |
| 9.2. Successful 2xx |  | 8.2. Successful 2xx |
| This class of status code indicates that the client's request was |  | This class of status code indicates that the client's request was |
| successfully received, understood, and accepted. |  | successfully received, understood, and accepted. |
| 9.2.1. 200 OK |  | 8.2.1. 200 OK |
| The request has succeeded. The information returned with the |  | The request has succeeded. The information returned with the |
| response is dependent on the method used in the request, for example: |  | response is dependent on the method used in the request, for example: |
| GET an entity corresponding to the requested resource is sent in the |  | GET an entity corresponding to the requested resource is sent in the |
| response; |  | response; |
| HEAD the entity-header fields corresponding to the requested |  | HEAD the entity-header fields corresponding to the requested |
| resource are sent in the response without any message-body; |  | resource are sent in the response without any message-body; |
| POST an entity describing or containing the result of the action; |  | POST an entity describing or containing the result of the action; |
| TRACE an entity containing the request message as received by the |  | TRACE an entity containing the request message as received by the |
| end server. |  | end server. |
| 9.2.2. 201 Created |  | 8.2.2. 201 Created |
| The request has been fulfilled and resulted in a new resource being |  | The request has been fulfilled and resulted in a new resource being |
| created. The newly created resource can be referenced by the URI(s) |  | created. The newly created resource can be referenced by the URI(s) |
| returned in the entity of the response, with the most specific URI |  | returned in the entity of the response, with the most specific URI |
| for the resource given by a Location header field. The response |  | for the resource given by a Location header field. The response |
| SHOULD include an entity containing a list of resource |  | SHOULD include an entity containing a list of resource |
| characteristics and location(s) from which the user or user agent can |  | characteristics and location(s) from which the user or user agent can |
| choose the one most appropriate. The entity format is specified by |  | choose the one most appropriate. The entity format is specified by |
| the media type given in the Content-Type header field. The origin |  | the media type given in the Content-Type header field. The origin |
| server MUST create the resource before returning the 201 status code. |  | server MUST create the resource before returning the 201 status code. |
| If the action cannot be carried out immediately, the server SHOULD |  | If the action cannot be carried out immediately, the server SHOULD |
| respond with 202 (Accepted) response instead. |  | respond with 202 (Accepted) response instead. |
| A 201 response MAY contain an ETag response header field indicating |  | A 201 response MAY contain an ETag response header field indicating |
| the current value of the entity tag for the requested variant just |  | the current value of the entity tag for the requested variant just |
| created, see Section 7.1 of [Part4]. |  | created, see Section 6.1 of [Part4]. |
| 9.2.3. 202 Accepted |  | 8.2.3. 202 Accepted |
| The request has been accepted for processing, but the processing has |  | The request has been accepted for processing, but the processing has |
| not been completed. The request might or might not eventually be |  | not been completed. The request might or might not eventually be |
| acted upon, as it might be disallowed when processing actually takes |  | acted upon, as it might be disallowed when processing actually takes |
| place. There is no facility for re-sending a status code from an |  | place. There is no facility for re-sending a status code from an |
| asynchronous operation such as this. |  | asynchronous operation such as this. |
| The 202 response is intentionally non-committal. Its purpose is to |  | The 202 response is intentionally non-committal. Its purpose is to |
| allow a server to accept a request for some other process (perhaps a |  | allow a server to accept a request for some other process (perhaps a |
| batch-oriented process that is only run once per day) without |  | batch-oriented process that is only run once per day) without |
| requiring that the user agent's connection to the server persist |  | requiring that the user agent's connection to the server persist |
| until the process is completed. The entity returned with this |  | until the process is completed. The entity returned with this |
| response SHOULD include an indication of the request's current status |  | response SHOULD include an indication of the request's current status |
| and either a pointer to a status monitor or some estimate of when the |  | and either a pointer to a status monitor or some estimate of when the |
| user can expect the request to be fulfilled. |  | user can expect the request to be fulfilled. |
| 9.2.4. 203 Non-Authoritative Information |  | 8.2.4. 203 Non-Authoritative Information |
| The returned metainformation in the entity-header is not the |  | The returned metainformation in the entity-header is not the |
| definitive set as available from the origin server, but is gathered |  | definitive set as available from the origin server, but is gathered |
| from a local or a third-party copy. The set presented MAY be a |  | from a local or a third-party copy. The set presented MAY be a |
| subset or superset of the original version. For example, including |  | subset or superset of the original version. For example, including |
| local annotation information about the resource might result in a |  | local annotation information about the resource might result in a |
| superset of the metainformation known by the origin server. Use of |  | superset of the metainformation known by the origin server. Use of |
| this response code is not required and is only appropriate when the |  | this response code is not required and is only appropriate when the |
| response would otherwise be 200 (OK). |  | response would otherwise be 200 (OK). |
| 9.2.5. 204 No Content |  | 8.2.5. 204 No Content |
| The server has fulfilled the request but does not need to return an |  | The server has fulfilled the request but does not need to return an |
| entity-body, and might want to return updated metainformation. The |  | entity-body, and might want to return updated metainformation. The |
| response MAY include new or updated metainformation in the form of |  | response MAY include new or updated metainformation in the form of |
| entity-headers, which if present SHOULD be associated with the |  | entity-headers, which if present SHOULD be associated with the |
| requested variant. |  | requested variant. |
| If the client is a user agent, it SHOULD NOT change its document view |  | If the client is a user agent, it SHOULD NOT change its document view |
| from that which caused the request to be sent. This response is |  | from that which caused the request to be sent. This response is |
| primarily intended to allow input for actions to take place without |  | primarily intended to allow input for actions to take place without |
| causing a change to the user agent's active document view, although |  | causing a change to the user agent's active document view, although |
| any new or updated metainformation SHOULD be applied to the document |  | any new or updated metainformation SHOULD be applied to the document |
| currently in the user agent's active view. |  | currently in the user agent's active view. |
| The 204 response MUST NOT include a message-body, and thus is always |  | The 204 response MUST NOT include a message-body, and thus is always |
| terminated by the first empty line after the header fields. |  | terminated by the first empty line after the header fields. |
| 9.2.6. 205 Reset Content |  | 8.2.6. 205 Reset Content |
| The server has fulfilled the request and the user agent SHOULD reset |  | The server has fulfilled the request and the user agent SHOULD reset |
| the document view which caused the request to be sent. This response |  | the document view which caused the request to be sent. This response |
| is primarily intended to allow input for actions to take place via |  | is primarily intended to allow input for actions to take place via |
| user input, followed by a clearing of the form in which the input is |  | user input, followed by a clearing of the form in which the input is |
| given so that the user can easily initiate another input action. The |  | given so that the user can easily initiate another input action. The |
| response MUST NOT include an entity. |  | response MUST NOT include an entity. |
| 9.2.7. 206 Partial Content |  | 8.2.7. 206 Partial Content |
| The server has fulfilled the partial GET request for the resource and |  | The server has fulfilled the partial GET request for the resource and |
| the enclosed entity is a partial representation as defined in |  | the enclosed entity is a partial representation as defined in |
| [Part5]. |  | [Part5]. |
| 9.3. Redirection 3xx |  | 8.3. Redirection 3xx |
| This class of status code indicates that further action needs to be |  | This class of status code indicates that further action needs to be |
| taken by the user agent in order to fulfill the request. The action |  | taken by the user agent in order to fulfill the request. The action |
| required MAY be carried out by the user agent without interaction |  | required MAY be carried out by the user agent without interaction |
| with the user if and only if the method used in the second request is |  | with the user if and only if the method used in the second request is |
| GET or HEAD. A client SHOULD detect infinite redirection loops, |  | GET or HEAD. A client SHOULD detect infinite redirection loops, |
| since such loops generate network traffic for each redirection. |  | since such loops generate network traffic for each redirection. |
| Note: previous versions of this specification recommended a |  | Note: previous versions of this specification recommended a |
| maximum of five redirections. Content developers should be aware |  | maximum of five redirections. Content developers should be aware |
| that there might be clients that implement such a fixed |  | that there might be clients that implement such a fixed |
| limitation. |  | limitation. |
| 9.3.1. 300 Multiple Choices |  | 8.3.1. 300 Multiple Choices |
| The requested resource corresponds to any one of a set of |  | The requested resource corresponds to any one of a set of |
| representations, each with its own specific location, and agent- |  | representations, each with its own specific location, and agent- |
| driven negotiation information (Section 5 of [Part3]) is being |  | driven negotiation information (Section 4 of [Part3]) is being |
| provided so that the user (or user agent) can select a preferred |  | provided so that the user (or user agent) can select a preferred |
| representation and redirect its request to that location. |  | representation and redirect its request to that location. |
| Unless it was a HEAD request, the response SHOULD include an entity |  | Unless it was a HEAD request, the response SHOULD include an entity |
| containing a list of resource characteristics and location(s) from |  | containing a list of resource characteristics and location(s) from |
| which the user or user agent can choose the one most appropriate. |  | which the user or user agent can choose the one most appropriate. |
| The entity format is specified by the media type given in the |  | The entity format is specified by the media type given in the |
| Content-Type header field. Depending upon the format and the |  | Content-Type header field. Depending upon the format and the |
| capabilities of the user agent, selection of the most appropriate |  | capabilities of the user agent, selection of the most appropriate |
| choice MAY be performed automatically. However, this specification |  | choice MAY be performed automatically. However, this specification |
| does not define any standard for such automatic selection. |  | does not define any standard for such automatic selection. |
| If the server has a preferred choice of representation, it SHOULD |  | If the server has a preferred choice of representation, it SHOULD |
| include the specific URI for that representation in the Location |  | include the specific URI for that representation in the Location |
| field; user agents MAY use the Location field value for automatic |  | field; user agents MAY use the Location field value for automatic |
| redirection. This response is cacheable unless indicated otherwise. |  | redirection. This response is cacheable unless indicated otherwise. |
| 9.3.2. 301 Moved Permanently |  | 8.3.2. 301 Moved Permanently |
| The requested resource has been assigned a new permanent URI and any |  | The requested resource has been assigned a new permanent URI and any |
| future references to this resource SHOULD use one of the returned |  | future references to this resource SHOULD use one of the returned |
| 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-target 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 method |  | If the 301 status code is received in response to a request method |
| that is known to be "safe", as defined in Section 8.1.1, then the |  | that is known to be "safe", as defined in Section 7.1.1, then the |
| request MAY be automatically redirected by the user agent without |  | request MAY be automatically redirected by the user agent without |
| confirmation. Otherwise, the user agent MUST NOT automatically |  | confirmation. Otherwise, the user agent MUST NOT automatically |
| redirect the request unless it can be confirmed by the user, since |  | redirect the request unless it can be confirmed by the user, since |
| this might change the conditions under which the request was issued. |  | 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 |  | 8.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-target for future requests. This |
| is only cacheable if indicated by a Cache-Control or Expires header |  | response is only cacheable if indicated by a Cache-Control or Expires |
| field. |  | header 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 method |  | If the 302 status code is received in response to a request method |
| that is known to be "safe", as defined in Section 8.1.1, then the |  | that is known to be "safe", as defined in Section 7.1.1, then the |
| request MAY be automatically redirected by the user agent without |  | request MAY be automatically redirected by the user agent without |
| confirmation. Otherwise, the user agent MUST NOT automatically |  | confirmation. Otherwise, the user agent MUST NOT automatically |
| redirect the request unless it can be confirmed by the user, since |  | redirect the request unless it can be confirmed by the user, since |
| this might change the conditions under which the request was issued. |  | this might change the conditions under which the request was issued. |
| Note: [RFC1945] and [RFC2068] specify that the client is not |  | Note: [RFC1945] and [RFC2068] specify that the client is not |
| 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 |  | 8.3.4. 303 See Other |
| The server directs the user agent to a different resource, indicated |  | The server directs the user agent to a different resource, indicated |
| by a URI in the Location header field, that provides an indirect |  | by a URI in the Location header field, that provides an indirect |
| response to the original request. The user agent MAY perform a GET |  | response to the original request. The user agent MAY perform a GET |
| request on the URI in the Location field in order to obtain a |  | request on the URI in the Location field in order to obtain a |
| representation corresponding to the response, be redirected again, or |  | representation corresponding to the response, be redirected again, or |
| end with an error status. The Location URI is not a substitute |  | end with an error status. The Location URI is not a substitute |
| reference for the originally requested resource. |  | reference for the originally requested resource. |
| The 303 status is generally applicable to any HTTP method. It is |  | The 303 status is generally applicable to any HTTP method. It is |
| skipping to change at page 25, line 7 |  | skipping to change at page 25, line 17 |
| represents the previously requested resource. Note that answers to |  | represents the previously requested resource. Note that answers to |
| the questions of what can be represented, what representations are |  | the questions of what can be represented, what representations are |
| adequate, and what might be a useful description are outside the |  | adequate, and what might be a useful description are outside the |
| scope of HTTP and thus entirely determined by the resource owner(s). |  | scope of HTTP and thus entirely determined by the resource owner(s). |
| A 303 response SHOULD NOT be cached unless it is indicated as |  | A 303 response SHOULD NOT be cached unless it is indicated as |
| cacheable by Cache-Control or Expires header fields. Except for |  | cacheable by Cache-Control or Expires header fields. Except for |
| responses to a HEAD request, the entity of a 303 response SHOULD |  | responses to a HEAD request, the entity of a 303 response SHOULD |
| contain a short hypertext note with a hyperlink to the Location URI. |  | contain a short hypertext note with a hyperlink to the Location URI. |
| 9.3.5. 304 Not Modified |  | 8.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 |  | 8.3.6. 305 Use Proxy |
| The 305 status was defined in a previous version of this |  | The 305 status was defined in a previous version of this |
| specification (see Appendix A.2), and is now deprecated. |  | specification (see Appendix A.2), and is now deprecated. |
| 9.3.7. 306 (Unused) |  | 8.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 |  | 8.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 |
| continue to use the Request-URI for future requests. This response |  | continue to use the request-target for future requests. This |
| is only cacheable if indicated by a Cache-Control or Expires header |  | response is only cacheable if indicated by a Cache-Control or Expires |
| field. |  | header 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 method |  | If the 307 status code is received in response to a request method |
| that is known to be "safe", as defined in Section 8.1.1, then the |  | that is known to be "safe", as defined in Section 7.1.1, then the |
| request MAY be automatically redirected by the user agent without |  | request MAY be automatically redirected by the user agent without |
| confirmation. Otherwise, the user agent MUST NOT automatically |  | confirmation. Otherwise, the user agent MUST NOT automatically |
| redirect the request unless it can be confirmed by the user, since |  | redirect the request unless it can be confirmed by the user, since |
| this might change the conditions under which the request was issued. |  | this might change the conditions under which the request was issued. |
| 9.4. Client Error 4xx |  | 8.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. |
| If the client is sending data, a server implementation using TCP |  | If the client is sending data, a server implementation using TCP |
| SHOULD be careful to ensure that the client acknowledges receipt of |  | SHOULD be careful to ensure that the client acknowledges receipt of |
| the packet(s) containing the response, before the server closes the |  | the packet(s) containing the response, before the server closes the |
| input connection. If the client continues sending data to the server |  | input connection. If the client continues sending data to the server |
| after the close, the server's TCP stack will send a reset packet to |  | after the close, the server's TCP stack will send a reset packet to |
| the client, which may erase the client's unacknowledged input buffers |  | the client, which may erase the client's unacknowledged input buffers |
| before they can be read and interpreted by the HTTP application. |  | before they can be read and interpreted by the HTTP application. |
| 9.4.1. 400 Bad Request |  | 8.4.1. 400 Bad Request |
| The request could not be understood by the server due to malformed |  | The request could not be understood by the server due to malformed |
| syntax. The client SHOULD NOT repeat the request without |  | syntax. The client SHOULD NOT repeat the request without |
| modifications. |  | modifications. |
| 9.4.2. 401 Unauthorized |  | 8.4.2. 401 Unauthorized |
| The request requires user authentication (see [Part7]). |  | The request requires user authentication (see [Part7]). |
| 9.4.3. 402 Payment Required |  | 8.4.3. 402 Payment Required |
| This code is reserved for future use. |  | This code is reserved for future use. |
| 9.4.4. 403 Forbidden |  | 8.4.4. 403 Forbidden |
| The server understood the request, but is refusing to fulfill it. |  | The server understood the request, but is refusing to fulfill it. |
| Authorization will not help and the request SHOULD NOT be repeated. |  | Authorization will not help and the request SHOULD NOT be repeated. |
| If the request method was not HEAD and the server wishes to make |  | If the request method was not HEAD and the server wishes to make |
| public why the request has not been fulfilled, it SHOULD describe the |  | public why the request has not been fulfilled, it SHOULD describe the |
| reason for the refusal in the entity. If the server does not wish to |  | reason for the refusal in the entity. If the server does not wish to |
| make this information available to the client, the status code 404 |  | make this information available to the client, the status code 404 |
| (Not Found) can be used instead. |  | (Not Found) can be used instead. |
| 9.4.5. 404 Not Found |  | 8.4.5. 404 Not Found |
| The server has not found anything matching the Request-URI. No |  | The server has not found anything matching the request-target. No |
| indication is given of whether the condition is temporary or |  | indication is given of whether the condition is temporary or |
| permanent. The 410 (Gone) status code SHOULD be used if the server |  | permanent. The 410 (Gone) status code SHOULD be used if the server |
| knows, through some internally configurable mechanism, that an old |  | knows, through some internally configurable mechanism, that an old |
| resource is permanently unavailable and has no forwarding address. |  | resource is permanently unavailable and has no forwarding address. |
| This status code is commonly used when the server does not wish to |  | This status code is commonly used when the server does not wish to |
| reveal exactly why the request has been refused, or when no other |  | reveal exactly why the request has been refused, or when no other |
| response is applicable. |  | response is applicable. |
| 9.4.6. 405 Method Not Allowed |  | 8.4.6. 405 Method Not Allowed |
| The method specified in the Request-Line is not allowed for the |  | The method specified in the Request-Line is not allowed for the |
| resource identified by the Request-URI. The response MUST include an |  | resource identified by the request-target. The response MUST include |
| Allow header containing a list of valid methods for the requested |  | an Allow header containing a list of valid methods for the requested |
| resource. |  | resource. |
| 9.4.7. 406 Not Acceptable |  | 8.4.7. 406 Not Acceptable |
| The resource identified by the request is only capable of generating |  | The resource identified by the request is only capable of generating |
| response entities which have content characteristics not acceptable |  | response entities which have content characteristics not acceptable |
| according to the accept headers sent in the request. |  | according to the accept headers sent in the request. |
| Unless it was a HEAD request, the response SHOULD include an entity |  | Unless it was a HEAD request, the response SHOULD include an entity |
| containing a list of available entity characteristics and location(s) |  | containing a list of available entity characteristics and location(s) |
| from which the user or user agent can choose the one most |  | from which the user or user agent can choose the one most |
| appropriate. The entity format is specified by the media type given |  | appropriate. The entity format is specified by the media type given |
| in the Content-Type header field. Depending upon the format and the |  | in the Content-Type header field. Depending upon the format and the |
| skipping to change at page 27, line 37 |  | skipping to change at page 27, line 48 |
| Note: HTTP/1.1 servers are allowed to return responses which are |  | Note: HTTP/1.1 servers are allowed to return responses which are |
| not acceptable according to the accept headers sent in the |  | not acceptable according to the accept headers sent in the |
| request. In some cases, this may even be preferable to sending a |  | request. In some cases, this may even be preferable to sending a |
| 406 response. User agents are encouraged to inspect the headers |  | 406 response. User agents are encouraged to inspect the headers |
| of an incoming response to determine if it is acceptable. |  | of an incoming response to determine if it is acceptable. |
| If the response could be unacceptable, a user agent SHOULD |  | If the response could be unacceptable, a user agent SHOULD |
| temporarily stop receipt of more data and query the user for a |  | temporarily stop receipt of more data and query the user for a |
| decision on further actions. |  | decision on further actions. |
| 9.4.8. 407 Proxy Authentication Required |  | 8.4.8. 407 Proxy Authentication Required |
| This code is similar to 401 (Unauthorized), but indicates that the |  | This code is similar to 401 (Unauthorized), but indicates that the |
| client must first authenticate itself with the proxy (see [Part7]). |  | client must first authenticate itself with the proxy (see [Part7]). |
| 9.4.9. 408 Request Timeout |  | 8.4.9. 408 Request Timeout |
| The client did not produce a request within the time that the server |  | The client did not produce a request within the time that the server |
| was prepared to wait. The client MAY repeat the request without |  | was prepared to wait. The client MAY repeat the request without |
| modifications at any later time. |  | modifications at any later time. |
| 9.4.10. 409 Conflict |  | 8.4.10. 409 Conflict |
| The request could not be completed due to a conflict with the current |  | The request could not be completed due to a conflict with the current |
| state of the resource. This code is only allowed in situations where |  | state of the resource. This code is only allowed in situations where |
| it is expected that the user might be able to resolve the conflict |  | it is expected that the user might be able to resolve the conflict |
| and resubmit the request. The response body SHOULD include enough |  | and resubmit the request. The response body SHOULD include enough |
| information for the user to recognize the source of the conflict. |  | information for the user to recognize the source of the conflict. |
| Ideally, the response entity would include enough information for the |  | Ideally, the response entity would include enough information for the |
| user or user agent to fix the problem; however, that might not be |  | user or user agent to fix the problem; however, that might not be |
| possible and is not required. |  | possible and is not required. |
| Conflicts are most likely to occur in response to a PUT request. For |  | Conflicts are most likely to occur in response to a PUT request. For |
| example, if versioning were being used and the entity being PUT |  | example, if versioning were being used and the entity being PUT |
| included changes to a resource which conflict with those made by an |  | included changes to a resource which conflict with those made by an |
| earlier (third-party) request, the server might use the 409 response |  | earlier (third-party) request, the server might use the 409 response |
| to indicate that it can't complete the request. In this case, the |  | to indicate that it can't complete the request. In this case, the |
| response entity would likely contain a list of the differences |  | response entity would likely contain a list of the differences |
| between the two versions in a format defined by the response Content- |  | between the two versions in a format defined by the response Content- |
| Type. |  | Type. |
| 9.4.11. 410 Gone |  | 8.4.11. 410 Gone |
| The requested resource is no longer available at the server and no |  | The requested resource is no longer available at the server and no |
| forwarding address is known. This condition is expected to be |  | forwarding address is known. This condition is expected to be |
| considered permanent. Clients with link editing capabilities SHOULD |  | considered permanent. Clients with link editing capabilities SHOULD |
| delete references to the Request-URI after user approval. If the |  | delete references to the request-target after user approval. If the |
| server does not know, or has no facility to determine, whether or not |  | server does not know, or has no facility to determine, whether or not |
| the condition is permanent, the status code 404 (Not Found) SHOULD be |  | the condition is permanent, the status code 404 (Not Found) SHOULD be |
| used instead. This response is cacheable unless indicated otherwise. |  | used instead. This response is cacheable unless indicated otherwise. |
| The 410 response is primarily intended to assist the task of web |  | The 410 response is primarily intended to assist the task of web |
| maintenance by notifying the recipient that the resource is |  | maintenance by notifying the recipient that the resource is |
| intentionally unavailable and that the server owners desire that |  | intentionally unavailable and that the server owners desire that |
| remote links to that resource be removed. Such an event is common |  | remote links to that resource be removed. Such an event is common |
| for limited-time, promotional services and for resources belonging to |  | for limited-time, promotional services and for resources belonging to |
| individuals no longer working at the server's site. It is not |  | individuals no longer working at the server's site. It is not |
| necessary to mark all permanently unavailable resources as "gone" or |  | necessary to mark all permanently unavailable resources as "gone" or |
| to keep the mark for any length of time -- that is left to the |  | to keep the mark for any length of time -- that is left to the |
| discretion of the server owner. |  | discretion of the server owner. |
| 9.4.12. 411 Length Required |  | 8.4.12. 411 Length Required |
| The server refuses to accept the request without a defined Content- |  | The server refuses to accept the request without a defined Content- |
| Length. The client MAY repeat the request if it adds a valid |  | Length. The client MAY repeat the request if it adds a valid |
| Content-Length header field containing the length of the message-body |  | Content-Length header field containing the length of the message-body |
| in the request message. |  | in the request message. |
| 9.4.13. 412 Precondition Failed |  | 8.4.13. 412 Precondition Failed |
| The precondition given in one or more of the request-header fields |  | The precondition given in one or more of the request-header fields |
| evaluated to false when it was tested on the server, as defined in |  | evaluated to false when it was tested on the server, as defined in |
| [Part4]. |  | [Part4]. |
| 9.4.14. 413 Request Entity Too Large |  | 8.4.14. 413 Request Entity Too Large |
| The server is refusing to process a request because the request |  | The server is refusing to process a request because the request |
| entity is larger than the server is willing or able to process. The |  | entity is larger than the server is willing or able to process. The |
| server MAY close the connection to prevent the client from continuing |  | server MAY close the connection to prevent the client from continuing |
| the request. |  | the request. |
| If the condition is temporary, the server SHOULD include a Retry- |  | If the condition is temporary, the server SHOULD include a Retry- |
| After header field to indicate that it is temporary and after what |  | After header field to indicate that it is temporary and after what |
| time the client MAY try again. |  | time the client MAY try again. |
| 9.4.15. 414 Request-URI Too Long |  | 8.4.15. 414 URI Too Long |
| The server is refusing to service the request because the Request-URI |  | The server is refusing to service the request because the request- |
| is longer than the server is willing to interpret. This rare |  | target is longer than the server is willing to interpret. This rare |
| condition is only likely to occur when a client has improperly |  | condition is only likely to occur when a client has improperly |
| converted a POST request to a GET request with long query |  | converted a POST request to a GET request with long query |
| information, when the client has descended into a URI "black hole" of |  | information, when the client has descended into a URI "black hole" of |
| redirection (e.g., a redirected URI prefix that points to a suffix of |  | redirection (e.g., a redirected URI prefix that points to a suffix of |
| itself), or when the server is under attack by a client attempting to |  | itself), or when the server is under attack by a client attempting to |
| exploit security holes present in some servers using fixed-length |  | exploit security holes present in some servers using fixed-length |
| buffers for reading or manipulating the Request-URI. |  | buffers for reading or manipulating the request-target. |
| 9.4.16. 415 Unsupported Media Type |  | 8.4.16. 415 Unsupported Media Type |
| The server is refusing to service the request because the entity of |  | The server is refusing to service the request because the entity of |
| the request is in a format not supported by the requested resource |  | the request is in a format not supported by the requested resource |
| for the requested method. |  | for the requested method. |
| 9.4.17. 416 Requested Range Not Satisfiable |  | 8.4.17. 416 Requested Range Not Satisfiable |
| The request included a Range request-header field (Section 6.4 of |  | The request included a Range request-header field (Section 5.4 of |
| [Part5]) and none of the range-specifier values in this field overlap |  | [Part5]) and none of the range-specifier values in this field overlap |
| the current extent of the selected resource. |  | the current extent of the selected resource. |
| 9.4.18. 417 Expectation Failed |  | 8.4.18. 417 Expectation Failed |
| The expectation given in an Expect request-header field (see |  | The expectation given in an Expect request-header field (see |
| Section 10.2) could not be met by this server, or, if the server is a |  | Section 9.2) could not be met by this server, or, if the server is a |
| proxy, the server has unambiguous evidence that the request could not |  | proxy, the server has unambiguous evidence that the request could not |
| be met by the next-hop server. |  | be met by the next-hop server. |
| 9.5. Server Error 5xx |  | 8.5. Server Error 5xx |
| Response status codes beginning with the digit "5" indicate cases in |  | Response status codes beginning with the digit "5" indicate cases in |
| which the server is aware that it has erred or is incapable of |  | which the server is aware that it has erred or is incapable of |
| performing the request. Except when responding to a HEAD request, |  | performing the request. Except when responding to a HEAD request, |
| the server SHOULD include an entity containing an explanation of the |  | the server SHOULD include an entity containing an explanation of the |
| error situation, and whether it is a temporary or permanent |  | error situation, and whether it is a temporary or permanent |
| condition. User agents SHOULD display any included entity to the |  | condition. User agents SHOULD display any included entity to the |
| user. These response codes are applicable to any request method. |  | user. These response codes are applicable to any request method. |
| 9.5.1. 500 Internal Server Error |  | 8.5.1. 500 Internal Server Error |
| The server encountered an unexpected condition which prevented it |  | The server encountered an unexpected condition which prevented it |
| from fulfilling the request. |  | from fulfilling the request. |
| 9.5.2. 501 Not Implemented |  | 8.5.2. 501 Not Implemented |
| The server does not support the functionality required to fulfill the |  | The server does not support the functionality required to fulfill the |
| request. This is the appropriate response when the server does not |  | request. This is the appropriate response when the server does not |
| recognize the request method and is not capable of supporting it for |  | recognize the request method and is not capable of supporting it for |
| any resource. |  | any resource. |
| 9.5.3. 502 Bad Gateway |  | 8.5.3. 502 Bad Gateway |
| The server, while acting as a gateway or proxy, received an invalid |  | The server, while acting as a gateway or proxy, received an invalid |
| response from the upstream server it accessed in attempting to |  | response from the upstream server it accessed in attempting to |
| fulfill the request. |  | fulfill the request. |
| 9.5.4. 503 Service Unavailable |  | 8.5.4. 503 Service Unavailable |
| The server is currently unable to handle the request due to a |  | The server is currently unable to handle the request due to a |
| temporary overloading or maintenance of the server. The implication |  | temporary overloading or maintenance of the server. The implication |
| is that this is a temporary condition which will be alleviated after |  | is that this is a temporary condition which will be alleviated after |
| some delay. If known, the length of the delay MAY be indicated in a |  | some delay. If known, the length of the delay MAY be indicated in a |
| Retry-After header. If no Retry-After is given, the client SHOULD |  | Retry-After header. If no Retry-After is given, the client SHOULD |
| handle the response as it would for a 500 response. |  | handle the response as it would for a 500 response. |
| Note: The existence of the 503 status code does not imply that a |  | Note: The existence of the 503 status code does not imply that a |
| server must use it when becoming overloaded. Some servers may |  | server must use it when becoming overloaded. Some servers may |
| wish to simply refuse the connection. |  | wish to simply refuse the connection. |
| 9.5.5. 504 Gateway Timeout |  | 8.5.5. 504 Gateway Timeout |
| The server, while acting as a gateway or proxy, did not receive a |  | The server, while acting as a gateway or proxy, did not receive a |
| timely response from the upstream server specified by the URI (e.g. |  | timely response from the upstream server specified by the URI (e.g. |
| HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed |  | HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed |
| to access in attempting to complete the request. |  | to access in attempting to complete the request. |
| Note: Note to implementors: some deployed proxies are known to |  | Note: Note to implementors: some deployed proxies are known to |
| return 400 or 500 when DNS lookups time out. |  | return 400 or 500 when DNS lookups time out. |
| 9.5.6. 505 HTTP Version Not Supported |  | 8.5.6. 505 HTTP Version Not Supported |
| The server does not support, or refuses to support, the protocol |  | The server does not support, or refuses to support, the protocol |
| version that was used in the request message. The server is |  | version that was used in the request message. The server is |
| indicating that it is unable or unwilling to complete the request |  | indicating that it is unable or unwilling to complete the request |
| using the same major version as the client, as described in Section |  | using the same major version as the client, as described in Section |
| 3.1 of [Part1], other than with this error message. The response |  | 3.1 of [Part1], other than with this error message. The response |
| SHOULD contain an entity describing why that version is not supported |  | SHOULD contain an entity describing why that version is not supported |
| and what other protocols are supported by that server. |  | and what other protocols are supported by that server. |
| 10. Header Field Definitions |  | 9. Header Field Definitions |
| This section defines the syntax and semantics of HTTP/1.1 header |  | This section defines the syntax and semantics of HTTP/1.1 header |
| 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 |  | 9.1. Allow |
| The response-header field "Allow" lists the set of methods advertised |  | The response-header field "Allow" lists the set of methods advertised |
| as supported by the resource identified by the Request-URI. The |  | as supported by the resource identified by the request-target. The |
| purpose of this field is strictly to inform the recipient of valid |  | purpose of this field is strictly to inform the recipient of valid |
| methods associated with the resource. An Allow header field MUST be |  | methods associated with the resource. An Allow header field MUST be |
| present in a 405 (Method Not Allowed) response. |  | present in a 405 (Method Not Allowed) response. |
| Allow = "Allow" ":" OWS Allow-v |  | Allow = "Allow" ":" OWS Allow-v |
| Allow-v = #Method |  | Allow-v = #Method |
| Example of use: |  | Example of use: |
| Allow: GET, HEAD, PUT |  | Allow: GET, HEAD, PUT |
| The actual set of allowed methods is defined by the origin server at |  | The actual set of allowed methods is defined by the origin server at |
| the time of each request. |  | the time of each request. |
| 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 |  | 9.2. Expect |
| The request-header field "Expect" is used to indicate that particular |  | The request-header field "Expect" is used to indicate that particular |
| server behaviors are required by the client. |  | server behaviors are required by the client. |
| Expect = "Expect" ":" OWS Expect-v |  | Expect = "Expect" ":" OWS Expect-v |
| Expect-v = 1#expectation |  | Expect-v = 1#expectation |
| expectation = "100-continue" / expectation-extension |  | expectation = "100-continue" / expectation-extension |
| expectation-extension = token [ "=" ( token / quoted-string ) |  | expectation-extension = token [ "=" ( token / quoted-string ) |
| *expect-params ] |  | *expect-params ] |
| skipping to change at page 32, line 41 |  | skipping to change at page 33, line 5 |
| 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 |  | 9.3. From |
| The request-header field "From", if given, SHOULD contain an Internet |  | The request-header field "From", if given, SHOULD contain an Internet |
| e-mail address for the human user who controls the requesting user |  | e-mail address for the human user who controls the requesting user |
| agent. The address SHOULD be machine-usable, as defined by "mailbox" |  | agent. The address SHOULD be machine-usable, as defined by "mailbox" |
| in Section 3.4 of [RFC5322]: |  | in Section 3.4 of [RFC5322]: |
| From = "From" ":" OWS From-v |  | From = "From" ":" OWS From-v |
| From-v = mailbox |  | From-v = mailbox |
| mailbox = <mailbox, defined in [RFC5322], Section 3.4> |  | mailbox = <mailbox, defined in [RFC5322], Section 3.4> |
| skipping to change at page 33, line 28 |  | skipping to change at page 33, line 41 |
| Internet host which issued the request. For example, when a request |  | Internet host which issued the request. For example, when a request |
| is passed through a proxy the original issuer's address SHOULD be |  | is passed through a proxy the original issuer's address SHOULD be |
| 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 |  | 9.4. Location |
| The response-header field "Location" is used for the identification |  | The response-header field "Location" is used for the identification |
| of a new resource or to redirect the recipient to a location other |  | of a new resource or to redirect the recipient to a location other |
| than the Request-URI for completion of the request. For 201 |  | than the request-target for completion of the request. For 201 |
| (Created) responses, the Location is that of the new resource which |  | (Created) responses, the Location is that of the new resource which |
| was created by the request. For 3xx responses, the location SHOULD |  | was created by the request. For 3xx responses, the location SHOULD |
| indicate the server's preferred URI for automatic redirection to the |  | indicate the server's preferred URI for automatic redirection to the |
| resource. The field value consists of a single absolute URI. |  | resource. The field value consists of a single absolute URI. |
| Location = "Location" ":" OWS Location-v |  | Location = "Location" ":" OWS Location-v |
| Location-v = absolute-URI [ "#" fragment ] |  | Location-v = absolute-URI [ "#" fragment ] |
| An example is: |  | An example is: |
| Location: http://www.example.org/pub/WWW/People.html |  | Location: http://www.example.org/pub/WWW/People.html |
| Note: The Content-Location header field (Section 6.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 response. It is |  | original location of the entity enclosed in the response. It is |
| therefore possible for a response to contain header fields for |  | therefore possible for a response to contain header fields for |
| both Location and Content-Location. |  | both Location and Content-Location. |
| There are circumstances in which a fragment identifier in a Location |  | There are circumstances in which a fragment identifier in a Location |
| URL would not be appropriate: |  | URL would not be appropriate: |
| o With a 201 Created response, because in this usage the Location |  | o With a 201 Created response, because in this usage the Location |
| header specifies the URL for the entire created resource. |  | header specifies the URL for the entire created resource. |
| o With a 300 Multiple Choices, since the choice decision is intended |  | o With a 300 Multiple Choices, since the choice decision is intended |
| to be made on resource characteristics and not fragment |  | to be made on resource characteristics and not fragment |
| characteristics. |  | characteristics. |
| o With 305 Use Proxy. |  | o With 305 Use Proxy. |
| 10.5. Max-Forwards |  | 9.5. Max-Forwards |
| The request-header "Max-Forwards" field provides a mechanism with the |  | The request-header "Max-Forwards" field provides a mechanism with the |
| TRACE (Section 8.8) and OPTIONS (Section 8.2) methods to limit the |  | TRACE (Section 7.8) and OPTIONS (Section 7.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" ":" OWS Max-Forwards-v |  | Max-Forwards = "Max-Forwards" ":" OWS Max-Forwards-v |
| Max-Forwards-v = 1*DIGIT |  | Max-Forwards-v = 1*DIGIT |
| The Max-Forwards value is a decimal integer indicating the remaining |  | The Max-Forwards value is a decimal integer indicating the remaining |
| number of times this request message may be forwarded. |  | number of times this request message may be forwarded. |
| skipping to change at page 34, line 42 |  | skipping to change at page 35, line 5 |
| value prior to forwarding the request. If the received value is zero |  | value prior to forwarding the request. If the received value is zero |
| (0), the recipient MUST NOT forward the request; instead, it MUST |  | (0), the recipient MUST NOT forward the request; instead, it MUST |
| respond as the final recipient. If the received Max-Forwards value |  | respond as the final recipient. If the received Max-Forwards value |
| is greater than zero, then the forwarded message MUST contain an |  | is greater than zero, then the forwarded message MUST contain an |
| updated Max-Forwards field with a value decremented by one (1). |  | updated Max-Forwards field with a value decremented by one (1). |
| The Max-Forwards header field MAY be ignored for all other methods |  | The Max-Forwards header field MAY be ignored for all other methods |
| defined by this specification and for any extension methods for which |  | defined by this specification and for any extension methods for which |
| it is not explicitly referred to as part of that method definition. |  | it is not explicitly referred to as part of that method definition. |
| 10.6. Referer |  | 9.6. Referer |
| The request-header field "Referer" [sic] allows the client to |  | The request-header field "Referer" [sic] allows the client to |
| specify, for the server's benefit, the address (URI) of the resource |  | specify, for the server's benefit, the address (URI) of the resource |
| from which the Request-URI was obtained (the "referrer", although the |  | from which the request-target was obtained (the "referrer", although |
| header field is misspelled.) The Referer request-header allows a |  | the header field is misspelled.) The Referer request-header allows a |
| 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-target was obtained from a source that does not |
| its own URI, such as input from the user keyboard. |  | have its own URI, such as input from the user keyboard. |
| Referer = "Referer" ":" OWS Referer-v |  | Referer = "Referer" ":" OWS Referer-v |
| Referer-v = absolute-URI / relativeURI |  | Referer-v = absolute-URI / partial-URI |
| Example: |  | Example: |
| Referer: http://www.example.org/hypertext/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-target. The URI MUST NOT include a fragment. |
| See Section 12.2 for security considerations. |  | See Section 11.2 for security considerations. |
| 10.7. Retry-After |  | 9.7. Retry-After |
| The response-header "Retry-After" field can be used with a 503 |  | The response-header "Retry-After" field can be used with a 503 |
| (Service Unavailable) response to indicate how long the service is |  | (Service Unavailable) response to indicate how long the service is |
| expected to be unavailable to the requesting client. This field MAY |  | expected to be unavailable to the requesting client. This field MAY |
| also be used with any 3xx (Redirection) response to indicate the |  | also be used with any 3xx (Redirection) response to indicate the |
| minimum time the user-agent is asked wait before issuing the |  | minimum time the user-agent is asked wait before issuing the |
| redirected request. The value of this field can be either an HTTP- |  | redirected request. The value of this field can be either an HTTP- |
| date or an integer number of seconds (in decimal) after the time of |  | date or an integer number of seconds (in decimal) after the time of |
| the response. |  | the response. |
| skipping to change at page 35, line 43 |  | skipping to change at page 36, line 5 |
| delta-seconds = 1*DIGIT |  | delta-seconds = 1*DIGIT |
| Two examples of its use are |  | Two examples of its use are |
| Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |  | Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |
| Retry-After: 120 |  | Retry-After: 120 |
| In the latter example, the delay is 2 minutes. |  | In the latter example, the delay is 2 minutes. |
| 10.8. Server |  | 9.8. Server |
| The response-header field "Server" contains information about the |  | The response-header field "Server" contains information about the |
| software used by the origin server to handle the request. The field |  | software used by the origin server to handle the request. The field |
| can contain multiple product tokens (Section 3.5 of [Part1]) and |  | can contain multiple product tokens (Section 3.4 of [Part1]) and |
| comments identifying the server and any significant subproducts. The |  | comments identifying the server and any significant subproducts. The |
| product tokens are listed in order of their significance for |  | product tokens are listed in order of their significance for |
| identifying the application. |  | identifying the application. |
| Server = "Server" ":" OWS Server-v |  | Server = "Server" ":" OWS Server-v |
| Server-v = product |  | Server-v = product |
| *( RWS ( product / comment ) ) |  | *( RWS ( product / comment ) ) |
| Example: |  | Example: |
| skipping to change at page 36, line 23 |  | skipping to change at page 36, line 32 |
| If the response is being forwarded through a proxy, the proxy |  | If the response is being forwarded through a proxy, the proxy |
| application MUST NOT modify the Server response-header. Instead, it |  | application MUST NOT modify the Server response-header. Instead, it |
| MUST include a Via field (as described in Section 8.9 of [Part1]). |  | MUST include a Via field (as described in Section 8.9 of [Part1]). |
| 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 |  | 9.9. User-Agent |
| The request-header field "User-Agent" contains information about the |  | The request-header field "User-Agent" contains information about the |
| user agent originating the request. This is for statistical |  | user agent originating the request. This is for statistical |
| purposes, the tracing of protocol violations, and automated |  | purposes, the tracing of protocol violations, and automated |
| recognition of user agents for the sake of tailoring responses to |  | recognition of user agents for the sake of tailoring responses to |
| avoid particular user agent limitations. User agents SHOULD include |  | avoid particular user agent limitations. User agents SHOULD include |
| this field with requests. The field can contain multiple product |  | this field with requests. The field can contain multiple product |
| tokens (Section 3.5 of [Part1]) and comments identifying the agent |  | tokens (Section 3.4 of [Part1]) and comments identifying the agent |
| and any subproducts which form a significant part of the user agent. |  | and any subproducts which form a significant part of the user agent. |
| By convention, the product tokens are listed in order of their |  | By convention, the product tokens are listed in order of their |
| significance for identifying the application. |  | significance for identifying the application. |
| User-Agent = "User-Agent" ":" OWS User-Agent-v |  | User-Agent = "User-Agent" ":" OWS User-Agent-v |
| User-Agent-v = product |  | User-Agent-v = product |
| *( RWS ( product / comment ) ) |  | *( RWS ( 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 |  | 10. IANA Considerations |
| 11.1. Method Registry |  | 10.1. Method Registry |
| The registration procedure for HTTP Methods is defined by Section 3.1 |  | The registration procedure for HTTP Methods is defined by Section 2.1 |
| of this document. |  | of this document. |
| The HTTP Method Registry located at |  | The HTTP Method Registry located at |
| <http://www.iana.org/assignments/http-methods> should be populated |  | <http://www.iana.org/assignments/http-methods> should be populated |
| with the registrations below: |  | with the registrations below: |
| +---------+------+-------------+ |  | +---------+------+-------------+ |
| | Method | Safe | Reference | |  | | Method | Safe | Reference | |
| +---------+------+-------------+ |  | +---------+------+-------------+ |
| | CONNECT | no | Section 8.9 | |  | | CONNECT | no | Section 7.9 | |
| | DELETE | no | Section 8.7 | |  | | DELETE | no | Section 7.7 | |
| | GET | yes | Section 8.3 | |  | | GET | yes | Section 7.3 | |
| | HEAD | yes | Section 8.4 | |  | | HEAD | yes | Section 7.4 | |
| | OPTIONS | yes | Section 8.2 | |  | | OPTIONS | yes | Section 7.2 | |
| | POST | no | Section 8.5 | |  | | POST | no | Section 7.5 | |
| | PUT | no | Section 8.6 | |  | | PUT | no | Section 7.6 | |
| | TRACE | yes | Section 8.8 | |  | | TRACE | yes | Section 7.8 | |
| +---------+------+-------------+ |  | +---------+------+-------------+ |
| 11.2. Status Code Registry |  | 10.2. Status Code Registry |
| The registration procedure for HTTP Status Codes -- previously |  | The registration procedure for HTTP Status Codes -- previously |
| defined in Section 7.1 of [RFC2817] -- is now defined by Section 5.1 |  | defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.1 |
| of this document. |  | of this document. |
| The HTTP Status Code Registry located at |  | The HTTP Status Code Registry located at |
| <http://www.iana.org/assignments/http-status-codes> should be updated |  | <http://www.iana.org/assignments/http-status-codes> should be updated |
| with the registrations below: |  | with the registrations below: |
| +-------+---------------------------------+----------------+ |  | +-------+---------------------------------+----------------+ |
| | Value | Description | Reference | |  | | Value | Description | Reference | |
| +-------+---------------------------------+----------------+ |  | +-------+---------------------------------+----------------+ |
| | 100 | Continue | Section 9.1.1 | |  | | 100 | Continue | Section 8.1.1 | |
| | 101 | Switching Protocols | Section 9.1.2 | |  | | 101 | Switching Protocols | Section 8.1.2 | |
| | 200 | OK | Section 9.2.1 | |  | | 200 | OK | Section 8.2.1 | |
| | 201 | Created | Section 9.2.2 | |  | | 201 | Created | Section 8.2.2 | |
| | 202 | Accepted | Section 9.2.3 | |  | | 202 | Accepted | Section 8.2.3 | |
| | 203 | Non-Authoritative Information | Section 9.2.4 | |  | | 203 | Non-Authoritative Information | Section 8.2.4 | |
| | 204 | No Content | Section 9.2.5 | |  | | 204 | No Content | Section 8.2.5 | |
| | 205 | Reset Content | Section 9.2.6 | |  | | 205 | Reset Content | Section 8.2.6 | |
| | 206 | Partial Content | Section 9.2.7 | |  | | 206 | Partial Content | Section 8.2.7 | |
| | 300 | Multiple Choices | Section 9.3.1 | |  | | 300 | Multiple Choices | Section 8.3.1 | |
| | 301 | Moved Permanently | Section 9.3.2 | |  | | 301 | Moved Permanently | Section 8.3.2 | |
| | 302 | Found | Section 9.3.3 | |  | | 302 | Found | Section 8.3.3 | |
| | 303 | See Other | Section 9.3.4 | |  | | 303 | See Other | Section 8.3.4 | |
| | 304 | Not Modified | Section 9.3.5 | |  | | 304 | Not Modified | Section 8.3.5 | |
| | 305 | Use Proxy | Section 9.3.6 | |  | | 305 | Use Proxy | Section 8.3.6 | |
| | 306 | (Unused) | Section 9.3.7 | |  | | 306 | (Unused) | Section 8.3.7 | |
| | 307 | Temporary Redirect | Section 9.3.8 | |  | | 307 | Temporary Redirect | Section 8.3.8 | |
| | 400 | Bad Request | Section 9.4.1 | |  | | 400 | Bad Request | Section 8.4.1 | |
| | 401 | Unauthorized | Section 9.4.2 | |  | | 401 | Unauthorized | Section 8.4.2 | |
| | 402 | Payment Required | Section 9.4.3 | |  | | 402 | Payment Required | Section 8.4.3 | |
| | 403 | Forbidden | Section 9.4.4 | |  | | 403 | Forbidden | Section 8.4.4 | |
| | 404 | Not Found | Section 9.4.5 | |  | | 404 | Not Found | Section 8.4.5 | |
| | 405 | Method Not Allowed | Section 9.4.6 | |  | | 405 | Method Not Allowed | Section 8.4.6 | |
| | 406 | Not Acceptable | Section 9.4.7 | |  | | 406 | Not Acceptable | Section 8.4.7 | |
| | 407 | Proxy Authentication Required | Section 9.4.8 | |  | | 407 | Proxy Authentication Required | Section 8.4.8 | |
| | 408 | Request Timeout | Section 9.4.9 | |  | | 408 | Request Timeout | Section 8.4.9 | |
| | 409 | Conflict | Section 9.4.10 | |  | | 409 | Conflict | Section 8.4.10 | |
| | 410 | Gone | Section 9.4.11 | |  | | 410 | Gone | Section 8.4.11 | |
| | 411 | Length Required | Section 9.4.12 | |  | | 411 | Length Required | Section 8.4.12 | |
| | 412 | Precondition Failed | Section 9.4.13 | |  | | 412 | Precondition Failed | Section 8.4.13 | |
| | 413 | Request Entity Too Large | Section 9.4.14 | |  | | 413 | Request Entity Too Large | Section 8.4.14 | |
| | 414 | Request-URI Too Long | Section 9.4.15 | |  | | 414 | URI Too Long | Section 8.4.15 | |
| | 415 | Unsupported Media Type | Section 9.4.16 | |  | | 415 | Unsupported Media Type | Section 8.4.16 | |
| | 416 | Requested Range Not Satisfiable | Section 9.4.17 | |  | | 416 | Requested Range Not Satisfiable | Section 8.4.17 | |
| | 417 | Expectation Failed | Section 9.4.18 | |  | | 417 | Expectation Failed | Section 8.4.18 | |
| | 500 | Internal Server Error | Section 9.5.1 | |  | | 500 | Internal Server Error | Section 8.5.1 | |
| | 501 | Not Implemented | Section 9.5.2 | |  | | 501 | Not Implemented | Section 8.5.2 | |
| | 502 | Bad Gateway | Section 9.5.3 | |  | | 502 | Bad Gateway | Section 8.5.3 | |
| | 503 | Service Unavailable | Section 9.5.4 | |  | | 503 | Service Unavailable | Section 8.5.4 | |
| | 504 | Gateway Timeout | Section 9.5.5 | |  | | 504 | Gateway Timeout | Section 8.5.5 | |
| | 505 | HTTP Version Not Supported | Section 9.5.6 | |  | | 505 | HTTP Version Not Supported | Section 8.5.6 | |
| +-------+---------------------------------+----------------+ |  | +-------+---------------------------------+----------------+ |
| 11.3. Message Header Registration |  | 10.3. Message Header Registration |
| The Message Header Registry located at <http://www.iana.org/ |  | The Message Header Registry located at <http://www.iana.org/ |
| assignments/message-headers/message-header-index.html> should be |  | assignments/message-headers/message-header-index.html> should be |
| updated with the permanent registrations below (see [RFC3864]): |  | updated with the permanent registrations below (see [RFC3864]): |
| +-------------------+----------+----------+--------------+ |  | +-------------------+----------+----------+-------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +-------------------+----------+----------+--------------+ |  | +-------------------+----------+----------+-------------+ |
| | Allow | http | standard | Section 10.1 | |  | | Allow | http | standard | Section 9.1 | |
| | Expect | http | standard | Section 10.2 | |  | | Expect | http | standard | Section 9.2 | |
| | From | http | standard | Section 10.3 | |  | | From | http | standard | Section 9.3 | |
| | Location | http | standard | Section 10.4 | |  | | Location | http | standard | Section 9.4 | |
| | Max-Forwards | http | standard | Section 10.5 | |  | | Max-Forwards | http | standard | Section 9.5 | |
| | Referer | http | standard | Section 10.6 | |  | | Referer | http | standard | Section 9.6 | |
| | Retry-After | http | standard | Section 10.7 | |  | | Retry-After | http | standard | Section 9.7 | |
| | Server | http | standard | Section 10.8 | |  | | Server | http | standard | Section 9.8 | |
| | User-Agent | http | standard | Section 10.9 | |  | | User-Agent | http | standard | Section 9.9 | |
| +-------------------+----------+----------+--------------+ |  | +-------------------+----------+----------+-------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 12. Security Considerations |  | 11. 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 |  | 11.1. Transfer of Sensitive Information |
| Like any generic data transfer protocol, HTTP cannot regulate the |  | Like any generic data transfer protocol, HTTP cannot regulate the |
| content of the data that is transferred, nor is there any a priori |  | content of the data that is transferred, nor is there any a priori |
| method of determining the sensitivity of any particular piece of |  | method of determining the sensitivity of any particular piece of |
| information within the context of any given request. Therefore, |  | information within the context of any given request. Therefore, |
| applications SHOULD supply as much control over this information as |  | applications SHOULD supply as much control over this information as |
| possible to the provider of that information. Four header fields are |  | possible to the provider of that information. Four header fields are |
| worth special mention in this context: Server, Via, Referer and From. |  | worth special mention in this context: Server, Via, Referer and From. |
| Revealing the specific software version of the server might allow the |  | Revealing the specific software version of the server might allow the |
| skipping to change at page 40, line 27 |  | skipping to change at page 40, line 27 |
| privacy interests or their site's security policy, and hence it |  | privacy interests or their site's security policy, and hence it |
| SHOULD NOT be transmitted without the user being able to disable, |  | SHOULD NOT be transmitted without the user being able to disable, |
| enable, and modify the contents of the field. The user MUST be able |  | enable, and modify the contents of the field. The user MUST be able |
| to set the contents of this field within a user preference or |  | to set the contents of this field within a user preference or |
| application defaults configuration. |  | application defaults configuration. |
| We suggest, though do not require, that a convenient toggle interface |  | We suggest, though do not require, that a convenient toggle interface |
| be provided for the user to enable or disable the sending of From and |  | be provided for the user to enable or disable the sending of From and |
| Referer information. |  | Referer information. |
| The User-Agent (Section 10.9) or Server (Section 10.8) header fields |  | The User-Agent (Section 9.9) or Server (Section 9.8) header fields |
| can sometimes be used to determine that a specific client or server |  | can sometimes be used to determine that a specific client or server |
| have a particular security hole which might be exploited. |  | have a particular security hole which might be exploited. |
| Unfortunately, this same information is often used for other valuable |  | Unfortunately, this same information is often used for other valuable |
| purposes for which HTTP currently has no better mechanism. |  | purposes for which HTTP currently has no better mechanism. |
| 12.2. Encoding Sensitive Information in URIs |  | 11.2. Encoding Sensitive Information in URIs |
| Because the source of a link might be private information or might |  | Because the source of a link might be private information or might |
| reveal an otherwise private information source, it is strongly |  | reveal an otherwise private information source, it is strongly |
| recommended that the user be able to select whether or not the |  | recommended that the user be able to select whether or not the |
| Referer field is sent. For example, a browser client could have a |  | Referer field is sent. For example, a browser client could have a |
| toggle switch for browsing openly/anonymously, which would |  | toggle switch for browsing openly/anonymously, which would |
| respectively enable/disable the sending of Referer and From |  | respectively enable/disable the sending of Referer and From |
| information. |  | information. |
| Clients SHOULD NOT include a Referer header field in a (non-secure) |  | Clients SHOULD NOT include a Referer header field in a (non-secure) |
| HTTP request if the referring page was transferred with a secure |  | HTTP request if the referring page was transferred with a secure |
| protocol. |  | protocol. |
| Authors of services should not use GET-based forms for the submission |  | Authors of services should not use GET-based forms for the submission |
| of sensitive data because that data will be encoded in the Request- |  | of sensitive data because that data will be encoded in the Request- |
| URI. Many existing servers, proxies, and user agents log or display |  | target. Many existing servers, proxies, and user agents log or |
| the Request-URI in places where it might be visible to third parties. |  | display the Request-target in places where it might be visible to |
| Such services can use POST-based form submission instead. |  | third parties. Such services can use POST-based form submission |
|  |  | instead. |
| 12.3. Location Headers and Spoofing |  | 11.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 |  | 12. Acknowledgments |
| 14. References |  | 13. References |
| 14.1. Normative References |  | 13.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-05 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-06 |
| (work in progress), November 2008. |  | (work in progress), March 2009. |
| [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-05 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-06 |
| (work in progress), November 2008. |  | (work in progress), March 2009. |
| [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-05 (work in |  | Requests", draft-ietf-httpbis-p4-conditional-06 (work in |
| progress), November 2008. |  | progress), March 2009. |
| [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-05 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-06 (work |
| in progress), November 2008. |  | in progress), March 2009. |
| [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-05 (work in progress), |  | draft-ietf-httpbis-p6-cache-06 (work in progress), |
| November 2008. |  | March 2009. |
| [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-05 (work in progress), |  | draft-ietf-httpbis-p7-auth-06 (work in progress), |
| November 2008. |  | March 2009. |
| [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 |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
|  |  | Specifications: ABNF", STD 68, RFC 5234, January 2008. |
|  |  | 13.2. Informative References |
| [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext |  | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext |
| 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 |
| skipping to change at page 42, line 43 |  | skipping to change at page 42, line 49 |
| May 2008. |  | May 2008. |
| [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |  | [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |
| October 2008. |  | October 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 8.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 8.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 |
| skipping to change at page 43, line 31 |  | skipping to change at page 43, line 36 |
| before it sends a required 100 (Continue) response. |  | before it sends a required 100 (Continue) response. |
| 6. Allow, rather than require, a server to omit 100 (Continue) if it |  | 6. Allow, rather than require, a server to omit 100 (Continue) if it |
| has already seen some of the request body. |  | has already seen some of the request body. |
| 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 8.4.4, |
| 9.4.5, and 9.4.11) |  | 8.4.5, and 8.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 Section |  | implemented in previous versions of this specification. See Section |
| 19.6.1 of [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 |  | This document takes over the Status Code Registry, previously defined |
| in Section 7.1 of [RFC2817]. (Section 5.1) |  | in Section 7.1 of [RFC2817]. (Section 4.1) |
| Clarify definition of POST. (Section 8.5) |  | Clarify definition of POST. (Section 7.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 8.3.2, 8.3.3 and 8.3.8) |
| Deprecate 305 Use Proxy status code, because user agents did not |  | Deprecate 305 Use Proxy status code, because user agents did not |
| implement it. It used to indicate that the requested resource must |  | implement it. It used to indicate that the requested resource must |
| be accessed through the proxy given by the Location field. The |  | be accessed through the proxy given by the Location field. The |
| Location field gave the URI of the proxy. The recipient was expected |  | Location field gave the URI of the proxy. The recipient was expected |
| to repeat this single request via the proxy. (Section 9.3.6) |  | to repeat this single request via the proxy. (Section 8.3.6) |
| Reclassify Allow header as response header, removing the option to |  | Reclassify Allow header as response header, removing the option to |
| specify it in a PUT request. Relax the server requirement on the |  | specify it in a PUT request. Relax the server requirement on the |
| contents of the Allow header and remove requirement on clients to |  | contents of the Allow header and remove requirement on clients to |
| always trust the header value. (Section 10.1) |  | always trust the header value. (Section 9.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 9.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 9.8) |
| Appendix B. Change Log (to be removed by RFC Editor before publication) |  | Appendix B. Collected ABNF |
| B.1. Since RFC2616 |  | Accept = <Accept, defined in [Part3], Section 5.1> |
|  |  | Accept-Charset = <Accept-Charset, defined in [Part3], Section 5.2> |
|  |  | Accept-Encoding = <Accept-Encoding, defined in [Part3], Section 5.3> |
|  |  | Accept-Language = <Accept-Language, defined in [Part3], Section 5.4> |
|  |  | Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 5.1> |
|  |  | Age = <Age, defined in [Part6], Section 3.1> |
|  |  | Allow = "Allow:" OWS Allow-v |
|  |  | Allow-v = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] |
|  |  | Authorization = <Authorization, defined in [Part7], Section 3.1> |
|  |  | ETag = <ETag, defined in [Part4], Section 6.1> |
|  |  | Expect = "Expect:" OWS Expect-v |
|  |  | Expect-v = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) |
|  |  | From = "From:" OWS From-v |
|  |  | From-v = mailbox |
|  |  | HTTP-date = <HTTP-date, defined in [Part1], Section 3.2.1> |
|  |  | Host = <Host, defined in [Part1], Section 2.1> |
|  |  | If-Match = <If-Match, defined in [Part4], Section 6.2> |
|  |  | If-Modified-Since = |
|  |  | <If-Modified-Since, defined in [Part4], Section 6.3> |
|  |  | If-None-Match = <If-None-Match, defined in [Part4], Section 6.4> |
|  |  | If-Range = <If-Range, defined in [Part5], Section 5.3> |
|  |  | If-Unmodified-Since = |
|  |  | <If-Unmodified-Since, defined in [Part4], Section 6.5> |
|  |  | Location = "Location:" OWS Location-v |
|  |  | Location-v = absolute-URI [ "#" fragment ] |
|  |  | Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v |
|  |  | Max-Forwards-v = 1*DIGIT |
|  |  | Method = %x4F.50.54.49.4F.4E.53 / %x47.45.54 / %x48.45.41.44 / |
|  |  | %x50.4F.54 / %x50.55.54 / %x44.45.4C.45.54.45 / %x54.52.41.43.45 / |
|  |  | %x43.4E.4E.45.43.54 / extension-method |
|  |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
|  |  | Proxy-Authenticate = |
|  |  | <Proxy-Authenticate, defined in [Part7], Section 3.2> |
|  |  | Proxy-Authorization = |
|  |  | <Proxy-Authorization, defined in [Part7], Section 3.3> |
|  |  | RWS = <RWS, defined in [Part1], Section 1.2.2> |
|  |  | Range = <Range, defined in [Part5], Section 5.4> |
|  |  | Reason-Phrase = *( WSP / VCHAR / obs-text ) |
|  |  | Referer = "Referer:" OWS Referer-v |
|  |  | Referer-v = absolute-URI / partial-URI |
|  |  | Retry-After = "Retry-After:" OWS Retry-After-v |
|  |  | Retry-After-v = HTTP-date / delta-seconds |
|  |  | Server = "Server:" OWS Server-v |
|  |  | Server-v = product *( RWS ( product / comment ) ) |
|  |  | Status-Code = "100" / "101" / "200" / "201" / "202" / "203" / "204" / |
|  |  | "205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" / |
|  |  | "307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" / |
|  |  | "407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" / |
|  |  | "415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" / |
|  |  | "505" / extension-code |
|  |  | TE = <TE, defined in [Part1], Section 8.8> |
|  |  | User-Agent = "User-Agent:" OWS User-Agent-v |
|  |  | User-Agent-v = product *( RWS ( product / comment ) ) |
|  |  | Vary = <Vary, defined in [Part6], Section 3.5> |
|  |  | WWW-Authenticate = |
|  |  | <WWW-Authenticate, defined in [Part7], Section 3.4> |
|  |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.1> |
|  |  | comment = <comment, defined in [Part1], Section 1.2.2> |
|  |  | delta-seconds = 1*DIGIT |
|  |  | expect-params = ";" token [ "=" ( token / quoted-string ) ] |
|  |  | expectation = "100-continue" / expectation-extension |
|  |  | expectation-extension = token [ "=" ( token / quoted-string ) |
|  |  | *expect-params ] |
|  |  | extension-code = 3DIGIT |
|  |  | extension-method = token |
|  |  | fragment = <fragment, defined in [Part1], Section 2.1> |
|  |  | mailbox = <mailbox, defined in [RFC5322], Section 3.4> |
|  |  | obs-text = <obs-text, defined in [Part1], Section 1.2.2> |
|  |  | partial-URI = <partial-URI, defined in [Part1], Section 2.1> |
|  |  | product = <product, defined in [Part1], Section 3.4> |
|  |  | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |
|  |  | request-header = Accept / Accept-Charset / Accept-Encoding / |
|  |  | Accept-Language / Authorization / Expect / From / Host / If-Match / |
|  |  | If-Modified-Since / If-None-Match / If-Range / If-Unmodified-Since / |
|  |  | Max-Forwards / Proxy-Authorization / Range / Referer / TE / |
|  |  | User-Agent |
|  |  | response-header = Accept-Ranges / Age / Allow / ETag / Location / |
|  |  | Proxy-Authenticate / Retry-After / Server / Vary / WWW-Authenticate |
|  |  | token = <token, defined in [Part1], Section 1.2.2> |
|  |  | ABNF diagnostics: |
|  |  | ; Reason-Phrase defined but not used |
|  |  | ; Status-Code defined but not used |
|  |  | ; request-header defined but not used |
|  |  | ; response-header defined but not used |
|  |  | Appendix C. Change Log (to be removed by RFC Editor before publication) |
|  |  | C.1. Since RFC2616 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| B.2. Since draft-ietf-httpbis-p2-semantics-00 |  | C.2. Since draft-ietf-httpbis-p2-semantics-00 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a MUST" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a MUST" |
| (<http://purl.org/NET/http-errata#via-must>) |  | (<http://purl.org/NET/http-errata#via-must>) |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/6>: "Fragments |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/6>: "Fragments |
| allowed in Location" |  | allowed in Location" |
| (<http://purl.org/NET/http-errata#location-fragments>) |  | (<http://purl.org/NET/http-errata#location-fragments>) |
| skipping to change at page 45, line 14 |  | skipping to change at page 47, line 45 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative |
| references" |  | references" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant |
| cross-references" |  | cross-references" |
| Other changes: |  | Other changes: |
| o Move definitions of 304 and 412 condition codes to [Part4] |  | o Move definitions of 304 and 412 condition codes to [Part4] |
| B.3. Since draft-ietf-httpbis-p2-semantics-01 |  | C.3. Since draft-ietf-httpbis-p2-semantics-01 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side |
| effects" |  | effects" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate Host |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate Host |
| header requirements" |  | header requirements" |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| 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 |
| skipping to change at page 45, line 36 |  | skipping to change at page 48, line 19 |
| 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 |  | C.4. Since draft-ietf-httpbis-p2-semantics-02 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring |
| Allow in 405 responses" |  | Allow in 405 responses" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status Code |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status Code |
| Registry" |  | Registry" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/61>: "Redirection |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/61>: "Redirection |
| skipping to change at page 46, line 24 |  | skipping to change at page 49, line 8 |
| o Reference RFC 3984, and update header registrations for headers |  | o Reference RFC 3984, and update header registrations for headers |
| defined in this document. |  | defined in this document. |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Replace string literals when the string really is case-sensitive |  | o Replace string literals when the string really is case-sensitive |
| (method). |  | (method). |
| B.5. Since draft-ietf-httpbis-p2-semantics-03 |  | C.5. Since draft-ietf-httpbis-p2-semantics-03 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/98>: "OPTIONS |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/98>: "OPTIONS |
| request bodies" |  | request bodies" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/119>: "Description |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/119>: "Description |
| of CONNECT should refer to RFC2817" |  | of CONNECT should refer to RFC2817" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/125>: "Location |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/125>: "Location |
| Content-Location reference request/response mixup" |  | Content-Location reference request/response mixup" |
| Ongoing work on Method Registry |  | Ongoing work on Method Registry |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/72>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/72>): |
| o Added initial proposal for registration process, plus initial |  | o Added initial proposal for registration process, plus initial |
| content (non-HTTP/1.1 methods to be added by a separate |  | content (non-HTTP/1.1 methods to be added by a separate |
| specification). |  | specification). |
| B.6. Since draft-ietf-httpbis-p2-semantics-04 |  | C.6. Since draft-ietf-httpbis-p2-semantics-04 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is |
| updated by RFC 5322" |  | updated by RFC 5322" |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Use "/" instead of "|" for alternatives. |  | o Use "/" instead of "|" for alternatives. |
| o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |  | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
| whitespace ("OWS") and required whitespace ("RWS"). |  | whitespace ("OWS") and required whitespace ("RWS"). |
| o Rewrite ABNFs to spell out whitespace rules, factor out header |  | o Rewrite ABNFs to spell out whitespace rules, factor out header |
| value format definitions. |  | value format definitions. |
| skipping to change at page 47, line 15 |  | skipping to change at page 49, line 48 |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Use "/" instead of "|" for alternatives. |  | o Use "/" instead of "|" for alternatives. |
| o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |  | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
| whitespace ("OWS") and required whitespace ("RWS"). |  | whitespace ("OWS") and required whitespace ("RWS"). |
| o Rewrite ABNFs to spell out whitespace rules, factor out header |  | o Rewrite ABNFs to spell out whitespace rules, factor out header |
| value format definitions. |  | value format definitions. |
|  |  | C.7. Since draft-ietf-httpbis-p2-semantics-05 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase |
|  |  | BNF" |
|  |  | Final work on ABNF conversion |
|  |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
|  |  | o Add appendix containing collected and expanded ABNF, reorganize |
|  |  | ABNF introduction. |
| Index |  | Index |
| 1 |  | 1 |
| 100 Continue (status code) 19 |  | 100 Continue (status code) 20 |
| 101 Switching Protocols (status code) 20 |  | 101 Switching Protocols (status code) 20 |
| 2 |  | 2 |
| 200 OK (status code) 20 |  | 200 OK (status code) 20 |
| 201 Created (status code) 20 |  | 201 Created (status code) 21 |
| 202 Accepted (status code) 21 |  | 202 Accepted (status code) 21 |
| 203 Non-Authoritative Information (status code) 21 |  | 203 Non-Authoritative Information (status code) 21 |
| 204 No Content (status code) 21 |  | 204 No Content (status code) 22 |
| 205 Reset Content (status code) 22 |  | 205 Reset Content (status code) 22 |
| 206 Partial Content (status code) 22 |  | 206 Partial Content (status code) 22 |
| 3 |  | 3 |
| 300 Multiple Choices (status code) 22 |  | 300 Multiple Choices (status code) 23 |
| 301 Moved Permanently (status code) 23 |  | 301 Moved Permanently (status code) 23 |
| 302 Found (status code) 23 |  | 302 Found (status code) 24 |
| 303 See Other (status code) 24 |  | 303 See Other (status code) 24 |
| 304 Not Modified (status code) 25 |  | 304 Not Modified (status code) 25 |
| 305 Use Proxy (status code) 25 |  | 305 Use Proxy (status code) 25 |
| 306 (Unused) (status code) 25 |  | 306 (Unused) (status code) 25 |
| 307 Temporary Redirect (status code) 25 |  | 307 Temporary Redirect (status code) 25 |
| 4 |  | 4 |
| 400 Bad Request (status code) 26 |  | 400 Bad Request (status code) 26 |
| 401 Unauthorized (status code) 26 |  | 401 Unauthorized (status code) 26 |
| 402 Payment Required (status code) 26 |  | 402 Payment Required (status code) 26 |
| 403 Forbidden (status code) 26 |  | 403 Forbidden (status code) 26 |
| 404 Not Found (status code) 26 |  | 404 Not Found (status code) 27 |
| 405 Method Not Allowed (status code) 27 |  | 405 Method Not Allowed (status code) 27 |
| 406 Not Acceptable (status code) 27 |  | 406 Not Acceptable (status code) 27 |
| 407 Proxy Authentication Required (status code) 27 |  | 407 Proxy Authentication Required (status code) 27 |
| 408 Request Timeout (status code) 27 |  | 408 Request Timeout (status code) 28 |
| 409 Conflict (status code) 27 |  | 409 Conflict (status code) 28 |
| 410 Gone (status code) 28 |  | 410 Gone (status code) 28 |
| 411 Length Required (status code) 28 |  | 411 Length Required (status code) 29 |
| 412 Precondition Failed (status code) 28 |  | 412 Precondition Failed (status code) 29 |
| 413 Request Entity Too Large (status code) 29 |  | 413 Request Entity Too Large (status code) 29 |
| 414 Request-URI Too Long (status code) 29 |  | 414 URI Too Long (status code) 29 |
| 415 Unsupported Media Type (status code) 29 |  | 415 Unsupported Media Type (status code) 29 |
| 416 Requested Range Not Satisfiable (status code) 29 |  | 416 Requested Range Not Satisfiable (status code) 29 |
| 417 Expectation Failed (status code) 29 |  | 417 Expectation Failed (status code) 30 |
| 5 |  | 5 |
| 500 Internal Server Error (status code) 30 |  | 500 Internal Server Error (status code) 30 |
| 501 Not Implemented (status code) 30 |  | 501 Not Implemented (status code) 30 |
| 502 Bad Gateway (status code) 30 |  | 502 Bad Gateway (status code) 30 |
| 503 Service Unavailable (status code) 30 |  | 503 Service Unavailable (status code) 30 |
| 504 Gateway Timeout (status code) 30 |  | 504 Gateway Timeout (status code) 31 |
| 505 HTTP Version Not Supported (status code) 31 |  | 505 HTTP Version Not Supported (status code) 31 |
| A |  | A |
| Allow header 31 |  | Allow header 31 |
| C |  | C |
| CONNECT method 19 |  | CONNECT method 19 |
| D |  | D |
| DELETE method 18 |  | DELETE method 18 |
| E |  | E |
| Expect header 31 |  | Expect header 32 |
| F |  | F |
| From header 32 |  | From header 33 |
| G |  | G |
| GET method 15 |  | GET method 15 |
| Grammar |  | Grammar |
| Allow 31 |  | Allow 31 |
| Allow-v 31 |  | Allow-v 31 |
| delta-seconds 35 |  | delta-seconds 35 |
| Expect 32 |  | Expect 32 |
| expect-params 32 |  | expect-params 32 |
| Expect-v 32 |  | Expect-v 32 |
| expectation 32 |  | expectation 32 |
| expectation-extension 32 |  | expectation-extension 32 |
| extension-code 11 |  | extension-code 11 |
| extension-method 8 |  | extension-method 8 |
| From 32 |  | From 33 |
| From-v 32 |  | From-v 33 |
| Location 33 |  | Location 33 |
| Location-v 33 |  | Location-v 33 |
| Max-Forwards 34 |  | Max-Forwards 34 |
| Max-Forwards-v 34 |  | Max-Forwards-v 34 |
| Method 8 |  | Method 8 |
| Reason-Phrase 11 |  | Reason-Phrase 11 |
| Referer 35 |  | Referer 35 |
| Referer-v 35 |  | Referer-v 35 |
| request-header 9 |  | request-header 9 |
| response-header 12 |  | response-header 12 |
| skipping to change at page 49, line 25 |  | skipping to change at page 52, line 23 |
| Server 36 |  | Server 36 |
| Server-v 36 |  | Server-v 36 |
| Status-Code 11 |  | Status-Code 11 |
| User-Agent 36 |  | User-Agent 36 |
| User-Agent-v 36 |  | User-Agent-v 36 |
| H |  | H |
| HEAD method 16 |  | HEAD method 16 |
| Headers |  | Headers |
| Allow 31 |  | Allow 31 |
| Expect 31 |  | Expect 32 |
| From 32 |  | From 33 |
| Location 33 |  | Location 33 |
| Max-Forwards 34 |  | Max-Forwards 34 |
| Referer 34 |  | Referer 35 |
| Retry-After 35 |  | Retry-After 35 |
| Server 35 |  | Server 36 |
| User-Agent 36 |  | User-Agent 36 |
| I |  | I |
| Idempotent Methods 14 |  | Idempotent Methods 14 |
| L |  | L |
| LINK method 43 |  | LINK method 43 |
| Location header 33 |  | Location header 33 |
| M |  | M |
| skipping to change at page 50, line 17 |  | skipping to change at page 53, line 15 |
| O |  | O |
| OPTIONS method 14 |  | OPTIONS method 14 |
| P |  | P |
| PATCH method 43 |  | PATCH method 43 |
| POST method 16 |  | POST method 16 |
| PUT method 17 |  | PUT method 17 |
| R |  | R |
| Referer header 34 |  | Referer header 35 |
| Retry-After header 35 |  | Retry-After header 35 |
| S |  | S |
| Safe Methods 13 |  | Safe Methods 13 |
| Server header 35 |  | Server header 36 |
| Status Codes |  | Status Codes |
| 100 Continue 19 |  | 100 Continue 20 |
| 101 Switching Protocols 20 |  | 101 Switching Protocols 20 |
| 200 OK 20 |  | 200 OK 20 |
| 201 Created 20 |  | 201 Created 21 |
| 202 Accepted 21 |  | 202 Accepted 21 |
| 203 Non-Authoritative Information 21 |  | 203 Non-Authoritative Information 21 |
| 204 No Content 21 |  | 204 No Content 22 |
| 205 Reset Content 22 |  | 205 Reset Content 22 |
| 206 Partial Content 22 |  | 206 Partial Content 22 |
| 300 Multiple Choices 22 |  | 300 Multiple Choices 23 |
| 301 Moved Permanently 23 |  | 301 Moved Permanently 23 |
| 302 Found 23 |  | 302 Found 24 |
| 303 See Other 24 |  | 303 See Other 24 |
| 304 Not Modified 25 |  | 304 Not Modified 25 |
| 305 Use Proxy 25 |  | 305 Use Proxy 25 |
| 306 (Unused) 25 |  | 306 (Unused) 25 |
| 307 Temporary Redirect 25 |  | 307 Temporary Redirect 25 |
| 400 Bad Request 26 |  | 400 Bad Request 26 |
| 401 Unauthorized 26 |  | 401 Unauthorized 26 |
| 402 Payment Required 26 |  | 402 Payment Required 26 |
| 403 Forbidden 26 |  | 403 Forbidden 26 |
| 404 Not Found 26 |  | 404 Not Found 27 |
| 405 Method Not Allowed 27 |  | 405 Method Not Allowed 27 |
| 406 Not Acceptable 27 |  | 406 Not Acceptable 27 |
| 407 Proxy Authentication Required 27 |  | 407 Proxy Authentication Required 27 |
| 408 Request Timeout 27 |  | 408 Request Timeout 28 |
| 409 Conflict 27 |  | 409 Conflict 28 |
| 410 Gone 28 |  | 410 Gone 28 |
| 411 Length Required 28 |  | 411 Length Required 29 |
| 412 Precondition Failed 28 |  | 412 Precondition Failed 29 |
| 413 Request Entity Too Large 29 |  | 413 Request Entity Too Large 29 |
| 414 Request-URI Too Long 29 |  | 414 URI Too Long 29 |
| 415 Unsupported Media Type 29 |  | 415 Unsupported Media Type 29 |
| 416 Requested Range Not Satisfiable 29 |  | 416 Requested Range Not Satisfiable 29 |
| 417 Expectation Failed 29 |  | 417 Expectation Failed 30 |
| 500 Internal Server Error 30 |  | 500 Internal Server Error 30 |
| 501 Not Implemented 30 |  | 501 Not Implemented 30 |
| 502 Bad Gateway 30 |  | 502 Bad Gateway 30 |
| 503 Service Unavailable 30 |  | 503 Service Unavailable 30 |
| 504 Gateway Timeout 30 |  | 504 Gateway Timeout 31 |
| 505 HTTP Version Not Supported 31 |  | 505 HTTP Version Not Supported 31 |
| T |  | T |
| TRACE method 18 |  | TRACE method 18 |
| U |  | U |
| UNLINK method 43 |  | UNLINK method 43 |
| User-Agent header 36 |  | User-Agent header 36 |
| Authors' Addresses |  | Authors' Addresses |
| skipping to change at page 54, line 4 |  | skipping to change at line 2528 |
| Julian F. Reschke (editor) |  | Julian F. Reschke (editor) |
| greenbytes GmbH |  | greenbytes GmbH |
| Hafenweg 16 |  | Hafenweg 16 |
| Muenster, NW 48155 |  | Muenster, NW 48155 |
| Germany |  | Germany |
| Phone: +49 251 2807760 |  | Phone: +49 251 2807760 |
| Fax: +49 251 2807761 |  | Fax: +49 251 2807761 |
| Email: julian.reschke@greenbytes.de |  | Email: julian.reschke@greenbytes.de |
| URI: http://greenbytes.de/tech/webdav/ |  | URI: http://greenbytes.de/tech/webdav/ |
| Full Copyright Statement |  |  |
| Copyright (C) The IETF Trust (2008). |  |  |
| This document is subject to the rights, licenses and restrictions |  |  |
| contained in BCP 78, and except as set forth therein, the authors |  |  |
| retain all their rights. |  |  |
| This document and the information contained herein are provided on an |  |  |
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |  |  |
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |  |  |
| THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |  |  |
| OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |  |  |
| THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED |  |  |
| WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |  |  |
| Intellectual Property |  |  |
| The IETF takes no position regarding the validity or scope of any |  |  |
| Intellectual Property Rights or other rights that might be claimed to |  |  |
| pertain to the implementation or use of the technology described in |  |  |
| this document or the extent to which any license under such rights |  |  |
| might or might not be available; nor does it represent that it has |  |  |
| made any independent effort to identify any such rights. Information |  |  |
| on the procedures with respect to rights in RFC documents can be |  |  |
| found in BCP 78 and BCP 79. |  |  |
| Copies of IPR disclosures made to the IETF Secretariat and any |  |  |
| assurances of licenses to be made available, or the result of an |  |  |
| attempt made to obtain a general license or permission for the use of |  |  |
| such proprietary rights by implementers or users of this |  |  |
| specification can be obtained from the IETF on-line IPR repository at |  |  |
| http://www.ietf.org/ipr. |  |  |
| The IETF invites any interested party to bring to its attention any |  |  |
| copyrights, patents or patent applications, or other proprietary |  |  |
| rights that may cover technology that may be required to implement |  |  |
| this standard. Please address the information to the IETF at |  |  |
| ietf-ipr@ietf.org. |  |  |
End of changes. 237 change blocks.
| 517 lines changed or deleted |  | 689 lines changed or added |
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/