| draft-ietf-httpbis-p2-semantics-12.txt |  | draft-ietf-httpbis-p2-semantics-13.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Adobe |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Updates: 2817 (if approved) Alcatel-Lucent |  | Updates: 2817 (if approved) Alcatel-Lucent |
| Intended status: Standards Track J. Mogul |  | Intended status: Standards Track J. Mogul |
| Expires: April 28, 2011 HP |  | Expires: September 15, 2011 HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe Systems |  | Adobe |
| 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 |
| October 25, 2010 |  | March 14, 2011 |
| HTTP/1.1, part 2: Message Semantics |  | HTTP/1.1, part 2: Message Semantics |
| draft-ietf-httpbis-p2-semantics-12 |  | draft-ietf-httpbis-p2-semantics-13 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypermedia information |  | protocol for distributed, collaborative, hypermedia information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| information initiative since 1990. This document is Part 2 of the |  | information initiative since 1990. This document is Part 2 of the |
| seven-part specification that defines the protocol referred to as |  | seven-part specification that defines the protocol referred to as |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines |
| the semantics of HTTP messages as expressed by request methods, |  | the semantics of HTTP messages as expressed by request methods, |
| request-header fields, response status codes, and response-header |  | request header fields, response status codes, and response header |
| fields. |  | fields. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| 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/3> and related |  | at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix C.13. |  | The changes in this draft are summarized in Appendix C.14. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| This Internet-Draft will expire on April 28, 2011. |  | This Internet-Draft will expire on September 15, 2011. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2010 IETF Trust and the persons identified as the |  | Copyright (c) 2011 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| carefully, as they describe your rights and restrictions with respect |  | carefully, as they describe your rights and restrictions with respect |
| to this document. Code Components extracted from this document must |  | to this document. Code Components extracted from this document must |
| include Simplified BSD License text as described in Section 4.e of |  | include Simplified BSD License text as described in Section 4.e of |
| the Trust Legal Provisions and are provided without warranty as |  | the Trust Legal Provisions and are provided without warranty as |
| skipping to change at page 3, line 6 |  | skipping to change at page 3, line 6 |
| than English. |  | than English. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 |  | 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 |
| 1.2.2. ABNF Rules defined in other Parts of the |  | 1.2.2. ABNF Rules defined in other Parts of the |
| Specification . . . . . . . . . . . . . . . . . . . . 7 |  | Specification . . . . . . . . . . . . . . . . . . . . 7 |
| 2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 |  | 2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 8 |  | 2.1. Overview of Methods . . . . . . . . . . . . . . . . . . . 8 |
| 2.1.1. Considerations for New Methods . . . . . . . . . . . . 9 |  | 2.2. Method Registry . . . . . . . . . . . . . . . . . . . . . 8 |
|  |  | 2.2.1. Considerations for New Methods . . . . . . . . . . . . 8 |
| 3. Request Header Fields . . . . . . . . . . . . . . . . . . . . 9 |  | 3. Request Header Fields . . . . . . . . . . . . . . . . . . . . 9 |
| 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 10 |  | 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 10 |
| 4.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 12 |  | 4.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 10 |
| 4.1.1. Considerations for New Status Codes . . . . . . . . . 12 |  | 4.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 12 |
|  |  | 4.2.1. Considerations for New Status Codes . . . . . . . . . 12 |
| 5. Response Header Fields . . . . . . . . . . . . . . . . . . . . 13 |  | 5. Response Header Fields . . . . . . . . . . . . . . . . . . . . 13 |
| 6. Representation . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 6. Representation . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 6.1. Identifying the Resource Associated with a |  | 6.1. Identifying the Resource Associated with a |
| Representation . . . . . . . . . . . . . . . . . . . . . . 14 |  | Representation . . . . . . . . . . . . . . . . . . . . . . 13 |
| 7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 14 |  | 7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 14 |
| 7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 15 |  | 7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 14 |
| 7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 15 |  | 7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 14 |
| 7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 15 |  | 7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 15 |
| 7.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 15 |  | 7.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 15 |
| 7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 21 |
| 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 21 |
| 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 20 |  | 7.9.1. Establishing a Tunnel with CONNECT . . . . . . . . . . 22 |
| 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 20 |  | 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 22 |
| 8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 21 |  | 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 22 |
| 8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 21 |  | 8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 23 |
| 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 21 |  | 8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 23 |
| 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 22 |  | 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 23 |
| 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 22 |  | 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 23 |
| 8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 22 |  | 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 24 |
| 8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 23 |  | 8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 24 |
| 8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 23 |  | 8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 25 |
| 8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 23 |  | 8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 25 |
| 8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 24 |  | 8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 25 |
| 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 24 |  | 8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 26 |
| 8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 24 |  | 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 26 |
| 8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 25 |  | 8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 26 |
| 8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 25 |  | 8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 27 |
| 8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 26 |  | 8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 27 |
| 8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 26 |  | 8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 28 |
| 8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 27 |  | 8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 28 |
| 8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 27 |  | 8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 29 |
| 8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 27 |  | 8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 29 |
| 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 27 |  | 8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 29 |
| 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 28 |  | 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 29 |
| 8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 28 |  | 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 30 |
| 8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 28 |  | 8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 30 |
| 8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 28 |  | 8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 30 |
| 8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 28 |  | 8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 30 |
| 8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 28 |  | 8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 30 |
| 8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 28 |  | 8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 30 |
| 8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 29 |  | 8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 30 |
| 8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 29 |  | 8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 31 |
| 8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 29 |  | 8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 31 |
| 8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 30 |  | 8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 31 |
| 8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 30 |  | 8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 30 |  | 8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 32 |
| 8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 30 |  | 8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 32 |
| 8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 31 |  | 8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 32 |
| 8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 31 |  | 8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 33 |
| 8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 31 |  | 8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 33 |
| 8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 31 |  | 8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 33 |
| 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 31 |  | 8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 33 |
| 8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 32 |  | 8.4.19. 426 Upgrade Required . . . . . . . . . . . . . . . . . 33 |
| 8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 32 |  | 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 34 |
| 8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 32 |  | 8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 34 |
| 8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 32 |  | 8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 34 |
| 8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 32 |  | 8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 34 |
| 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 32 |  | 8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 34 |
| 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 33 |  | 8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 35 |
| 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 35 |
| 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 35 |
| 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 |  | 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 35 |
| 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 35 |  | 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 36 |
| 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 36 |  | 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 |
| 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 36 |  | 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 37 |
| 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 37 |  | 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 38 |
| 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 37 |  | 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 39 |
| 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 38 |  | 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 39 |
| 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 |  | 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 40 |
| 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 39 |  | 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 40 |
| 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 39 |  | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 |
| 10.3. Header Field Registration . . . . . . . . . . . . . . . . 40 |  | 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 41 |
| 11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 |  | 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 42 |
| 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 41 |  | 10.3. Header Field Registration . . . . . . . . . . . . . . . . 43 |
| 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 42 |  | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44 |
| 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 43 |  | 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 44 |
| 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 |  | 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 45 |
| 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 |  | 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 46 |
| 13.1. Normative References . . . . . . . . . . . . . . . . . . . 43 |  | 11.4. Security Considerations for CONNECT . . . . . . . . . . . 46 |
| 13.2. Informative References . . . . . . . . . . . . . . . . . . 44 |  | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 |
| Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 44 |  | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 45 |  | 13.1. Normative References . . . . . . . . . . . . . . . . . . . 46 |
|  |  | 13.2. Informative References . . . . . . . . . . . . . . . . . . 47 |
|  |  | Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 48 |
|  |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 49 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 48 |  | publication) . . . . . . . . . . . . . . . . . . . . 50 |
| C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 48 |  | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 50 |
| C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 48 |  | C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 50 |
| C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 49 |  | C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 51 |
| C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 49 |  | C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 52 |
| C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 50 |  | C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 52 |
| C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 50 |  | C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 53 |
| C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 51 |  | C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 53 |
| C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 51 |  | C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 53 |
| C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 51 |  | C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 54 |
| C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 52 |  | C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 54 |
| C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 52 |  | C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 55 |
| C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 52 |  | C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 55 |
| C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 53 |  | C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 55 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 |  | C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 56 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 |
| 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 |
| the various response messages that might be expected as a result of |  | the various response messages that might be expected as a result of |
| applying that method to the target resource. |  | applying that method to the target resource. |
| This document is currently disorganized in order to minimize the |  | This document is currently disorganized in order to minimize the |
| changes between drafts and enable reviewers to see the smaller errata |  | changes between drafts and enable reviewers to see the smaller errata |
| changes. A future draft will reorganize the sections to better |  | changes. A future draft will reorganize the sections to better |
| reflect the content. In particular, the sections will be ordered |  | reflect the content. In particular, the sections will be ordered |
| according to the typical processing of an HTTP request message (after |  | according to the typical processing of an HTTP request message (after |
| message parsing): resource mapping, general header fields, methods, |  | message parsing): resource mapping, methods, request modifying header |
| request modifiers, response status, and resource metadata. The |  | fields, response status, status modifying header fields, and resource |
| current mess reflects how widely dispersed these topics and |  | metadata. The current mess reflects how widely dispersed these |
| associated requirements had become in [RFC2616]. |  | topics and associated requirements had become in [RFC2616]. |
| 1.1. Requirements |  | 1.1. Requirements |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in [RFC2119]. |  | document are to be interpreted as described in [RFC2119]. |
| 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 |
| skipping to change at page 7, line 23 |  | skipping to change at page 7, line 23 |
| OWS = <OWS, 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> |  | RWS = <RWS, defined in [Part1], Section 1.2.2> |
| obs-text = <obs-text, 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 |  | 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 2.6> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |
| comment = <comment, defined in [Part1], Section 3.2> |  | comment = <comment, defined in [Part1], Section 3.2> |
| Host = <Host, defined in [Part1], Section 2.6> |  |  |
| HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |  | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |
| partial-URI = <partial-URI, defined in [Part1], Section 2.6> |  | partial-URI = <partial-URI, defined in [Part1], Section 2.6> |
| product = <product, defined in [Part1], Section 6.3> |  | product = <product, defined in [Part1], Section 6.3> |
| TE = <TE, defined in [Part1], Section 9.5> |  |  |
| URI-reference = <URI-reference, defined in [Part1], Section 2.6> |  | URI-reference = <URI-reference, defined in [Part1], Section 2.6> |
| Accept = <Accept, defined in [Part3], Section 6.1> |  |  |
| Accept-Charset = |  |  |
| <Accept-Charset, defined in [Part3], Section 6.2> |  |  |
| Accept-Encoding = |  |  |
| <Accept-Encoding, defined in [Part3], Section 6.3> |  |  |
| Accept-Language = |  |  |
| <Accept-Language, defined in [Part3], Section 6.4> |  |  |
| ETag = <ETag, defined in [Part4], Section 6.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-Unmodified-Since = |  |  |
| <If-Unmodified-Since, defined in [Part4], Section 6.5> |  |  |
| Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 5.1> |  |  |
| If-Range = <If-Range, defined in [Part5], Section 5.3> |  |  |
| Range = <Range, defined in [Part5], Section 5.4> |  |  |
| Age = <Age, defined in [Part6], Section 3.1> |  |  |
| Vary = <Vary, defined in [Part6], Section 3.5> |  |  |
| Authorization = <Authorization, defined in [Part7], Section 4.1> |  |  |
| Proxy-Authenticate = |  |  |
| <Proxy-Authenticate, defined in [Part7], Section 4.2> |  |  |
| Proxy-Authorization = |  |  |
| <Proxy-Authorization, defined in [Part7], Section 4.3> |  |  |
| WWW-Authenticate = |  |  |
| <WWW-Authenticate, defined in [Part7], Section 4.4> |  |  |
| 2. Method |  | 2. Method |
| The Method token indicates the method to be performed on the target |  | The Method token indicates the request method to be performed on the |
| resource (Section 4.3 of [Part1]). The method is case-sensitive. |  | target resource (Section 4.3 of [Part1]). The method is case- |
|  |  | sensitive. |
| Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 7.2 |  | Method = token |
| / %x47.45.54 ; "GET", Section 7.3 |  |  |
| / %x48.45.41.44 ; "HEAD", Section 7.4 |  |  |
| / %x50.4F.53.54 ; "POST", Section 7.5 |  |  |
| / %x50.55.54 ; "PUT", Section 7.6 |  |  |
| / %x44.45.4C.45.54.45 ; "DELETE", Section 7.7 |  |  |
| / %x54.52.41.43.45 ; "TRACE", Section 7.8 |  |  |
| / %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 7.9 |  |  |
| / extension-method |  |  |
| 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 9.1). The status code of the response |  | Allow header field (Section 9.1). The status 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 respond with the status code 405 (Method Not |  | An origin server SHOULD respond with 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 resource, and 501 (Not Implemented) if the method is |  | for the resource, and 501 (Not Implemented) if the method is |
| unrecognized or not implemented by the origin server. The methods |  | 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 7. |  | those specified in Section 7. |
| 2.1. Method Registry |  | 2.1. Overview of Methods |
|  |  | The methods listed below are defined in Section 7. |
|  |  | +-------------+---------------+ |
|  |  | | Method Name | Defined in... | |
|  |  | +-------------+---------------+ |
|  |  | | OPTIONS | Section 7.2 | |
|  |  | | GET | Section 7.3 | |
|  |  | | HEAD | Section 7.4 | |
|  |  | | POST | Section 7.5 | |
|  |  | | PUT | Section 7.6 | |
|  |  | | DELETE | Section 7.7 | |
|  |  | | TRACE | Section 7.8 | |
|  |  | | CONNECT | Section 7.9 | |
|  |  | +-------------+---------------+ |
|  |  | Note that this list is not exhaustive -- it does not include request |
|  |  | methods defined in other specifications. |
|  |  | 2.2. 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 2) |  | o Method Name (see Section 2) |
| o Safe ("yes" or "no", see Section 7.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). |  | ([RFC5226], Section 4.1). |
| 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>. |
| 2.1.1. Considerations for New Methods |  | 2.2.1. Considerations for New Methods |
| When it is necessary to express new semantics for a HTTP request that |  | When it is necessary to express new semantics for a HTTP request that |
| aren't specific to a single application or media type, and currently |  | aren't specific to a single application or media type, and currently |
| defined methods are inadequate, it may be appropriate to register a |  | defined methods are inadequate, it may be appropriate to register a |
| new method. |  | new method. |
| HTTP methods are generic; that is, they are potentially applicable to |  | HTTP methods are generic; that is, they are potentially applicable to |
| any resource, not just one particular media type, "type" of resource, |  | any resource, not just one particular media type, "type" of resource, |
| or application. As such, it is preferred that new HTTP methods be |  | or application. As such, it is preferred that new HTTP methods be |
| registered in a document that isn't specific to a single application, |  | registered in a document that isn't specific to a single application, |
| skipping to change at page 9, line 46 |  | skipping to change at page 9, line 24 |
| New method definitions need to indicate whether they are safe |  | New method definitions need to indicate whether they are safe |
| (Section 7.1.1) and whether they are idempotent (Section 7.1.2). |  | (Section 7.1.1) and whether they are idempotent (Section 7.1.2). |
| They also need to state whether they can be cached ([Part6]); in |  | They also need to state whether they can be cached ([Part6]); in |
| particular what conditions a cache may store the response, and under |  | particular what conditions a cache may store the response, and under |
| what conditions such a stored response may be used to satisfy a |  | what conditions such a stored response may be used to satisfy a |
| subsequent request. |  | subsequent request. |
| 3. 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 |  | +---------------------+------------------------+ |
| / Accept-Charset ; [Part3], Section 6.2 |  | | Header Field Name | Defined in... | |
| / Accept-Encoding ; [Part3], Section 6.3 |  | +---------------------+------------------------+ |
| / Accept-Language ; [Part3], Section 6.4 |  | | Accept | Section 6.1 of [Part3] | |
| / Authorization ; [Part7], Section 4.1 |  | | Accept-Charset | Section 6.2 of [Part3] | |
| / Expect ; Section 9.2 |  | | Accept-Encoding | Section 6.3 of [Part3] | |
| / From ; Section 9.3 |  | | Accept-Language | Section 6.4 of [Part3] | |
| / Host ; [Part1], Section 9.4 |  | | Authorization | Section 4.1 of [Part7] | |
| / If-Match ; [Part4], Section 6.2 |  | | Expect | Section 9.2 | |
| / If-Modified-Since ; [Part4], Section 6.3 |  | | From | Section 9.3 | |
| / If-None-Match ; [Part4], Section 6.4 |  | | Host | Section 9.4 of [Part1] | |
| / If-Range ; [Part5], Section 5.3 |  | | If-Match | Section 6.2 of [Part4] | |
| / If-Unmodified-Since ; [Part4], Section 6.5 |  | | If-Modified-Since | Section 6.3 of [Part4] | |
| / Max-Forwards ; Section 9.5 |  | | If-None-Match | Section 6.4 of [Part4] | |
| / Proxy-Authorization ; [Part7], Section 4.3 |  | | If-Range | Section 5.3 of [Part5] | |
| / Range ; [Part5], Section 5.4 |  | | If-Unmodified-Since | Section 6.5 of [Part4] | |
| / Referer ; Section 9.6 |  | | Max-Forwards | Section 9.5 | |
| / TE ; [Part1], Section 9.5 |  | | Proxy-Authorization | Section 4.3 of [Part7] | |
| / User-Agent ; Section 9.9 |  | | Range | Section 5.4 of [Part5] | |
|  |  | | Referer | Section 9.6 | |
| Request-header field names can be extended reliably only in |  | | TE | Section 9.5 of [Part1] | |
| combination with a change in the protocol version. However, new or |  | | User-Agent | Section 9.9 | |
| experimental header fields MAY be given the semantics of request- |  | +---------------------+------------------------+ |
| header fields if all parties in the communication recognize them to |  |  |
| be request-header fields. |  |  |
| 4. 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. |
| listed below are defined in Section 8, Section 3 of [Part4], Section |  |  |
| 3 of [Part5], and Section 3 of [Part7]. |  |  |
| The Reason-Phrase is intended to give a short textual description of |  | The Reason-Phrase is intended to give a short textual description of |
| the Status-Code. The Status-Code is intended for use by automata and |  | the Status-Code and is intended for a human user. The client does |
| the Reason-Phrase is intended for the human user. The client is not |  | not need to examine or display the Reason-Phrase. |
| required to examine or display the Reason-Phrase. |  |  |
| The individual values of the numeric status codes defined for |  |  |
| HTTP/1.1, and an example set of corresponding Reason-Phrase values, |  |  |
| are presented below. The reason phrases listed here are only |  |  |
| recommendations -- they MAY be replaced by local equivalents without |  |  |
| affecting the protocol. |  |  |
| Status-Code = |  |  |
| "100" ; Section 8.1.1: Continue |  |  |
| / "101" ; Section 8.1.2: Switching Protocols |  |  |
| / "200" ; Section 8.2.1: OK |  |  |
| / "201" ; Section 8.2.2: Created |  |  |
| / "202" ; Section 8.2.3: Accepted |  |  |
| / "203" ; Section 8.2.4: Non-Authoritative Information |  |  |
| / "204" ; Section 8.2.5: No Content |  |  |
| / "205" ; Section 8.2.6: Reset Content |  |  |
| / "206" ; [Part5], Section 3.1: Partial Content |  |  |
| / "300" ; Section 8.3.1: Multiple Choices |  |  |
| / "301" ; Section 8.3.2: Moved Permanently |  |  |
| / "302" ; Section 8.3.3: Found |  |  |
| / "303" ; Section 8.3.4: See Other |  |  |
| / "304" ; [Part4], Section 3.1: Not Modified |  |  |
| / "305" ; Section 8.3.6: Use Proxy |  |  |
| / "307" ; Section 8.3.8: Temporary Redirect |  |  |
| / "400" ; Section 8.4.1: Bad Request |  |  |
| / "401" ; [Part7], Section 3.1: Unauthorized |  |  |
| / "402" ; Section 8.4.3: Payment Required |  |  |
| / "403" ; Section 8.4.4: Forbidden |  |  |
| / "404" ; Section 8.4.5: Not Found |  |  |
| / "405" ; Section 8.4.6: Method Not Allowed |  |  |
| / "406" ; Section 8.4.7: Not Acceptable |  |  |
| / "407" ; [Part7], Section 3.2: Proxy Authentication Required |  |  |
| / "408" ; Section 8.4.9: Request Time-out |  |  |
| / "409" ; Section 8.4.10: Conflict |  |  |
| / "410" ; Section 8.4.11: Gone |  |  |
| / "411" ; Section 8.4.12: Length Required |  |  |
| / "412" ; [Part4], Section 3.2: Precondition Failed |  |  |
| / "413" ; Section 8.4.14: Request Entity Too Large |  |  |
| / "414" ; Section 8.4.15: URI Too Long |  |  |
| / "415" ; Section 8.4.16: Unsupported Media Type |  |  |
| / "416" ; [Part5], Section 3.2: Requested range not satisfiable |  |  |
| / "417" ; Section 8.4.18: Expectation Failed |  |  |
| / "500" ; Section 8.5.1: Internal Server Error |  |  |
| / "501" ; Section 8.5.2: Not Implemented |  |  |
| / "502" ; Section 8.5.3: Bad Gateway |  |  |
| / "503" ; Section 8.5.4: Service Unavailable |  |  |
| / "504" ; Section 8.5.5: Gateway Time-out |  |  |
| / "505" ; Section 8.5.6: HTTP Version not supported |  |  |
| / extension-code |  |  |
| extension-code = 3DIGIT |  | Status-Code = 3DIGIT |
| Reason-Phrase = *( WSP / VCHAR / obs-text ) |  | 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 representation |  | cases, user agents SHOULD present to the user the representation |
| enclosed with the response, since that representation is likely to |  | enclosed with the response, since that representation is likely to |
| include human-readable information which will explain the unusual |  | include human-readable information which will explain the unusual |
| status. |  | status. |
| 4.1. Status Code Registry |  | 4.1. Overview of Status Codes |
|  |  | The status codes listed below are defined in Section 8 of this |
|  |  | specification, Section 3 of [Part4], Section 3 of [Part5], and |
|  |  | Section 3 of [Part7]. The reason phrases listed here are only |
|  |  | recommendations -- they can be replaced by local equivalents without |
|  |  | affecting the protocol. |
|  |  | +-------------+------------------------------+----------------------+ |
|  |  | | Status-Code | Reason-Phrase | Defined in... | |
|  |  | +-------------+------------------------------+----------------------+ |
|  |  | | 100 | Continue | Section 8.1.1 | |
|  |  | | 101 | Switching Protocols | Section 8.1.2 | |
|  |  | | 200 | OK | Section 8.2.1 | |
|  |  | | 201 | Created | Section 8.2.2 | |
|  |  | | 202 | Accepted | Section 8.2.3 | |
|  |  | | 203 | Non-Authoritative | Section 8.2.4 | |
|  |  | | | Information | | |
|  |  | | 204 | No Content | Section 8.2.5 | |
|  |  | | 205 | Reset Content | Section 8.2.6 | |
|  |  | | 206 | Partial Content | Section 3.1 of | |
|  |  | | | | [Part5] | |
|  |  | | 300 | Multiple Choices | Section 8.3.1 | |
|  |  | | 301 | Moved Permanently | Section 8.3.2 | |
|  |  | | 302 | Found | Section 8.3.3 | |
|  |  | | 303 | See Other | Section 8.3.4 | |
|  |  | | 304 | Not Modified | Section 3.1 of | |
|  |  | | | | [Part4] | |
|  |  | | 305 | Use Proxy | Section 8.3.6 | |
|  |  | | 307 | Temporary Redirect | Section 8.3.8 | |
|  |  | | 400 | Bad Request | Section 8.4.1 | |
|  |  | | 401 | Unauthorized | Section 3.1 of | |
|  |  | | | | [Part7] | |
|  |  | | 402 | Payment Required | Section 8.4.3 | |
|  |  | | 403 | Forbidden | Section 8.4.4 | |
|  |  | | 404 | Not Found | Section 8.4.5 | |
|  |  | | 405 | Method Not Allowed | Section 8.4.6 | |
|  |  | | 406 | Not Acceptable | Section 8.4.7 | |
|  |  | | 407 | Proxy Authentication | Section 3.2 of | |
|  |  | | | Required | [Part7] | |
|  |  | | 408 | Request Time-out | Section 8.4.9 | |
|  |  | | 409 | Conflict | Section 8.4.10 | |
|  |  | | 410 | Gone | Section 8.4.11 | |
|  |  | | 411 | Length Required | Section 8.4.12 | |
|  |  | | 412 | Precondition Failed | Section 3.2 of | |
|  |  | | | | [Part4] | |
|  |  | | 413 | Request Entity Too Large | Section 8.4.14 | |
|  |  | | 414 | URI Too Long | Section 8.4.15 | |
|  |  | | 415 | Unsupported Media Type | Section 8.4.16 | |
|  |  | | 416 | Requested range not | Section 3.2 of | |
|  |  | | | satisfiable | [Part5] | |
|  |  | | 417 | Expectation Failed | Section 8.4.18 | |
|  |  | | 426 | Upgrade Required | Section 8.4.19 | |
|  |  | | 500 | Internal Server Error | Section 8.5.1 | |
|  |  | | 501 | Not Implemented | Section 8.5.2 | |
|  |  | | 502 | Bad Gateway | Section 8.5.3 | |
|  |  | | 503 | Service Unavailable | Section 8.5.4 | |
|  |  | | 504 | Gateway Time-out | Section 8.5.5 | |
|  |  | | 505 | HTTP Version not supported | Section 8.5.6 | |
|  |  | +-------------+------------------------------+----------------------+ |
|  |  | Note that this list is not exhaustive -- it does not include |
|  |  | extension status codes defined in other specifications. |
|  |  | 4.2. 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). |  | ([RFC5226], Section 4.1). |
| 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>. |
| 4.1.1. Considerations for New Status Codes |  | 4.2.1. Considerations for New Status Codes |
| When it is necessary to express new semantics for a HTTP response |  | When it is necessary to express new semantics for a HTTP response |
| that aren't specific to a single application or media type, and |  | that aren't specific to a single application or media type, and |
| currently defined status codes are inadequate, a new status code can |  | currently defined status codes are inadequate, a new status code can |
| be registered. |  | be registered. |
| HTTP status codes are generic; that is, they are potentially |  | HTTP status codes are generic; that is, they are potentially |
| applicable to any resource, not just one particular media type, |  | applicable to any resource, not just one particular media type, |
| "type" of resource, or application. As such, it is preferred that |  | "type" of resource, or application. As such, it is preferred that |
| new HTTP status codes be registered in a document that isn't specific |  | new HTTP status codes be registered in a document that isn't specific |
| skipping to change at page 13, line 14 |  | skipping to change at page 13, line 9 |
| header(s). |  | header(s). |
| Likewise, their definitions can specify that caches are allowed to |  | Likewise, their definitions can specify that caches are allowed to |
| use heuristics to determine their freshness (see [Part6]; by default, |  | use heuristics to determine their freshness (see [Part6]; by default, |
| it is not allowed), and can define how to determine the resource |  | it is not allowed), and can define how to determine the resource |
| which they carry a representation for (see Section 6.1; by default, |  | which they carry a representation for (see Section 6.1; by default, |
| it is anonymous). |  | it is anonymous). |
| 5. 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 target resource (Section 4.3 of [Part1]). |  | about further access to the target resource (Section 4.3 of [Part1]). |
| response-header = Accept-Ranges ; [Part5], Section 5.1 |  | +--------------------+------------------------+ |
| / Age ; [Part6], Section 3.1 |  | | Header Field Name | Defined in... | |
| / Allow ; Section 9.1 |  | +--------------------+------------------------+ |
| / ETag ; [Part4], Section 6.1 |  | | Accept-Ranges | Section 5.1 of [Part5] | |
| / Location ; Section 9.4 |  | | Age | Section 3.1 of [Part6] | |
| / Proxy-Authenticate ; [Part7], Section 4.2 |  | | Allow | Section 9.1 | |
| / Retry-After ; Section 9.7 |  | | ETag | Section 6.1 of [Part4] | |
| / Server ; Section 9.8 |  | | Location | Section 9.4 | |
| / Vary ; [Part6], Section 3.5 |  | | Proxy-Authenticate | Section 4.2 of [Part7] | |
| / WWW-Authenticate ; [Part7], Section 4.4 |  | | Retry-After | Section 9.7 | |
|  |  | | Server | Section 9.8 | |
| Response-header field names can be extended reliably only in |  | | Vary | Section 3.5 of [Part6] | |
| combination with a change in the protocol version. However, new or |  | | WWW-Authenticate | Section 4.4 of [Part7] | |
| experimental header fields MAY be given the semantics of response- |  | +--------------------+------------------------+ |
| header fields if all parties in the communication recognize them to |  |  |
| be response-header fields. |  |  |
| 6. Representation |  | 6. Representation |
| Request and Response messages MAY transfer a representation if not |  | Request and Response messages MAY transfer a representation if not |
| otherwise restricted by the request method or response status code. |  | otherwise restricted by the request method or response status code. |
| A representation consists of metadata (representation header fields) |  | A representation consists of metadata (representation header fields) |
| and data (representation body). When a complete or partial |  | and data (representation body). When a complete or partial |
| representation is enclosed in an HTTP message, it is referred to as |  | representation is enclosed in an HTTP message, it is referred to as |
| the payload of the message. HTTP representations are defined in |  | the payload of the message. HTTP representations are defined in |
| [Part3]. |  | [Part3]. |
| skipping to change at page 14, line 25 |  | skipping to change at page 14, line 17 |
| always the case. To determine the URI of the resource a response is |  | always the case. To determine the URI of the resource a response is |
| associated with, the following rules are used (with the first |  | associated with, the following rules are used (with the first |
| applicable one being selected): |  | applicable one being selected): |
| 1. If the response status code is 200 or 203 and the request method |  | 1. If the response status code is 200 or 203 and the request method |
| was GET, the response payload is a representation of the target |  | was GET, the response payload is a representation of the target |
| resource. |  | resource. |
| 2. If the response status code is 204, 206, or 304 and the request |  | 2. If the response status code is 204, 206, or 304 and the request |
| method was GET or HEAD, the response payload is a partial |  | method was GET or HEAD, the response payload is a partial |
| representation of the target (see Section 2.8 of [Part6]). |  | representation of the target resource (see Section 2.8 of |
|  |  | [Part6]). |
| 3. If the response has a Content-Location header field, and that URI |  | 3. If the response has a Content-Location header field, and that URI |
| is the same as the effective request URI, the response payload is |  | is the same as the effective request URI, the response payload is |
| a representation of the target resource. |  | a representation of the target resource. |
| 4. If the response has a Content-Location header field, and that URI |  | 4. If the response has a Content-Location header field, and that URI |
| is not the same as the effective request URI, then the response |  | is not the same as the effective request URI, then the response |
| asserts that its payload is a representation of the resource |  | asserts that its payload is a representation of the resource |
| identified by the Content-Location URI. However, such an |  | identified by the Content-Location URI. However, such an |
| assertion cannot be trusted unless it can be verified by other |  | assertion cannot be trusted unless it can be verified by other |
| skipping to change at page 14, line 47 |  | skipping to change at page 14, line 40 |
| 5. Otherwise, the response is a representation of an anonymous |  | 5. Otherwise, the response is a representation of an anonymous |
| (i.e., unidentified) resource. |  | (i.e., unidentified) resource. |
| [[TODO-req-uri: The comparison function is going to have to be |  | [[TODO-req-uri: The comparison function is going to have to be |
| defined somewhere, because we already need to compare URIs for things |  | defined somewhere, because we already need to compare URIs for things |
| like cache invalidation.]] |  | like cache invalidation.]] |
| 7. Method Definitions |  | 7. Method Definitions |
| The set of common methods for HTTP/1.1 is defined below. Although |  | The set of common request methods for HTTP/1.1 is defined below. |
| this set can be expanded, additional methods cannot be assumed to |  | Although this set can be expanded, additional methods cannot be |
| share the same semantics for separately extended clients and servers. |  | assumed to share the same semantics for separately extended clients |
|  |  | and servers. |
| 7.1. Safe and Idempotent Methods |  | 7.1. Safe and Idempotent Methods |
| 7.1.1. Safe Methods |  | 7.1.1. Safe Methods |
| Implementors need to be aware that the software represents the user |  | Implementors need to be aware that the software represents the user |
| in their interactions over the Internet, and need to allow the user |  | in their interactions over the Internet, and need to allow the user |
| to be aware of any actions they take which might have an unexpected |  | to be aware of any actions they take which might have an unexpected |
| significance to themselves or others. |  | significance to themselves or others. |
| In particular, the convention has been established that the GET, |  | In particular, the convention has been established that the GET, |
| HEAD, OPTIONS, and TRACE methods SHOULD NOT have the significance of |  | HEAD, OPTIONS, and TRACE request methods SHOULD NOT have the |
| taking an action other than retrieval. These methods ought to be |  | significance of taking an action other than retrieval. These request |
| considered "safe". This allows user agents to represent other |  | methods ought to be considered "safe". This allows user agents to |
| methods, such as POST, PUT and DELETE, in a special way, so that the |  | represent other methods, such as POST, PUT and DELETE, in a special |
| user is made aware of the fact that a possibly unsafe action is being |  | way, so that the user is made aware of the fact that a possibly |
| requested. |  | 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. |
| 7.1.2. Idempotent Methods |  | 7.1.2. Idempotent Methods |
| Methods can also have the property of "idempotence" in that, aside |  | Request methods can also have the property of "idempotence" in that, |
| from error or expiration issues, the intended effect of multiple |  | aside from error or expiration issues, the intended effect of |
| identical requests is the same as for a single request. The methods |  | multiple identical requests is the same as for a single request. |
| PUT, DELETE, and all safe methods are idempotent. It is important to |  | PUT, DELETE, and all safe request methods are idempotent. It is |
| note that idempotence refers only to changes requested by the client: |  | important to note that idempotence refers only to changes requested |
| a server is free to change its state due to multiple requests for the |  | by the client: a server is free to change its state due to multiple |
| purpose of tracking those requests, versioning of results, etc. |  | requests for the purpose of tracking those requests, versioning of |
|  |  | results, etc. |
| 7.2. OPTIONS |  | 7.2. OPTIONS |
| The OPTIONS method represents a request for information about the |  | The OPTIONS method requests information about the communication |
| communication options available on the request/response chain |  | options available on the request/response chain identified by the |
| identified by the effective request URI. This method allows the |  | effective request URI. This method allows a client to determine the |
| client to determine the options and/or requirements associated with a |  | options and/or requirements associated with a resource, or the |
| resource, or the capabilities of a server, without implying a |  | capabilities of a server, without implying a resource action or |
| resource action or initiating a resource retrieval. |  | initiating a resource retrieval. |
| Responses to this method are not cacheable. |  | Responses to the OPTIONS method are not cacheable. |
| If the OPTIONS request includes a message-body (as indicated by the |  | If the OPTIONS request includes a message-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-target 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 |
| skipping to change at page 16, line 30 |  | skipping to change at page 16, line 22 |
| 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 |
| the appropriate response format. If no response body is included, |  | the appropriate response format. If no response body is included, |
| the response MUST include a Content-Length field with a field-value |  | the response MUST include a Content-Length field with a field-value |
| of "0". |  | of "0". |
| The Max-Forwards request-header field MAY be used to target a |  | The Max-Forwards header field MAY be used to target a specific proxy |
| specific proxy in the request chain (see Section 9.5). If no Max- |  | in the request chain (see Section 9.5). If no Max-Forwards field is |
| Forwards field is present in the request, then the forwarded request |  | present in the request, then the forwarded request MUST NOT include a |
| MUST NOT include a Max-Forwards field. |  | Max-Forwards field. |
| 7.3. GET |  | 7.3. GET |
| The GET method means retrieve whatever information (in the form of a |  | The GET method requests transfer of a current representation of the |
| representation) currently corresponds to the target resource. |  | target resource. |
| If the target resource is a data-producing process, it is the |  | If the target resource is a data-producing process, it is the |
| produced data which shall be returned as the representation in the |  | produced data which shall be returned as the representation in the |
| response and not the source text of the process, unless that text |  | response and not the source text of the process, unless that text |
| happens to be the output of the process. |  | 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 representation be transferred only under the |  | requests that the representation 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 request is intended to reduce unnecessary network |
| usage by allowing cached representations to be refreshed without |  | usage by allowing cached representations to be refreshed without |
| requiring multiple requests or transferring data already held by the |  | requiring multiple requests or transferring data already held by the |
| client. |  | 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 representation be transferred, as |  | requests that only part of the representation be transferred, as |
| described in Section 5.4 of [Part5]. The partial GET method is |  | described in Section 5.4 of [Part5]. The partial GET request is |
| intended to reduce unnecessary network usage by allowing partially- |  | intended to reduce unnecessary network usage by allowing partially- |
| retrieved representations to be completed without transferring data |  | retrieved representations to be completed without transferring data |
| already held by the client. |  | already held by the client. |
| The response to a GET request is cacheable and MAY be used to satisfy |  | The response to a GET request is cacheable and MAY be used to satisfy |
| subsequent GET and HEAD requests (see [Part6]). |  | subsequent GET and HEAD requests (see [Part6]). |
| See Section 11.2 for security considerations when used for forms. |  | See Section 11.2 for security considerations when used for forms. |
| 7.4. HEAD |  | 7.4. HEAD |
| skipping to change at page 17, line 41 |  | skipping to change at page 17, line 33 |
| The response to a HEAD request is cacheable and MAY be used to |  | The response to a HEAD request is cacheable and MAY be used to |
| satisfy a subsequent HEAD request; see [Part6]. It also MAY be used |  | satisfy a subsequent HEAD request; see [Part6]. It also MAY be used |
| to update a previously cached representation from that resource; if |  | to update a previously cached representation from that resource; if |
| the new field values indicate that the cached representation differs |  | the new field values indicate that the cached representation differs |
| from the current representation (as would be indicated by a change in |  | from the current representation (as would be indicated by a change in |
| Content-Length, Content-MD5, ETag or Last-Modified), then the cache |  | Content-Length, Content-MD5, ETag or Last-Modified), then the cache |
| MUST treat the cache entry as stale. |  | MUST treat the cache entry as stale. |
| 7.5. POST |  | 7.5. POST |
| The POST method is used to request that the origin server accept the |  | The POST method requests that the origin server accept the |
| representation enclosed in the request as data to be processed by the |  | representation enclosed in the request as data to be processed by the |
| target resource. POST is designed to allow a uniform method to cover |  | target resource. POST is designed to allow a uniform method to cover |
| the following functions: |  | 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 |
| skipping to change at page 18, line 36 |  | skipping to change at page 18, line 26 |
| cached POST response with a Content-Location header field (see |  | cached POST response with a Content-Location header field (see |
| Section 6.7 of [Part3]) whose value is the effective Request URI MAY |  | Section 6.7 of [Part3]) whose value is the effective Request URI MAY |
| be used to satisfy subsequent GET and HEAD requests. |  | be used to satisfy subsequent GET and HEAD requests. |
| Note that POST caching is not widely implemented. However, the 303 |  | Note that POST caching is not widely implemented. However, the 303 |
| (See Other) response can be used to direct the user agent to retrieve |  | (See Other) response can be used to direct the user agent to retrieve |
| a cacheable resource. |  | a cacheable resource. |
| 7.6. PUT |  | 7.6. PUT |
| The PUT method requests that the enclosed representation be stored at |  | The PUT method requests that the state of the target resource be |
| the effective request URI. If the effective request URI refers to an |  | created or replaced with the state defined by the representation |
| already existing resource, the enclosed representation SHOULD be |  | enclosed in the request message payload. A successful PUT of a given |
| considered a modified version of the one residing on the origin |  | representation would suggest that a subsequent GET on that same |
| server. Otherwise, if the effective request URI does not point to an |  | target resource will result in an equivalent representation being |
| existing resource, and that URI is capable of being defined as a new |  | returned in a 200 (OK) response. However, there is no guarantee that |
| resource by the requesting user agent, the origin server can create |  | such a state change will be observable, since the target resource |
| the resource with that URI. |  | might be acted upon by other user agents in parallel, or might be |
|  |  | subject to dynamic processing by the origin server, before any |
|  |  | subsequent GET is received. A successful response only implies that |
|  |  | the user agent's intent was achieved at the time of its processing by |
|  |  | the origin server. |
| If a new resource is created at the effective request URI, the origin |  | If the target resource does not have a current representation and the |
| server MUST inform the user agent via the 201 (Created) response. If |  | PUT successfully creates one, then the origin server MUST inform the |
| an existing resource is modified, either the 200 (OK) or 204 (No |  | user agent by sending a 201 (Created) response. If the target |
| Content) response codes SHOULD be sent to indicate successful |  | resource does have a current representation and that representation |
| completion of the request. |  | is successfully modified in accordance with the state of the enclosed |
|  |  | representation, then either a 200 (OK) or 204 (No Content) response |
|  |  | SHOULD be sent to indicate successful completion of the request. |
| If the target resource could not be created or modified, an |  | Unrecognized header fields SHOULD be ignored (i.e., not saved as part |
| appropriate error response SHOULD be given that reflects the nature |  | of the resource state). |
| of the problem. The recipient of the representation MUST NOT ignore |  |  |
| any Content-* header fields (headers starting with the prefix |  |  |
| "Content-") that it does not understand or implement and MUST return |  |  |
| a 501 (Not Implemented) response in such cases. |  |  |
| If the request passes through a cache that has one or more stored |  | An origin server SHOULD verify that the PUT representation is |
| responses for the effective request URI, those stored responses |  | consistent with any constraints which the server has for the target |
| SHOULD be marked as stale if the response to the PUT request has a |  | resource that cannot or will not be changed by the PUT. This is |
| success status code. Responses to the PUT method are not cacheable. |  | particularly important when the origin server uses internal |
|  |  | configuration information related to the URI in order to set the |
|  |  | values for representation metadata on GET responses. When a PUT |
|  |  | representation is inconsistent with the target resource, the origin |
|  |  | server SHOULD either make them consistent, by transforming the |
|  |  | representation or changing the resource configuration, or respond |
|  |  | with an appropriate error message containing sufficient information |
|  |  | to explain why the representation is unsuitable. The 409 (Conflict) |
|  |  | or 415 (Unsupported Media Type) status codes are suggested, with the |
|  |  | latter being specific to constraints on Content-Type values. |
| The fundamental difference between the POST and PUT requests is |  | For example, if the target resource is configured to always have a |
| reflected in the different meaning of the effective request URI. The |  | Content-Type of "text/html" and the representation being PUT has a |
| URI in a POST request identifies the resource that will handle the |  | Content-Type of "image/jpeg", then the origin server SHOULD do one |
| enclosed representation. That resource might be a data-accepting |  | of: (a) reconfigure the target resource to reflect the new media |
| process, a gateway to some other protocol, or a document that accepts |  | type; (b) transform the PUT representation to a format consistent |
| annotations. In contrast, the URI in a PUT request identifies the |  | with that of the resource before saving it as the new resource state; |
| resource for which enclosed representation is a new or replacement |  | or, (c) reject the request with a 415 response indicating that the |
| value; the user agent knows what URI is intended and the server MUST |  | target resource is limited to "text/html", perhaps including a link |
| NOT attempt to apply the request to some other resource. If the |  | to a different resource that would be a suitable target for the new |
| server desires that the request be applied to a different URI, it |  | representation. |
| MUST send a 301 (Moved Permanently) response; the user agent MAY then |  |  |
| make its own decision regarding whether or not to redirect the |  |  |
| request. |  |  |
| A single resource MAY be identified by many different URIs. For |  | HTTP does not define exactly how a PUT method affects the state of an |
| example, an article might have a URI for identifying "the current |  | origin server beyond what can be expressed by the intent of the user |
| version" which is separate from the URI identifying each particular |  | agent request and the semantics of the origin server response. It |
| version. In this case, a PUT request on a general URI might result |  | does not define what a resource might be, in any sense of that word, |
| in several other URIs being defined by the origin server. |  | beyond the interface provided via HTTP. It does not define how |
|  |  | resource state is "stored", nor how such storage might change as a |
|  |  | result of a change in resource state, nor how the origin server |
|  |  | translates resource state into representations. Generally speaking, |
|  |  | all implementation details behind the resource interface are |
|  |  | intentionally hidden by the server. |
| HTTP/1.1 does not define how a PUT method affects the state of an |  | The fundamental difference between the POST and PUT methods is |
| origin server. |  | highlighted by the different intent for the target resource. The |
|  |  | target resource in a POST request is intended to handle the enclosed |
|  |  | representation as a data-accepting process, such as for a gateway to |
|  |  | some other protocol or a document that accepts annotations. In |
|  |  | contrast, the target resource in a PUT request is intended to take |
|  |  | the enclosed representation as a new or replacement value. Hence, |
|  |  | the intent of PUT is idempotent and visible to intermediaries, even |
|  |  | though the exact effect is only known by the origin server. |
| Header fields in a PUT request that are recognized as representation |  | Proper interpretation of a PUT request presumes that the user agent |
| metadata SHOULD be applied to the resource created or modified by the |  | knows what target resource is desired. A service that is intended to |
| PUT. Unrecognized header fields SHOULD be ignored. |  | select a proper URI on behalf of the client, after receiving a state- |
|  |  | changing request, SHOULD be implemented using the POST method rather |
|  |  | than PUT. If the origin server will not make the requested PUT state |
|  |  | change to the target resource and instead wishes to have it applied |
|  |  | to a different resource, such as when the resource has been moved to |
|  |  | a different URI, then the origin server MUST send a 301 (Moved |
|  |  | Permanently) response; the user agent MAY then make its own decision |
|  |  | regarding whether or not to redirect the request. |
|  |  | A PUT request applied to the target resource MAY have side-effects on |
|  |  | other resources. For example, an article might have a URI for |
|  |  | identifying "the current version" (a resource) which is separate from |
|  |  | the URIs identifying each particular version (different resources |
|  |  | that at one point shared the same state as the current version |
|  |  | resource). A successful PUT request on "the current version" URI |
|  |  | might therefore create a new version resource in addition to changing |
|  |  | the state of the target resource, and might also cause links to be |
|  |  | added between the related resources. |
|  |  | An origin server SHOULD reject any PUT request that contains a |
|  |  | Content-Range header field, since it might be misinterpreted as |
|  |  | partial content (or might be partial content that is being mistakenly |
|  |  | PUT as a full representation). Partial content updates are possible |
|  |  | by targeting a separately identified resource with state that |
|  |  | overlaps a portion of the larger resource, or by using a different |
|  |  | method that has been specifically defined for partial updates (for |
|  |  | example, the PATCH method defined in [RFC5789]). |
|  |  | Responses to the PUT method are not cacheable. If a PUT request |
|  |  | passes through a cache that has one or more stored responses for the |
|  |  | effective request URI, those stored responses will be invalidated |
|  |  | (see Section 2.5 of [Part6]). |
| 7.7. DELETE |  | 7.7. DELETE |
| The DELETE method requests that the origin server delete the target |  | The DELETE method requests that the origin server delete the target |
| resource. This method MAY be overridden by human intervention (or |  | resource. This method MAY be overridden by human intervention (or |
| other means) on the origin server. The client cannot be guaranteed |  | other means) on the origin server. The client cannot be guaranteed |
| that the operation has been carried out, even if the status code |  | that the operation has been carried out, even if the status code |
| returned from the origin server indicates that the action has been |  | returned from the origin server indicates that the action has been |
| completed successfully. However, the server SHOULD NOT indicate |  | completed successfully. However, the server SHOULD NOT indicate |
| success unless, at the time the response is given, it intends to |  | success unless, at the time the response is given, it intends to |
| delete the resource or move it to an inaccessible location. |  | delete the resource or move it to an inaccessible 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 |
| representation describing the status, 202 (Accepted) if the action |  | representation describing the status, 202 (Accepted) if the action |
| has not yet been enacted, or 204 (No Content) if the action has been |  | has not yet been enacted, or 204 (No Content) if the action has been |
| enacted but the response does not include a representation. |  | enacted but the response does not include a representation. |
| If the request passes through a cache and the effective request URI |  | Responses to the DELETE method are not cacheable. If a DELETE |
| identifies one or more currently cached representations, those |  | request passes through a cache that has one or more stored responses |
| entries SHOULD be treated as stale. Responses to the DELETE method |  | for the effective request URI, those stored responses will be |
| are not cacheable. |  | invalidated (see Section 2.5 of [Part6]). |
| 7.8. TRACE |  | 7.8. TRACE |
| The TRACE method is used to invoke a remote, application-layer loop- |  | The TRACE method requests a remote, application-layer loop-back of |
| back of the request message. The final recipient of the request |  | the request message. The final recipient of the request SHOULD |
| SHOULD reflect the message received back to the client as the |  | reflect the message received back to the client as the message-body |
| message-body of a 200 (OK) response. The final recipient is either |  | of a 200 (OK) response. The final recipient is either the origin |
| the origin server or the first proxy or gateway to receive a Max- |  | server or the first proxy to receive a Max-Forwards value of zero (0) |
| Forwards value of zero (0) in the request (see Section 9.5). A TRACE |  | in the request (see Section 9.5). A TRACE request MUST NOT include a |
| request MUST NOT include a message-body. |  | message-body. |
| 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 9.9 of |  | information. The value of the Via header field (Section 9.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 have a Content-Type of |  | If the request is valid, the response SHOULD have a Content-Type of |
| "message/http" (see Section 10.3.1 of [Part1]) and contain a message- |  | "message/http" (see Section 10.3.1 of [Part1]) and contain a message- |
| body that encloses a copy of the entire request message. Responses |  | body that encloses a copy of the entire request message. Responses |
| to the TRACE method are not cacheable. |  | to the TRACE method are not cacheable. |
| 7.9. CONNECT |  | 7.9. CONNECT |
| This specification reserves the method name CONNECT for use with a |  | The CONNECT method requests that the proxy establish a tunnel to the |
| proxy that can dynamically switch to being a tunnel (e.g., SSL |  | request-target and then restrict its behavior to blind forwarding of |
| tunneling [RFC2817]). |  | packets until the connection is closed. |
|  |  | When using CONNECT, the request-target MUST use the authority form |
|  |  | (Section 4.1.2 of [Part1]); i.e., the request-target consists of only |
|  |  | the host name and port number of the tunnel destination, separated by |
|  |  | a colon. For example, |
|  |  | CONNECT server.example.com:80 HTTP/1.1 |
|  |  | Host: server.example.com:80 |
|  |  | Other HTTP mechanisms can be used normally with the CONNECT method -- |
|  |  | except end-to-end protocol Upgrade requests, since the tunnel must be |
|  |  | established first. |
|  |  | For example, proxy authentication might be used to establish the |
|  |  | authority to create a tunnel: |
|  |  | CONNECT server.example.com:80 HTTP/1.1 |
|  |  | Host: server.example.com:80 |
|  |  | Proxy-Authorization: basic aGVsbG86d29ybGQ= |
|  |  | Like any other pipelined HTTP/1.1 request, data to be tunnel may be |
|  |  | sent immediately after the blank line. The usual caveats also apply: |
|  |  | data may be discarded if the eventual response is negative, and the |
|  |  | connection may be reset with no response if more than one TCP segment |
|  |  | is outstanding. |
|  |  | 7.9.1. Establishing a Tunnel with CONNECT |
|  |  | Any successful (2xx) response to a CONNECT request indicates that the |
|  |  | proxy has established a connection to the requested host and port, |
|  |  | and has switched to tunneling the current connection to that server |
|  |  | connection. |
|  |  | It may be the case that the proxy itself can only reach the requested |
|  |  | origin server through another proxy. In this case, the first proxy |
|  |  | SHOULD make a CONNECT request of that next proxy, requesting a tunnel |
|  |  | to the authority. A proxy MUST NOT respond with any 2xx status code |
|  |  | unless it has either a direct or tunnel connection established to the |
|  |  | authority. |
|  |  | An origin server which receives a CONNECT request for itself MAY |
|  |  | respond with a 2xx status code to indicate that a connection is |
|  |  | established. |
|  |  | If at any point either one of the peers gets disconnected, any |
|  |  | outstanding data that came from that peer will be passed to the other |
|  |  | one, and after that also the other connection will be terminated by |
|  |  | the proxy. If there is outstanding data to that peer undelivered, |
|  |  | that data will be discarded. |
| 8. Status Code Definitions |  | 8. Status Code Definitions |
| Each Status-Code is described below, including any metadata required |  | Each Status-Code is described below, including any metadata required |
| in the response. |  | in the response. |
| 8.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 header fields, and is |  | consisting only of the Status-Line and optional header fields, and is |
| skipping to change at page 24, line 4 |  | skipping to change at page 25, line 47 |
| 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. |
| 8.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. |
| response MUST NOT include a message-body. |  |  |
|  |  | The message-body included with the response MUST be empty. Note that |
|  |  | receivers still need to parse the response according to the algorithm |
|  |  | defined in Section 3.3 of [Part1]. |
| 8.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 payload is a partial representation as defined in |  | the enclosed payload is a partial representation as defined in |
| Section 3.1 of [Part5]. |  | Section 3.1 of [Part5]. |
| Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to |  | Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to |
| determine freshness for 206 responses. |  | determine freshness for 206 responses. |
| skipping to change at page 30, line 42 |  | skipping to change at page 32, line 42 |
| 8.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. |
| 8.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 header fields evaluated |
| evaluated to false when it was tested on the server, as defined in |  | to false when it was tested on the server, as defined in Section 3.2 |
| Section 3.2 of [Part4]. |  | of [Part4]. |
| 8.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 |
| representation is larger than the server is willing or able to |  | representation is larger than the server is willing or able to |
| process. The server MAY close the connection to prevent the client |  | process. The server MAY close the connection to prevent the client |
| from continuing the request. |  | from continuing 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 |
| skipping to change at page 31, line 23 |  | skipping to change at page 33, line 23 |
| rare condition is only likely to occur when a client has improperly |  | rare 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 effective request URI. |  | buffers for reading or manipulating the effective request URI. |
| 8.4.16. 415 Unsupported Media Type |  | 8.4.16. 415 Unsupported Media Type |
| The server is refusing to service the request because the |  | The server is refusing to service the request because the request |
| representation of the request is in a format not supported by the |  | payload is in a format not supported by this request method on the |
| target resource for the requested method. |  | target resource. |
| 8.4.17. 416 Requested Range Not Satisfiable |  | 8.4.17. 416 Requested Range Not Satisfiable |
| The request included a Range request-header field (Section 5.4 of |  | The request included a Range header field (Section 5.4 of [Part5]) |
| [Part5]) and none of the range-specifier values in this field overlap |  | and none of the range-specifier values in this field overlap the |
| the current extent of the selected resource. See Section 3.2 of |  | current extent of the selected resource. See Section 3.2 of [Part5]. |
| [Part5]. |  |  |
| 8.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 header field (see Section 9.2) |
| Section 9.2) could not be met by this server, or, if the server is a |  | could not be met by this server, or, if the server is a proxy, the |
| proxy, the server has unambiguous evidence that the request could not |  | server has unambiguous evidence that the request could not be met by |
| be met by the next-hop server. |  | the next-hop server. |
|  |  | 8.4.19. 426 Upgrade Required |
|  |  | The request can not be completed without a prior protocol upgrade. |
|  |  | This response MUST include an Upgrade header field (Section 9.8 of |
|  |  | [Part1]) specifying the required protocols. |
|  |  | Example: |
|  |  | HTTP/1.1 426 Upgrade Required |
|  |  | Upgrade: HTTP/2.0 |
|  |  | Connection: Upgrade |
|  |  | The server SHOULD include a message body in the 426 response which |
|  |  | indicates in human readable form the reason for the error and |
|  |  | describes any alternative courses which may be available to the user. |
| 8.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 a representation containing an explanation |  | the server SHOULD include a representation containing an explanation |
| of the error situation, and whether it is a temporary or permanent |  | of the error situation, and whether it is a temporary or permanent |
| condition. User agents SHOULD display any included representation to |  | condition. User agents SHOULD display any included representation to |
| the user. These response codes are applicable to any request method. |  | the user. These response codes are applicable to any request method. |
| skipping to change at page 33, line 14 |  | skipping to change at page 35, line 32 |
| SHOULD contain a representation describing why that version is not |  | SHOULD contain a representation describing why that version is not |
| supported and what other protocols are supported by that server. |  | supported and what other protocols are supported by that server. |
| 9. 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. |
| 9.1. Allow |  | 9.1. Allow |
| The "Allow" response-header field lists the set of methods advertised |  | The "Allow" header field lists the set of methods advertised as |
| as supported by the target resource. The purpose of this field is |  | supported by the target resource. The purpose of this field is |
| strictly to inform the recipient of valid methods associated with the |  | strictly to inform the recipient of valid request methods associated |
| resource. |  | with the resource. |
| 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 -- it does not need to |
| understand all the methods specified, since the user agent might have |  | understand all the methods specified in order to handle them |
| other means of communicating with the origin server. |  | according to the generic message handling rules. |
| 9.2. Expect |  | 9.2. Expect |
| The "Expect" request-header field is used to indicate that particular |  | The "Expect" header field is used to indicate that particular server |
| server behaviors are required by the client. |  | 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 ] |
| expect-params = ";" token [ "=" ( token / quoted-string ) ] |  | expect-params = ";" token [ "=" ( token / quoted-string ) ] |
| A server that does not understand or is unable to comply with any of |  | A server that does not understand or is unable to comply with any of |
| skipping to change at page 34, line 17 |  | skipping to change at page 36, line 37 |
| Expect field that includes an expectation-extension that it does not |  | Expect field that includes an expectation-extension that it does not |
| support, it MUST respond with a 417 (Expectation Failed) status code. |  | support, it MUST respond with a 417 (Expectation Failed) status code. |
| Comparison of expectation values is case-insensitive for unquoted |  | Comparison of expectation values is case-insensitive for unquoted |
| tokens (including the 100-continue token), and is case-sensitive for |  | tokens (including the 100-continue token), and is case-sensitive for |
| quoted-string expectation-extensions. |  | quoted-string expectation-extensions. |
| The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST |  | The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST |
| return a 417 (Expectation Failed) status code if it receives a |  | return a 417 (Expectation Failed) status code if it receives a |
| request with an expectation that it cannot meet. However, the Expect |  | request with an expectation that it cannot meet. However, the Expect |
| request-header field itself is end-to-end; it MUST be forwarded if |  | header field itself is end-to-end; it MUST be forwarded if the |
| 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 field. |  | Expect header field. |
| See Section 7.2.3 of [Part1] for the use of the 100 (Continue) status |  | See Section 7.2.3 of [Part1] for the use of the 100 (Continue) status |
| code. |  | code. |
| 9.3. From |  | 9.3. From |
| The "From" request-header field, if given, SHOULD contain an Internet |  | The "From" header field, if given, SHOULD contain an Internet e-mail |
| e-mail address for the human user who controls the requesting user |  | address for the human user who controls the requesting user agent. |
| agent. The address SHOULD be machine-usable, as defined by "mailbox" |  | The address SHOULD be machine-usable, as defined by "mailbox" in |
| in Section 3.4 of [RFC5322]: |  | 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> |
| An example is: |  | An example is: |
| From: webmaster@example.org |  | From: webmaster@example.org |
| skipping to change at page 35, line 15 |  | skipping to change at page 37, line 36 |
| used. |  | used. |
| The client SHOULD NOT send the From header field without the user's |  | The client SHOULD NOT send the From header field without the user's |
| approval, as it might conflict with the user's privacy interests or |  | approval, as it might conflict with the user's privacy interests or |
| their site's security policy. It is strongly recommended that the |  | their site's security policy. It is strongly recommended that the |
| user be able to disable, enable, and modify the value of this field |  | user be able to disable, enable, and modify the value of this field |
| at any time prior to a request. |  | at any time prior to a request. |
| 9.4. Location |  | 9.4. Location |
| The "Location" response-header field is used to identify a newly |  | The "Location" header field is used to identify a newly created |
| created resource, or to redirect the recipient to a different |  | resource, or to redirect the recipient to a different location for |
| location for completion of the request. |  | completion of the request. |
| For 201 (Created) responses, the Location is the URI of the new |  | For 201 (Created) responses, the Location is the URI of the new |
| resource which was created by the request. For 3xx responses, the |  | resource which was created by the request. For 3xx responses, the |
| location SHOULD indicate the server's preferred URI for automatic |  | location SHOULD indicate the server's preferred URI for automatic |
| redirection to the resource. |  | redirection to the resource. |
| The field value consists of a single URI-reference. When it has the |  | The field value consists of a single URI-reference. When it has the |
| form of a relative reference ([RFC3986], Section 4.2), the final |  | form of a relative reference ([RFC3986], Section 4.2), the final |
| value is computed by resolving it against the effective request URI |  | value is computed by resolving it against the effective request URI |
| ([RFC3986], Section 5). |  | ([RFC3986], Section 5). |
| skipping to change at page 35, line 49 |  | skipping to change at page 38, line 22 |
| URI would not be appropriate: |  | URI 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 field specifies the URI for the entire created resource. |  | header field specifies the URI for the entire created resource. |
| o With 305 Use Proxy. |  | o With 305 Use Proxy. |
| Note: This specification does not define precedence rules for the |  | Note: This specification does not define precedence rules for the |
| case where the original URI, as navigated to by the user agent, |  | case where the original URI, as navigated to by the user agent, |
| and the Location header field value both contain fragment |  | and the Location header field value both contain fragment |
| identifiers. |  | identifiers. Thus be aware that including fragment identifiers |
|  |  | might inconvenience anyone relying on the semantics of the |
|  |  | original URI's fragment identifier. |
| Note: The Content-Location header field (Section 6.7 of [Part3]) |  | Note: The Content-Location header field (Section 6.7 of [Part3]) |
| differs from Location in that the Content-Location identifies the |  | differs from Location in that the Content-Location identifies the |
| most specific resource corresponding to the enclosed |  | most specific resource corresponding to the enclosed |
| representation. It is therefore possible for a response to |  | representation. It is therefore possible for a response to |
| contain header fields for both Location and Content-Location. |  | contain header fields for both Location and Content-Location. |
| 9.5. Max-Forwards |  | 9.5. Max-Forwards |
| The "Max-Forwards" request-header field provides a mechanism with the |  | The "Max-Forwards" header field provides a mechanism with the TRACE |
| TRACE (Section 7.8) and OPTIONS (Section 7.2) methods to limit the |  | (Section 7.8) and OPTIONS (Section 7.2) methods to limit the number |
| number of times that the request is forwarded by proxies or gateways. |  | of times that the request is forwarded by proxies. This can be |
| This can be useful when the client is attempting to trace a request |  | useful when the client is attempting to trace a request which appears |
| which appears to be failing or looping in mid-chain. |  | to be failing or 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 can be forwarded. |  | number of times this request message can be forwarded. |
| Each proxy or gateway recipient of a TRACE or OPTIONS request |  | Each recipient of a TRACE or OPTIONS request containing a Max- |
| containing a Max-Forwards header field MUST check and update its |  | Forwards header field MUST check and update its value prior to |
| value prior to forwarding the request. If the received value is zero |  | forwarding the request. If the received value is zero (0), the |
| (0), the recipient MUST NOT forward the request; instead, it MUST |  | recipient MUST NOT forward the request; instead, it MUST respond as |
| respond as the final recipient. If the received Max-Forwards value |  | the final recipient. If the received Max-Forwards value is greater |
| is greater than zero, then the forwarded message MUST contain an |  | than zero, then the forwarded message MUST contain an updated Max- |
| updated Max-Forwards field with a value decremented by one (1). |  | 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 request |
| defined by this specification and for any extension methods for which |  | methods. |
| it is not explicitly referred to as part of that method definition. |  |  |
| 9.6. Referer |  | 9.6. Referer |
| The "Referer" [sic] request-header field allows the client to specify |  | The "Referer" [sic] header field allows the client to specify the URI |
| the URI of the resource from which the effective request URI was |  | of the resource from which the effective request URI was obtained |
| obtained (the "referrer", although the header field is misspelled.). |  | (the "referrer", although the header field is misspelled.). |
| The Referer header field allows servers to generate lists of back- |  | The Referer header field allows servers to generate lists of back- |
| links to resources for interest, logging, optimized caching, etc. It |  | links to resources for interest, logging, optimized caching, etc. It |
| also allows obsolete or mistyped links to be traced for maintenance. |  | also allows obsolete or mistyped links to be traced for maintenance. |
| Some servers use Referer as a means of controlling where they allow |  | Some servers use Referer as a means of controlling where they allow |
| links from (so-called "deep linking"), but legitimate requests do not |  | links from (so-called "deep linking"), but legitimate requests do not |
| always contain a Referer header field. |  | always contain a Referer header field. |
| If the effective request URI was obtained from a source that does not |  | If the effective request URI was obtained from a source that does not |
| have its own URI (e.g., input from the user keyboard), the Referer |  | have its own URI (e.g., input from the user keyboard), the Referer |
| skipping to change at page 37, line 20 |  | skipping to change at page 39, line 40 |
| 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 effective request URI. The URI MUST NOT include a |  | relative to the effective request URI. The URI MUST NOT include a |
| fragment. See Section 11.2 for security considerations. |  | fragment. See Section 11.2 for security considerations. |
| 9.7. Retry-After |  | 9.7. Retry-After |
| The response-header "Retry-After" field can be used with a 503 |  | The header "Retry-After" field can be used with a 503 (Service |
| (Service Unavailable) response to indicate how long the service is |  | Unavailable) response to indicate how long the service is expected to |
| expected to be unavailable to the requesting client. This field MAY |  | be unavailable to the requesting client. This field MAY also be used |
| also be used with any 3xx (Redirection) response to indicate the |  | with any 3xx (Redirection) response to indicate the minimum time the |
| minimum time the user-agent is asked wait before issuing the |  | user-agent is asked wait before issuing the redirected request. |
| redirected request. |  |  |
| The value of this field can be either an HTTP-date or an integer |  | The value of this field can be either an HTTP-date or an integer |
| number of seconds (in decimal) after the time of the response. |  | number of seconds (in decimal) after the time of the response. |
| Retry-After = "Retry-After" ":" OWS Retry-After-v |  | Retry-After = "Retry-After" ":" OWS Retry-After-v |
| Retry-After-v = HTTP-date / delta-seconds |  | Retry-After-v = HTTP-date / delta-seconds |
| Time spans are non-negative decimal integers, representing time in |  | Time spans are non-negative decimal integers, representing time in |
| seconds. |  | seconds. |
| skipping to change at page 37, line 47 |  | skipping to change at page 40, line 17 |
| 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. |
| 9.8. Server |  | 9.8. Server |
| The "Server" response-header field contains information about the |  | The "Server" header field contains information about the software |
| software used by the origin server to handle the request. |  | used by the origin server to handle the request. |
| The field can contain multiple product tokens (Section 6.3 of |  | The field can contain multiple product tokens (Section 6.3 of |
| [Part1]) and comments (Section 3.2 of [Part1]) identifying the server |  | [Part1]) and comments (Section 3.2 of [Part1]) identifying the server |
| and any significant subproducts. The product tokens are listed in |  | and any significant subproducts. The product tokens are listed in |
| order of their significance for identifying the application. |  | order of their significance for 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: |
| Server: CERN/3.0 libwww/2.17 |  | Server: CERN/3.0 libwww/2.17 |
| If the response is being forwarded through a proxy, the proxy |  | If the response is being forwarded through a proxy, the proxy |
| application MUST NOT modify the Server response-header field. |  | application MUST NOT modify the Server header field. Instead, it |
| Instead, it MUST include a Via field (as described in Section 9.9 of |  | MUST include a Via field (as described in Section 9.9 of [Part1]). |
| [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. |
| 9.9. User-Agent |  | 9.9. User-Agent |
| The "User-Agent" request-header field contains information about the |  | The "User-Agent" header field contains information about the user |
| user agent originating the request. User agents SHOULD include this |  | agent originating the request. User agents SHOULD include this field |
| field with requests. |  | with requests. |
| Typically, it is used for statistical purposes, the tracing of |  | Typically, it is used for statistical purposes, the tracing of |
| protocol violations, and tailoring responses to avoid particular user |  | protocol violations, and tailoring responses to avoid particular user |
| agent limitations. |  | agent limitations. |
| The field can contain multiple product tokens (Section 6.3 of |  | The field can contain multiple product tokens (Section 6.3 of |
| [Part1]) and comments (Section 3.2 of [Part1]) identifying the agent |  | [Part1]) and comments (Section 3.2 of [Part1]) identifying the agent |
| and its significant subproducts. By convention, the product tokens |  | and its significant subproducts. By convention, the product tokens |
| are listed in order of their significance for identifying the |  | are listed in order of their significance for identifying the |
| application. |  | application. |
| skipping to change at page 39, line 8 |  | skipping to change at page 41, line 25 |
| field values make requests larger and can also be used to identify |  | field values make requests larger and can also be used to identify |
| ("fingerprint") the user against their wishes. |  | ("fingerprint") the user against their wishes. |
| Likewise, implementations are encouraged not to use the product |  | Likewise, implementations are encouraged not to use the product |
| tokens of other implementations in order to declare compatibility |  | tokens of other implementations in order to declare compatibility |
| with them, as this circumvents the purpose of the field. Finally, |  | with them, as this circumvents the purpose of the field. Finally, |
| they are encouraged not to use comments to identify products; doing |  | they are encouraged not to use comments to identify products; doing |
| so makes the field value more difficult to parse. |  | so makes the field value more difficult to parse. |
| 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 |
| 10. IANA Considerations |  | 10. IANA Considerations |
| 10.1. Method Registry |  | 10.1. Method Registry |
| The registration procedure for HTTP Methods is defined by Section 2.1 |  | The registration procedure for HTTP request methods is defined by |
| of this document. |  | Section 2.2 of this document. |
| The HTTP Method Registry shall be created at |  | The HTTP Method Registry shall be created at |
| <http://www.iana.org/assignments/http-methods> and be populated with |  | <http://www.iana.org/assignments/http-methods> and be populated with |
| the registrations below: |  | the registrations below: |
| +---------+------+-------------+ |  | +---------+------+-------------+ |
| | Method | Safe | Reference | |  | | Method | Safe | Reference | |
| +---------+------+-------------+ |  | +---------+------+-------------+ |
| | CONNECT | no | Section 7.9 | |  | | CONNECT | no | Section 7.9 | |
| | DELETE | no | Section 7.7 | |  | | DELETE | no | Section 7.7 | |
| skipping to change at page 39, line 42 |  | skipping to change at page 42, line 21 |
| | HEAD | yes | Section 7.4 | |  | | HEAD | yes | Section 7.4 | |
| | OPTIONS | yes | Section 7.2 | |  | | OPTIONS | yes | Section 7.2 | |
| | POST | no | Section 7.5 | |  | | POST | no | Section 7.5 | |
| | PUT | no | Section 7.6 | |  | | PUT | no | Section 7.6 | |
| | TRACE | yes | Section 7.8 | |  | | TRACE | yes | Section 7.8 | |
| +---------+------+-------------+ |  | +---------+------+-------------+ |
| 10.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 4.1 |  | defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.2 |
| 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> shall be updated |  | <http://www.iana.org/assignments/http-status-codes> shall be updated |
| with the registrations below: |  | with the registrations below: |
| +-------+-------------------------------+----------------+ |  | +-------+-------------------------------+----------------+ |
| | Value | Description | Reference | |  | | Value | Description | Reference | |
| +-------+-------------------------------+----------------+ |  | +-------+-------------------------------+----------------+ |
| | 100 | Continue | Section 8.1.1 | |  | | 100 | Continue | Section 8.1.1 | |
| skipping to change at page 40, line 38 |  | skipping to change at page 43, line 38 |
| | 406 | Not Acceptable | Section 8.4.7 | |  | | 406 | Not Acceptable | Section 8.4.7 | |
| | 407 | Proxy Authentication Required | Section 8.4.8 | |  | | 407 | Proxy Authentication Required | Section 8.4.8 | |
| | 408 | Request Timeout | Section 8.4.9 | |  | | 408 | Request Timeout | Section 8.4.9 | |
| | 409 | Conflict | Section 8.4.10 | |  | | 409 | Conflict | Section 8.4.10 | |
| | 410 | Gone | Section 8.4.11 | |  | | 410 | Gone | Section 8.4.11 | |
| | 411 | Length Required | Section 8.4.12 | |  | | 411 | Length Required | Section 8.4.12 | |
| | 413 | Request Entity Too Large | Section 8.4.14 | |  | | 413 | Request Entity Too Large | Section 8.4.14 | |
| | 414 | URI Too Long | Section 8.4.15 | |  | | 414 | URI Too Long | Section 8.4.15 | |
| | 415 | Unsupported Media Type | Section 8.4.16 | |  | | 415 | Unsupported Media Type | Section 8.4.16 | |
| | 417 | Expectation Failed | Section 8.4.18 | |  | | 417 | Expectation Failed | Section 8.4.18 | |
|  |  | | 426 | Upgrade Required | Section 8.4.19 | |
| | 500 | Internal Server Error | Section 8.5.1 | |  | | 500 | Internal Server Error | Section 8.5.1 | |
| | 501 | Not Implemented | Section 8.5.2 | |  | | 501 | Not Implemented | Section 8.5.2 | |
| | 502 | Bad Gateway | Section 8.5.3 | |  | | 502 | Bad Gateway | Section 8.5.3 | |
| | 503 | Service Unavailable | Section 8.5.4 | |  | | 503 | Service Unavailable | Section 8.5.4 | |
| | 504 | Gateway Timeout | Section 8.5.5 | |  | | 504 | Gateway Timeout | Section 8.5.5 | |
| | 505 | HTTP Version Not Supported | Section 8.5.6 | |  | | 505 | HTTP Version Not Supported | Section 8.5.6 | |
| +-------+-------------------------------+----------------+ |  | +-------+-------------------------------+----------------+ |
| 10.3. Header Field Registration |  | 10.3. Header Field Registration |
| skipping to change at page 42, line 30 |  | skipping to change at page 45, line 30 |
| The User-Agent (Section 9.9) or Server (Section 9.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. |
| Furthermore, the User-Agent header field may contain enough entropy |  | Furthermore, the User-Agent header field may contain enough entropy |
| to be used, possibly in conjunction with other material, to uniquely |  | to be used, possibly in conjunction with other material, to uniquely |
| identify the user. |  | identify the user. |
| Some methods, like TRACE (Section 7.8), expose information that was |  | Some request methods, like TRACE (Section 7.8), expose information |
| sent in request header fields within the body of their response. |  | that was sent in request header fields within the body of their |
| Clients SHOULD be careful with sensitive information, like Cookies, |  | response. Clients SHOULD be careful with sensitive information, like |
| Authorization credentials and other header fields that might be used |  | Cookies, Authorization credentials, and other header fields that |
| to collect data from the client. |  | might be used to collect data from the client. |
| 11.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. |
| skipping to change at page 43, line 17 |  | skipping to change at page 46, line 17 |
| instead. |  | instead. |
| 11.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 header fields in responses that are generated under control |  | Location header fields in responses that are generated under control |
| of said organizations to make sure that they do not attempt to |  | of 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. |
|  |  | 11.4. Security Considerations for CONNECT |
|  |  | Since tunneled data is opaque to the proxy, there are additional |
|  |  | risks to tunneling to other well-known or reserved ports. A HTTP |
|  |  | client CONNECTing to port 25 could relay spam via SMTP, for example. |
|  |  | As such, proxies SHOULD restrict CONNECT access to a small number of |
|  |  | known ports. |
| 12. Acknowledgments |  | 12. Acknowledgments |
| 13. References |  | 13. References |
| 13.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-12 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-13 |
| (work in progress), October 2010. |  | (work in progress), March 2011. |
| [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-12 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-13 |
| (work in progress), October 2010. |  | (work in progress), March 2011. |
| [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-12 (work in |  | Requests", draft-ietf-httpbis-p4-conditional-13 (work in |
| progress), October 2010. |  | progress), March 2011. |
| [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-12 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-13 (work |
| in progress), October 2010. |  | in progress), March 2011. |
| [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., |
| Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |  | Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |
| 6: Caching", draft-ietf-httpbis-p6-cache-12 (work in |  | 6: Caching", draft-ietf-httpbis-p6-cache-13 (work in |
| progress), October 2010. |  | progress), March 2011. |
| [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-12 (work in progress), |  | draft-ietf-httpbis-p7-auth-13 (work in progress), |
| October 2010. |  | March 2011. |
| [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. |
| [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |  | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |
| Resource Identifier (URI): Generic Syntax", STD 66, |  | Resource Identifier (URI): Generic Syntax", STD 66, |
| RFC 3986, January 2005. |  | RFC 3986, January 2005. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
| Specifications: ABNF", STD 68, RFC 5234, January 2008. |  | Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| skipping to change at page 44, line 48 |  | skipping to change at page 48, line 8 |
| Procedures for Message Header Fields", BCP 90, RFC 3864, |  | Procedures for Message Header Fields", BCP 90, RFC 3864, |
| September 2004. |  | September 2004. |
| [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |  | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |
| IANA Considerations Section in RFCs", BCP 26, RFC 5226, |  | IANA Considerations Section in RFCs", BCP 26, RFC 5226, |
| May 2008. |  | May 2008. |
| [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |  | [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |
| October 2008. |  | October 2008. |
|  |  | [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", |
|  |  | RFC 5789, March 2010. |
| Appendix A. Changes from RFC 2616 |  | Appendix A. 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 4.1) |  | in Section 7.1 of [RFC2817]. (Section 4.2) |
| Clarify definition of POST. (Section 7.5) |  | Clarify definition of POST. (Section 7.5) |
|  |  | Remove requirement to handle all Content-* header fields; ban use of |
|  |  | Content-Range with PUT. (Section 7.6) |
|  |  | Take over definition of CONNECT method from [RFC2817]. (Section 7.9) |
| 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 8.3.2, 8.3.3 and 8.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 target resource must be |  | implement it. It used to indicate that the target resource must be |
| accessed through the proxy given by the Location field. The Location |  | accessed through the proxy given by the Location field. The Location |
| field gave the URI of the proxy. The recipient was expected to |  | field gave the URI of the proxy. The recipient was expected to |
| repeat this single request via the proxy. (Section 8.3.6) |  | repeat this single request via the proxy. (Section 8.3.6) |
|  |  | Define status 426 (Upgrade Required) (this was incorporated from |
|  |  | [RFC2817]). (Section 8.4.19) |
| Reclassify "Allow" as response header field, removing the option to |  | Reclassify "Allow" as response header field, 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 field and remove requirement on clients |  | contents of the Allow header field and remove requirement on clients |
| to always trust the header field value. (Section 9.1) |  | to always trust the header field value. (Section 9.1) |
| Correct syntax of Location header field to allow URI references |  | Correct syntax of Location header field to allow URI references |
| (including relative references and fragments), as referred symbol |  | (including relative references and fragments), as referred symbol |
| "absoluteURI" wasn't what was expected, and add some clarifications |  | "absoluteURI" wasn't what was expected, and add some clarifications |
| as to when use of fragments would not be appropriate. (Section 9.4) |  | as to when use of fragments would not be appropriate. (Section 9.4) |
|  |  | Restrict Max-Forwards header field to OPTIONS and TRACE (previously, |
|  |  | extension methods could have used it as well). (Section 9.5) |
| Allow Referer field value of "about:blank" as alternative to not |  | Allow Referer field value of "about:blank" as alternative to not |
| specifying it. (Section 9.6) |  | specifying it. (Section 9.6) |
| In the description of the Server header field, the Via field was |  | In the description of the Server header field, the Via field was |
| described as a SHOULD. The requirement was and is stated correctly |  | described as a SHOULD. The requirement was and is stated correctly |
| in the description of the Via header field in Section 9.9 of [Part1]. |  | in the description of the Via header field in Section 9.9 of [Part1]. |
| (Section 9.8) |  | (Section 9.8) |
| Appendix B. Collected ABNF |  | Appendix B. Collected ABNF |
| Accept = <Accept, defined in [Part3], Section 6.1> |  |  |
| Accept-Charset = <Accept-Charset, defined in [Part3], Section 6.2> |  |  |
| Accept-Encoding = <Accept-Encoding, defined in [Part3], Section 6.3> |  |  |
| Accept-Language = <Accept-Language, defined in [Part3], Section 6.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 = "Allow:" OWS Allow-v |
| Allow-v = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] |  | Allow-v = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] |
| Authorization = <Authorization, defined in [Part7], Section 4.1> |  |  |
| ETag = <ETag, defined in [Part4], Section 6.1> |  |  |
| Expect = "Expect:" OWS Expect-v |  | Expect = "Expect:" OWS Expect-v |
| Expect-v = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) |  | Expect-v = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) |
| From = "From:" OWS From-v |  | From = "From:" OWS From-v |
| From-v = mailbox |  | From-v = mailbox |
| HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |  | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |
| Host = <Host, defined in [Part1], Section 2.6> |  |  |
| 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 = "Location:" OWS Location-v |
| Location-v = URI-reference |  | Location-v = URI-reference |
| 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 |
| Method = %x4F.50.54.49.4F.4E.53 ; OPTIONS |  | Method = token |
| / %x47.45.54 ; GET |  |  |
| / %x48.45.41.44 ; HEAD |  |  |
| / %x50.4F.53.54 ; POST |  |  |
| / %x50.55.54 ; PUT |  |  |
| / %x44.45.4C.45.54.45 ; DELETE |  |  |
| / %x54.52.41.43.45 ; TRACE |  |  |
| / %x43.4F.4E.4E.45.43.54 ; CONNECT |  |  |
| / extension-method |  |  |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| Proxy-Authenticate = |  |  |
| <Proxy-Authenticate, defined in [Part7], Section 4.2> |  |  |
| Proxy-Authorization = |  |  |
| <Proxy-Authorization, defined in [Part7], Section 4.3> |  |  |
| RWS = <RWS, defined in [Part1], Section 1.2.2> |  | RWS = <RWS, defined in [Part1], Section 1.2.2> |
| Range = <Range, defined in [Part5], Section 5.4> |  |  |
| Reason-Phrase = *( WSP / VCHAR / obs-text ) |  | Reason-Phrase = *( WSP / VCHAR / obs-text ) |
| Referer = "Referer:" OWS Referer-v |  | Referer = "Referer:" OWS Referer-v |
| Referer-v = absolute-URI / partial-URI |  | Referer-v = absolute-URI / partial-URI |
| Retry-After = "Retry-After:" OWS Retry-After-v |  | Retry-After = "Retry-After:" OWS Retry-After-v |
| Retry-After-v = HTTP-date / delta-seconds |  | Retry-After-v = HTTP-date / delta-seconds |
| Server = "Server:" OWS Server-v |  | Server = "Server:" OWS Server-v |
| Server-v = product *( RWS ( product / comment ) ) |  | Server-v = product *( RWS ( product / comment ) ) |
| Status-Code = "100" / "101" / "200" / "201" / "202" / "203" / "204" / |  | Status-Code = 3DIGIT |
| "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 9.5> |  |  |
| URI-reference = <URI-reference, defined in [Part1], Section 2.6> |  | URI-reference = <URI-reference, defined in [Part1], Section 2.6> |
| User-Agent = "User-Agent:" OWS User-Agent-v |  | User-Agent = "User-Agent:" OWS User-Agent-v |
| User-Agent-v = product *( RWS ( product / comment ) ) |  | User-Agent-v = product *( RWS ( product / comment ) ) |
| Vary = <Vary, defined in [Part6], Section 3.5> |  |  |
| WWW-Authenticate = |  |  |
| <WWW-Authenticate, defined in [Part7], Section 4.4> |  |  |
| absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |
| comment = <comment, defined in [Part1], Section 3.2> |  | comment = <comment, defined in [Part1], Section 3.2> |
| delta-seconds = 1*DIGIT |  | delta-seconds = 1*DIGIT |
| expect-params = ";" token [ "=" ( token / quoted-string ) ] |  | expect-params = ";" token [ "=" ( token / quoted-string ) ] |
| 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 ] |
| extension-code = 3DIGIT |  |  |
| extension-method = token |  |  |
| mailbox = <mailbox, defined in [RFC5322], Section 3.4> |  | mailbox = <mailbox, defined in [RFC5322], Section 3.4> |
| obs-text = <obs-text, defined in [Part1], Section 1.2.2> |  | obs-text = <obs-text, defined in [Part1], Section 1.2.2> |
| partial-URI = <partial-URI, defined in [Part1], Section 2.6> |  | partial-URI = <partial-URI, defined in [Part1], Section 2.6> |
| product = <product, defined in [Part1], Section 6.3> |  | product = <product, defined in [Part1], Section 6.3> |
| quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |  | 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> |  | token = <token, defined in [Part1], Section 1.2.2> |
| ABNF diagnostics: |  | ABNF diagnostics: |
|  |  | ; Allow defined but not used |
|  |  | ; Expect defined but not used |
|  |  | ; From defined but not used |
|  |  | ; Location defined but not used |
|  |  | ; Max-Forwards defined but not used |
| ; Reason-Phrase defined but not used |  | ; Reason-Phrase defined but not used |
|  |  | ; Referer defined but not used |
|  |  | ; Retry-After defined but not used |
|  |  | ; Server defined but not used |
| ; Status-Code defined but not used |  | ; Status-Code defined but not used |
| ; request-header defined but not used |  | ; User-Agent defined but not used |
| ; response-header defined but not used |  |  |
| Appendix C. Change Log (to be removed by RFC Editor before publication) |  | Appendix C. Change Log (to be removed by RFC Editor before publication) |
| C.1. Since RFC 2616 |  | C.1. Since RFC 2616 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| C.2. Since draft-ietf-httpbis-p2-semantics-00 |  | C.2. Since draft-ietf-httpbis-p2-semantics-00 |
| Closed issues: |  | Closed issues: |
| skipping to change at page 53, line 30 |  | skipping to change at page 56, line 8 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/229>: |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/229>: |
| "Considerations for new status codes" |  | "Considerations for new status codes" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/230>: |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/230>: |
| "Considerations for new methods" |  | "Considerations for new methods" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/232>: "User-Agent |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/232>: "User-Agent |
| guidelines" (relating to the 'User-Agent' header field) |  | guidelines" (relating to the 'User-Agent' header field) |
|  |  | C.14. Since draft-ietf-httpbis-p2-semantics-12 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment |
|  |  | combination / precedence during redirects" (added warning about |
|  |  | having a fragid on the redirect may cause inconvenience in some |
|  |  | cases) |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/79>: "Content-* vs. |
|  |  | PUT" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/102>: "Understanding |
|  |  | Content-* on non-PUT requests" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/104>: "Header type |
|  |  | defaulting" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store |
|  |  | under' vs 'store at'" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/137>: "duplicate |
|  |  | ABNF for Reason-Phrase" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/180>: "Note special |
|  |  | status of Content-* prefix in header registration procedures" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/203>: "Max-Forwards |
|  |  | vs extension methods" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/213>: "What is the |
|  |  | value space of HTTP status codes?" (actually fixed in |
|  |  | draft-ietf-httpbis-p2-semantics-11) |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header |
|  |  | Classification" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/225>: "PUT side |
|  |  | effect: invalidation or just stale?" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/226>: "proxies not |
|  |  | supporting certain methods" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/239>: "Migrate |
|  |  | CONNECT from RFC2817 to p2" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate |
|  |  | Upgrade details from RFC2817" |
|  |  | o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/267>: "clarify |
|  |  | PUT semantics'" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/275>: "duplicate |
|  |  | ABNF for 'Method'" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
|  |  | ABNFs for header fields" |
| Index |  | Index |
| 1 |  | 1 |
| 100 Continue (status code) 21 |  | 100 Continue (status code) 23 |
| 101 Switching Protocols (status code) 21 |  | 101 Switching Protocols (status code) 23 |
| 2 |  | 2 |
| 200 OK (status code) 22 |  | 200 OK (status code) 23 |
| 201 Created (status code) 22 |  | 201 Created (status code) 24 |
| 202 Accepted (status code) 22 |  | 202 Accepted (status code) 24 |
| 203 Non-Authoritative Information (status code) 23 |  | 203 Non-Authoritative Information (status code) 25 |
| 204 No Content (status code) 23 |  | 204 No Content (status code) 25 |
| 205 Reset Content (status code) 23 |  | 205 Reset Content (status code) 25 |
| 206 Partial Content (status code) 24 |  | 206 Partial Content (status code) 26 |
| 3 |  | 3 |
| 300 Multiple Choices (status code) 24 |  | 300 Multiple Choices (status code) 26 |
| 301 Moved Permanently (status code) 25 |  | 301 Moved Permanently (status code) 27 |
| 302 Found (status code) 25 |  | 302 Found (status code) 27 |
| 303 See Other (status code) 26 |  | 303 See Other (status code) 28 |
| 304 Not Modified (status code) 26 |  | 304 Not Modified (status code) 28 |
| 305 Use Proxy (status code) 27 |  | 305 Use Proxy (status code) 29 |
| 306 (Unused) (status code) 27 |  | 306 (Unused) (status code) 29 |
| 307 Temporary Redirect (status code) 27 |  | 307 Temporary Redirect (status code) 29 |
| 4 |  | 4 |
| 400 Bad Request (status code) 28 |  | 400 Bad Request (status code) 30 |
| 401 Unauthorized (status code) 28 |  | 401 Unauthorized (status code) 30 |
| 402 Payment Required (status code) 28 |  | 402 Payment Required (status code) 30 |
| 403 Forbidden (status code) 28 |  | 403 Forbidden (status code) 30 |
| 404 Not Found (status code) 28 |  | 404 Not Found (status code) 30 |
| 405 Method Not Allowed (status code) 28 |  | 405 Method Not Allowed (status code) 30 |
| 406 Not Acceptable (status code) 28 |  | 406 Not Acceptable (status code) 30 |
| 407 Proxy Authentication Required (status code) 29 |  | 407 Proxy Authentication Required (status code) 31 |
| 408 Request Timeout (status code) 29 |  | 408 Request Timeout (status code) 31 |
| 409 Conflict (status code) 29 |  | 409 Conflict (status code) 31 |
| 410 Gone (status code) 30 |  | 410 Gone (status code) 32 |
| 411 Length Required (status code) 30 |  | 411 Length Required (status code) 32 |
| 412 Precondition Failed (status code) 30 |  | 412 Precondition Failed (status code) 32 |
| 413 Request Entity Too Large (status code) 30 |  | 413 Request Entity Too Large (status code) 32 |
| 414 URI Too Long (status code) 31 |  | 414 URI Too Long (status code) 33 |
| 415 Unsupported Media Type (status code) 31 |  | 415 Unsupported Media Type (status code) 33 |
| 416 Requested Range Not Satisfiable (status code) 31 |  | 416 Requested Range Not Satisfiable (status code) 33 |
| 417 Expectation Failed (status code) 31 |  | 417 Expectation Failed (status code) 33 |
|  |  | 426 Upgrade Required (status code) 33 |
| 5 |  | 5 |
| 500 Internal Server Error (status code) 32 |  | 500 Internal Server Error (status code) 34 |
| 501 Not Implemented (status code) 32 |  | 501 Not Implemented (status code) 34 |
| 502 Bad Gateway (status code) 32 |  | 502 Bad Gateway (status code) 34 |
| 503 Service Unavailable (status code) 32 |  | 503 Service Unavailable (status code) 34 |
| 504 Gateway Timeout (status code) 32 |  | 504 Gateway Timeout (status code) 35 |
| 505 HTTP Version Not Supported (status code) 32 |  | 505 HTTP Version Not Supported (status code) 35 |
| A |  | A |
| Allow header 33 |  | Allow header field 35 |
| C |  | C |
| CONNECT method 20 |  | CONNECT method 21 |
| D |  | D |
| DELETE method 19 |  | DELETE method 20 |
| E |  | E |
| Expect header 33 |  | Expect header field 36 |
| F |  | F |
| From header 34 |  | From header field 36 |
| G |  | G |
| GET method 16 |  | GET method 16 |
| Grammar |  | Grammar |
| Allow 33 |  | Allow 35 |
| Allow-v 33 |  | Allow-v 35 |
| delta-seconds 37 |  | delta-seconds 40 |
| Expect 33 |  | Expect 36 |
| expect-params 33 |  | expect-params 36 |
| Expect-v 33 |  | Expect-v 36 |
| expectation 33 |  | expectation 36 |
| expectation-extension 33 |  | expectation-extension 36 |
| extension-code 11 |  | extension-code 10 |
| extension-method 8 |  | From 37 |
| From 34 |  | From-v 37 |
| From-v 34 |  | Location 37 |
| Location 35 |  | Location-v 37 |
| Location-v 35 |  | Max-Forwards 38 |
| Max-Forwards 36 |  | Max-Forwards-v 38 |
| Max-Forwards-v 36 |  | Method 7 |
| Method 8 |  | Reason-Phrase 10 |
| Reason-Phrase 11 |  | Referer 39 |
| Referer 37 |  | Referer-v 39 |
| Referer-v 37 |  | Retry-After 39 |
| request-header 10 |  | Retry-After-v 39 |
| response-header 13 |  | Server 40 |
| Retry-After 37 |  | Server-v 40 |
| Retry-After-v 37 |  | Status-Code 10 |
| Server 38 |  | User-Agent 41 |
| Server-v 38 |  | User-Agent-v 41 |
| Status-Code 11 |  |  |
| User-Agent 39 |  |  |
| User-Agent-v 39 |  |  |
| H |  | H |
| HEAD method 17 |  | HEAD method 17 |
| Headers |  | Header Fields |
| Allow 33 |  | Allow 35 |
| Expect 33 |  | Expect 36 |
| From 34 |  | From 36 |
| Location 35 |  | Location 37 |
| Max-Forwards 36 |  | Max-Forwards 38 |
| Referer 36 |  | Referer 39 |
| Retry-After 37 |  | Retry-After 39 |
| Server 37 |  | Server 40 |
| User-Agent 38 |  | User-Agent 40 |
| I |  | I |
| Idempotent Methods 15 |  | Idempotent Methods 15 |
| L |  | L |
| Location header 35 |  | Location header field 37 |
| M |  | M |
| Max-Forwards header 36 |  | Max-Forwards header field 38 |
| Methods |  | Methods |
| CONNECT 20 |  | CONNECT 21 |
| DELETE 19 |  | DELETE 20 |
| GET 16 |  | GET 16 |
| HEAD 17 |  | HEAD 17 |
| OPTIONS 15 |  | OPTIONS 15 |
| POST 17 |  | POST 17 |
| PUT 18 |  | PUT 18 |
| TRACE 20 |  | TRACE 21 |
| O |  | O |
| OPTIONS method 15 |  | OPTIONS method 15 |
| P |  | P |
| POST method 17 |  | POST method 17 |
| PUT method 18 |  | PUT method 18 |
| R |  | R |
| Referer header 36 |  | Referer header field 39 |
| Retry-After header 37 |  | Retry-After header field 39 |
| S |  | S |
| Safe Methods 15 |  | Safe Methods 14 |
| Server header 37 |  | Server header field 40 |
| Status Codes |  | Status Codes |
| 100 Continue 21 |  | 100 Continue 23 |
| 101 Switching Protocols 21 |  | 101 Switching Protocols 23 |
| 200 OK 22 |  | 200 OK 23 |
| 201 Created 22 |  | 201 Created 24 |
| 202 Accepted 22 |  | 202 Accepted 24 |
| 203 Non-Authoritative Information 23 |  | 203 Non-Authoritative Information 25 |
| 204 No Content 23 |  | 204 No Content 25 |
| 205 Reset Content 23 |  | 205 Reset Content 25 |
| 206 Partial Content 24 |  | 206 Partial Content 26 |
| 300 Multiple Choices 24 |  | 300 Multiple Choices 26 |
| 301 Moved Permanently 25 |  | 301 Moved Permanently 27 |
| 302 Found 25 |  | 302 Found 27 |
| 303 See Other 26 |  | 303 See Other 28 |
| 304 Not Modified 26 |  | 304 Not Modified 28 |
| 305 Use Proxy 27 |  | 305 Use Proxy 29 |
| 306 (Unused) 27 |  | 306 (Unused) 29 |
| 307 Temporary Redirect 27 |  | 307 Temporary Redirect 29 |
| 400 Bad Request 28 |  | 400 Bad Request 30 |
| 401 Unauthorized 28 |  | 401 Unauthorized 30 |
| 402 Payment Required 28 |  | 402 Payment Required 30 |
| 403 Forbidden 28 |  | 403 Forbidden 30 |
| 404 Not Found 28 |  | 404 Not Found 30 |
| 405 Method Not Allowed 28 |  | 405 Method Not Allowed 30 |
| 406 Not Acceptable 28 |  | 406 Not Acceptable 30 |
| 407 Proxy Authentication Required 29 |  | 407 Proxy Authentication Required 31 |
| 408 Request Timeout 29 |  | 408 Request Timeout 31 |
| 409 Conflict 29 |  | 409 Conflict 31 |
| 410 Gone 30 |  | 410 Gone 32 |
| 411 Length Required 30 |  | 411 Length Required 32 |
| 412 Precondition Failed 30 |  | 412 Precondition Failed 32 |
| 413 Request Entity Too Large 30 |  | 413 Request Entity Too Large 32 |
| 414 URI Too Long 31 |  | 414 URI Too Long 33 |
| 415 Unsupported Media Type 31 |  | 415 Unsupported Media Type 33 |
| 416 Requested Range Not Satisfiable 31 |  | 416 Requested Range Not Satisfiable 33 |
| 417 Expectation Failed 31 |  | 417 Expectation Failed 33 |
| 500 Internal Server Error 32 |  | 426 Upgrade Required 33 |
| 501 Not Implemented 32 |  | 500 Internal Server Error 34 |
| 502 Bad Gateway 32 |  | 501 Not Implemented 34 |
| 503 Service Unavailable 32 |  | 502 Bad Gateway 34 |
| 504 Gateway Timeout 32 |  | 503 Service Unavailable 34 |
| 505 HTTP Version Not Supported 32 |  | 504 Gateway Timeout 35 |
|  |  | 505 HTTP Version Not Supported 35 |
| T |  | T |
| TRACE method 20 |  | TRACE method 21 |
| U |  | U |
| User-Agent header 38 |  | User-Agent header field 40 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Day Software |  | Adobe Systems Incorporated |
| 23 Corporate Plaza DR, Suite 280 |  | 345 Park Ave |
| Newport Beach, CA 92660 |  | San Jose, CA 95110 |
| USA |  | USA |
| Phone: +1-949-706-5300 |  |  |
| Fax: +1-949-706-5305 |  |  |
| EMail: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
| URI: http://roy.gbiv.com/ |  | URI: http://roy.gbiv.com/ |
| Jim Gettys |  | Jim Gettys |
| Alcatel-Lucent Bell Labs |  | Alcatel-Lucent Bell Labs |
| 21 Oak Knoll Road |  | 21 Oak Knoll Road |
| Carlisle, MA 01741 |  | Carlisle, MA 01741 |
| USA |  | USA |
| EMail: jg@freedesktop.org |  | EMail: jg@freedesktop.org |
| URI: http://gettys.wordpress.com/ |  | URI: http://gettys.wordpress.com/ |
| Jeffrey C. Mogul |  | Jeffrey C. Mogul |
| Hewlett-Packard Company |  | Hewlett-Packard Company |
| HP Labs, Large Scale Systems Group |  | HP Labs, Large Scale Systems Group |
| 1501 Page Mill Road, MS 1177 |  | 1501 Page Mill Road, MS 1177 |
| Palo Alto, CA 94304 |  | Palo Alto, CA 94304 |
| USA |  | USA |
| EMail: JeffMogul@acm.org |  | EMail: JeffMogul@acm.org |
| Henrik Frystyk Nielsen |  | Henrik Frystyk Nielsen |
| skipping to change at page 58, line 31 |  | skipping to change at page 62, line 22 |
| Henrik Frystyk Nielsen |  | Henrik Frystyk Nielsen |
| Microsoft Corporation |  | Microsoft Corporation |
| 1 Microsoft Way |  | 1 Microsoft Way |
| Redmond, WA 98052 |  | Redmond, WA 98052 |
| USA |  | USA |
| EMail: henrikn@microsoft.com |  | EMail: henrikn@microsoft.com |
| Larry Masinter |  | Larry Masinter |
| Adobe Systems, Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| EMail: LMM@acm.org |  | EMail: LMM@acm.org |
| URI: http://larry.masinter.net/ |  | URI: http://larry.masinter.net/ |
| Paul J. Leach |  | Paul J. Leach |
| Microsoft Corporation |  | Microsoft Corporation |
| 1 Microsoft Way |  | 1 Microsoft Way |
End of changes. 135 change blocks.
| 644 lines changed or deleted |  | 792 lines changed or added |
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/