| draft-ietf-httpbis-p2-semantics-13.txt |  | draft-ietf-httpbis-p2-semantics-14.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | 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: September 15, 2011 HP |  | Expires: October 20, 2011 HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe |  | 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 |
| March 14, 2011 |  | April 18, 2011 |
| HTTP/1.1, part 2: Message Semantics |  | HTTP/1.1, part 2: Message Semantics |
| draft-ietf-httpbis-p2-semantics-13 |  | draft-ietf-httpbis-p2-semantics-14 |
| 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), which is archived at |
| at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
|  |  | The current issues list is 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.14. |  | The changes in this draft are summarized in Appendix C.15. |
| 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 |
| skipping to change at page 2, line 17 |  | skipping to change at page 2, line 20 |
| 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 September 15, 2011. |  | This Internet-Draft will expire on October 20, 2011. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2011 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 |
| skipping to change at page 3, line 32 |  | skipping to change at page 3, line 34 |
| 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 21 |  | 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 21 |
| 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 21 |  | 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 21 |
| 7.9.1. Establishing a Tunnel with CONNECT . . . . . . . . . . 22 |  | 7.9.1. Establishing a Tunnel with CONNECT . . . . . . . . . . 22 |
| 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 22 |  | 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 23 |
| 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 22 |  | 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 23 |
| 8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 23 |  | 8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 23 |
| 8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 23 |  | 8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 23 |
| 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 23 |  | 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 24 |
| 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 23 |  | 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 24 |  | 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 24 |
| 8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 24 |  | 8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 25 |
| 8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 25 |  | 8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 25 |
| 8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 25 |  | 8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 25 |
| 8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 25 |  | 8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 26 |
| 8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 26 |  | 8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 26 |
| 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 26 |  | 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 26 |
| 8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 26 |  | 8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 27 |
| 8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 27 |  | 8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 27 |
| 8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 27 |  | 8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 28 |
| 8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 28 |  | 8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 28 |
| 8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 28 |  | 8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 29 |
| 8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 29 |  | 8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 29 |
| 8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 29 |  | 8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 29 |
| 8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 29 |  | 8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 29 |
| 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 29 |  | 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 30 |
| 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 30 |  | 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 30 |
| 8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 30 |  | 8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 30 |
| 8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 30 |  | 8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 30 |
| 8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 30 |  | 8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 30 |
| 8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 30 |  | 8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 31 |
| 8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 30 |  | 8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 31 |
| 8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 30 |  | 8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 31 |
| 8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 31 |  | 8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 32 |
| 8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 31 |  | 8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 32 |
| 8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 31 |  | 8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 32 |
| 8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 32 |  | 8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 33 |
| 8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 32 |  | 8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 33 |
| 8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 32 |  | 8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 33 |
| 8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 33 |  | 8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 33 |
| 8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 33 |  | 8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 33 |
| 8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 33 |  | 8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 34 |
| 8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 33 |  | 8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 34 |
| 8.4.19. 426 Upgrade Required . . . . . . . . . . . . . . . . . 33 |  | 8.4.19. 426 Upgrade Required . . . . . . . . . . . . . . . . . 34 |
| 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 34 |  | 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 34 |
| 8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 34 |  | 8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 34 |
| 8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 34 |  | 8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 35 |
| 8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 34 |  | 8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 35 |
| 8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 34 |  | 8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 35 |
| 8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 35 |  | 8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 35 |
| 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 35 |  | 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 35 |
| 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 35 |  | 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 36 |
| 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 35 |  | 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 36 |
| 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 36 |  | 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 36 |
| 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 |  | 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 |
| 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 37 |  | 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 38 |
| 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 38 |  | 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 39 |
| 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 39 |  | 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 39 |
| 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 39 |  | 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 40 |
| 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 40 |  | 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 40 |
| 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 40 |  | 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 41 |
| 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 |  | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 |
| 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 41 |  | 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 41 |
| 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 42 |  | 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 42 |
| 10.3. Header Field Registration . . . . . . . . . . . . . . . . 43 |  | 10.3. Header Field Registration . . . . . . . . . . . . . . . . 43 |
| 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44 |  | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44 |
| 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 44 |  | 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 44 |
| 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 45 |  | 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 45 |
| 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 46 |  | 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 46 |
| 11.4. Security Considerations for CONNECT . . . . . . . . . . . 46 |  | 11.4. Security Considerations for CONNECT . . . . . . . . . . . 46 |
| 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 |  | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 |
| 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 |  | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 |
| 13.1. Normative References . . . . . . . . . . . . . . . . . . . 46 |  | 13.1. Normative References . . . . . . . . . . . . . . . . . . . 46 |
| 13.2. Informative References . . . . . . . . . . . . . . . . . . 47 |  | 13.2. Informative References . . . . . . . . . . . . . . . . . . 47 |
| Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 48 |  | Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 48 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 49 |  | 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) . . . . . . . . . . . . . . . . . . . . 50 |  | publication) . . . . . . . . . . . . . . . . . . . . 51 |
| C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 50 |  | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 51 |
| C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 50 |  | C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 51 |
| C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 51 |  | C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 52 |
| C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 52 |  | C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 52 |
| C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 52 |  | C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 53 |
| C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 53 |  | C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 53 |
| C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 53 |  | C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 54 |
| C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 53 |  | C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 54 |
| C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 54 |  | C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 54 |
| C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 54 |  | C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 55 |
| C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 55 |  | C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 55 |
| C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 55 |  | C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 55 |
| C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 55 |  | C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 56 |
| C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 56 |  | C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 56 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 |  | C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 58 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 |
| 1. Introduction |  | 1. Introduction |
| This document defines HTTP/1.1 request and response semantics. Each |  | This document defines HTTP/1.1 request and response semantics. Each |
| HTTP message, as defined in [Part1], is in the form of either a |  | HTTP message, as defined in [Part1], is in the form of either a |
| request or a response. An HTTP server listens on a connection for |  | request or a response. An HTTP server listens on a connection for |
| HTTP requests and responds to each request, in the order received on |  | HTTP requests and responds to each request, in the order received on |
| that connection, with one or more HTTP response messages. This |  | that connection, with one or more HTTP response messages. This |
| document defines the commonly agreed upon semantics of the HTTP |  | document defines the commonly agreed upon semantics of the HTTP |
| uniform interface, the intentions defined by each request method, and |  | uniform interface, the intentions defined by each request method, and |
| skipping to change at page 9, line 16 |  | skipping to change at page 9, line 16 |
| so that this is clear. |  | so that this is clear. |
| Due to the parsing rules defined in Section 3.3 of [Part1], |  | Due to the parsing rules defined in Section 3.3 of [Part1], |
| definitions of HTTP methods cannot prohibit the presence of a |  | definitions of HTTP methods cannot prohibit the presence of a |
| message-body on either the request or the response message (with |  | message-body on either the request or the response message (with |
| responses to HEAD requests being the single exception). Definitions |  | responses to HEAD requests being the single exception). Definitions |
| of new methods cannot change this rule, but they can specify that |  | of new methods cannot change this rule, but they can specify that |
| only zero-length bodies (as opposed to absent bodies) are allowed. |  | only zero-length bodies (as opposed to absent bodies) are allowed. |
| 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), what semantics (if any) the request body has, and |
| They also need to state whether they can be cached ([Part6]); in |  | whether they are idempotent (Section 7.1.2). They also need to state |
| particular what conditions a cache may store the response, and under |  | whether they can be cached ([Part6]); in particular what conditions a |
| what conditions such a stored response may be used to satisfy a |  | cache may store the response, and under what conditions such a stored |
| subsequent request. |  | response may be used to satisfy a 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. |
| +---------------------+------------------------+ |  | +---------------------+------------------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +---------------------+------------------------+ |  | +---------------------+------------------------+ |
| | Accept | Section 6.1 of [Part3] | |  | | Accept | Section 6.1 of [Part3] | |
| | Accept-Charset | Section 6.2 of [Part3] | |  | | Accept-Charset | Section 6.2 of [Part3] | |
| | Accept-Encoding | Section 6.3 of [Part3] | |  | | Accept-Encoding | Section 6.3 of [Part3] | |
| | Accept-Language | Section 6.4 of [Part3] | |  | | Accept-Language | Section 6.4 of [Part3] | |
| | Authorization | Section 4.1 of [Part7] | |  | | Authorization | Section 4.1 of [Part7] | |
| | Expect | Section 9.2 | |  | | Expect | Section 9.2 | |
| | From | Section 9.3 | |  | | From | Section 9.3 | |
| | Host | Section 9.4 of [Part1] | |  | | Host | Section 9.4 of [Part1] | |
| | If-Match | Section 6.2 of [Part4] | |  | | If-Match | Section 3.1 of [Part4] | |
| | If-Modified-Since | Section 6.3 of [Part4] | |  | | If-Modified-Since | Section 3.3 of [Part4] | |
| | If-None-Match | Section 6.4 of [Part4] | |  | | If-None-Match | Section 3.2 of [Part4] | |
| | If-Range | Section 5.3 of [Part5] | |  | | If-Range | Section 5.3 of [Part5] | |
| | If-Unmodified-Since | Section 6.5 of [Part4] | |  | | If-Unmodified-Since | Section 3.4 of [Part4] | |
| | Max-Forwards | Section 9.5 | |  | | Max-Forwards | Section 9.5 | |
| | Proxy-Authorization | Section 4.3 of [Part7] | |  | | Proxy-Authorization | Section 4.3 of [Part7] | |
| | Range | Section 5.4 of [Part5] | |  | | Range | Section 5.4 of [Part5] | |
| | Referer | Section 9.6 | |  | | Referer | Section 9.6 | |
| | TE | Section 9.5 of [Part1] | |  | | TE | Section 9.5 of [Part1] | |
| | User-Agent | Section 9.9 | |  | | User-Agent | Section 9.9 | |
| +---------------------+------------------------+ |  | +---------------------+------------------------+ |
| 4. Status Code and Reason Phrase |  | 4. Status Code and Reason Phrase |
| skipping to change at page 10, line 37 |  | skipping to change at page 10, line 37 |
| 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. Overview of Status Codes |  | 4.1. Overview of Status Codes |
| The status codes listed below are defined in Section 8 of this |  | The status codes listed below are defined in Section 8 of this |
| specification, Section 3 of [Part4], Section 3 of [Part5], and |  | specification, Section 4 of [Part4], Section 3 of [Part5], and |
| Section 3 of [Part7]. The reason phrases listed here are only |  | Section 3 of [Part7]. The reason phrases listed here are only |
| recommendations -- they can be replaced by local equivalents without |  | recommendations -- they can be replaced by local equivalents without |
| affecting the protocol. |  | affecting the protocol. |
| +-------------+------------------------------+----------------------+ |  | +-------------+------------------------------+----------------------+ |
| | Status-Code | Reason-Phrase | Defined in... | |  | | Status-Code | Reason-Phrase | Defined in... | |
| +-------------+------------------------------+----------------------+ |  | +-------------+------------------------------+----------------------+ |
| | 100 | Continue | Section 8.1.1 | |  | | 100 | Continue | Section 8.1.1 | |
| | 101 | Switching Protocols | Section 8.1.2 | |  | | 101 | Switching Protocols | Section 8.1.2 | |
| | 200 | OK | Section 8.2.1 | |  | | 200 | OK | Section 8.2.1 | |
| skipping to change at page 11, line 23 |  | skipping to change at page 11, line 23 |
| | 203 | Non-Authoritative | Section 8.2.4 | |  | | 203 | Non-Authoritative | Section 8.2.4 | |
| | | Information | | |  | | | Information | | |
| | 204 | No Content | Section 8.2.5 | |  | | 204 | No Content | Section 8.2.5 | |
| | 205 | Reset Content | Section 8.2.6 | |  | | 205 | Reset Content | Section 8.2.6 | |
| | 206 | Partial Content | Section 3.1 of | |  | | 206 | Partial Content | Section 3.1 of | |
| | | | [Part5] | |  | | | | [Part5] | |
| | 300 | Multiple Choices | Section 8.3.1 | |  | | 300 | Multiple Choices | Section 8.3.1 | |
| | 301 | Moved Permanently | Section 8.3.2 | |  | | 301 | Moved Permanently | Section 8.3.2 | |
| | 302 | Found | Section 8.3.3 | |  | | 302 | Found | Section 8.3.3 | |
| | 303 | See Other | Section 8.3.4 | |  | | 303 | See Other | Section 8.3.4 | |
| | 304 | Not Modified | Section 3.1 of | |  | | 304 | Not Modified | Section 4.1 of | |
| | | | [Part4] | |  | | | | [Part4] | |
| | 305 | Use Proxy | Section 8.3.6 | |  | | 305 | Use Proxy | Section 8.3.6 | |
| | 307 | Temporary Redirect | Section 8.3.8 | |  | | 307 | Temporary Redirect | Section 8.3.8 | |
| | 400 | Bad Request | Section 8.4.1 | |  | | 400 | Bad Request | Section 8.4.1 | |
| | 401 | Unauthorized | Section 3.1 of | |  | | 401 | Unauthorized | Section 3.1 of | |
| | | | [Part7] | |  | | | | [Part7] | |
| | 402 | Payment Required | Section 8.4.3 | |  | | 402 | Payment Required | Section 8.4.3 | |
| | 403 | Forbidden | Section 8.4.4 | |  | | 403 | Forbidden | Section 8.4.4 | |
| | 404 | Not Found | Section 8.4.5 | |  | | 404 | Not Found | Section 8.4.5 | |
| | 405 | Method Not Allowed | Section 8.4.6 | |  | | 405 | Method Not Allowed | Section 8.4.6 | |
| | 406 | Not Acceptable | Section 8.4.7 | |  | | 406 | Not Acceptable | Section 8.4.7 | |
| | 407 | Proxy Authentication | Section 3.2 of | |  | | 407 | Proxy Authentication | Section 3.2 of | |
| | | Required | [Part7] | |  | | | Required | [Part7] | |
| | 408 | Request Time-out | Section 8.4.9 | |  | | 408 | Request Time-out | 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 | |
| | 412 | Precondition Failed | Section 3.2 of | |  | | 412 | Precondition Failed | Section 4.2 of | |
| | | | [Part4] | |  | | | | [Part4] | |
| | 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 | |
| | 416 | Requested range not | Section 3.2 of | |  | | 416 | Requested range not | Section 3.2 of | |
| | | satisfiable | [Part5] | |  | | | satisfiable | [Part5] | |
| | 417 | Expectation Failed | Section 8.4.18 | |  | | 417 | Expectation Failed | Section 8.4.18 | |
| | 426 | Upgrade Required | Section 8.4.19 | |  | | 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 | |
| skipping to change at page 13, line 20 |  | skipping to change at page 13, line 20 |
| 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]). |
| +--------------------+------------------------+ |  | +--------------------+------------------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +--------------------+------------------------+ |  | +--------------------+------------------------+ |
| | Accept-Ranges | Section 5.1 of [Part5] | |  | | Accept-Ranges | Section 5.1 of [Part5] | |
| | Age | Section 3.1 of [Part6] | |  | | Age | Section 3.1 of [Part6] | |
| | Allow | Section 9.1 | |  | | Allow | Section 9.1 | |
| | ETag | Section 6.1 of [Part4] | |  | | ETag | Section 2.2 of [Part4] | |
| | Location | Section 9.4 | |  | | Location | Section 9.4 | |
| | Proxy-Authenticate | Section 4.2 of [Part7] | |  | | Proxy-Authenticate | Section 4.2 of [Part7] | |
| | Retry-After | Section 9.7 | |  | | Retry-After | Section 9.7 | |
| | Server | Section 9.8 | |  | | Server | Section 9.8 | |
| | Vary | Section 3.5 of [Part6] | |  | | Vary | Section 3.5 of [Part6] | |
| | WWW-Authenticate | Section 4.4 of [Part7] | |  | | WWW-Authenticate | Section 4.4 of [Part7] | |
| +--------------------+------------------------+ |  | +--------------------+------------------------+ |
| 6. Representation |  | 6. Representation |
| skipping to change at page 17, line 7 |  | skipping to change at page 17, line 7 |
| 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 request 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. |
|  |  | Bodies on GET requests have no defined semantics. Note that sending |
|  |  | a body on a GET request might cause some existing implementations to |
|  |  | reject the request. |
| 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 |
| The HEAD method is identical to GET except that the server MUST NOT |  | The HEAD method is identical to GET except that the server MUST NOT |
| return a message-body in the response. The metadata contained in the |  | return a message-body in the response. The metadata contained in the |
| HTTP header fields in response to a HEAD request SHOULD be identical |  | HTTP header fields in response to a HEAD request SHOULD be identical |
| skipping to change at page 17, line 31 |  | skipping to change at page 17, line 35 |
| accessibility, and recent modification. |  | accessibility, and recent modification. |
| 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. |
|  |  | Bodies on HEAD requests have no defined semantics. Note that sending |
|  |  | a body on a HEAD request might cause some existing implementations to |
|  |  | reject the request. |
| 7.5. POST |  | 7.5. POST |
| The POST method requests 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 |
| skipping to change at page 20, line 51 |  | skipping to change at page 21, line 12 |
| 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. |
|  |  | Bodies on DELETE requests have no defined semantics. Note that |
|  |  | sending a body on a DELETE request might cause some existing |
|  |  | implementations to reject the request. |
| Responses to the DELETE method are not cacheable. If a DELETE |  | Responses to the DELETE method are not cacheable. If a DELETE |
| request passes through a cache that has one or more stored responses |  | request passes through a cache that has one or more stored responses |
| for the effective request URI, those stored responses will be |  | for the effective request URI, those stored responses will be |
| invalidated (see Section 2.5 of [Part6]). |  | invalidated (see Section 2.5 of [Part6]). |
| 7.8. TRACE |  | 7.8. TRACE |
| The TRACE method requests a remote, application-layer loop-back of |  | The TRACE method requests a remote, application-layer loop-back of |
| the request message. The final recipient of the request SHOULD |  | the request message. The final recipient of the request SHOULD |
| reflect the message received back to the client as the message-body |  | reflect the message received back to the client as the message-body |
| skipping to change at page 22, line 9 |  | skipping to change at page 22, line 21 |
| except end-to-end protocol Upgrade requests, since the tunnel must be |  | except end-to-end protocol Upgrade requests, since the tunnel must be |
| established first. |  | established first. |
| For example, proxy authentication might be used to establish the |  | For example, proxy authentication might be used to establish the |
| authority to create a tunnel: |  | authority to create a tunnel: |
| CONNECT server.example.com:80 HTTP/1.1 |  | CONNECT server.example.com:80 HTTP/1.1 |
| Host: server.example.com:80 |  | Host: server.example.com:80 |
| Proxy-Authorization: basic aGVsbG86d29ybGQ= |  | Proxy-Authorization: basic aGVsbG86d29ybGQ= |
|  |  | Bodies on CONNECT requests have no defined semantics. Note that |
|  |  | sending a body on a CONNECT request might cause some existing |
|  |  | implementations to reject the request. |
| Like any other pipelined HTTP/1.1 request, data to be tunnel may be |  | 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: |  | sent immediately after the blank line. The usual caveats also apply: |
| data may be discarded if the eventual response is negative, and the |  | 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 |  | connection may be reset with no response if more than one TCP segment |
| is outstanding. |  | is outstanding. |
| 7.9.1. Establishing a Tunnel with CONNECT |  | 7.9.1. Establishing a Tunnel with CONNECT |
| Any successful (2xx) response to a CONNECT request indicates that the |  | Any successful (2xx) response to a CONNECT request indicates that the |
| proxy has established a connection to the requested host and port, |  | proxy has established a connection to the requested host and port, |
| skipping to change at page 24, line 35 |  | skipping to change at page 25, line 5 |
| response SHOULD include a payload containing a list of resource |  | response SHOULD include a payload containing a list of resource |
| characteristics and location(s) from which the user or user agent can |  | characteristics and location(s) from which the user or user agent can |
| choose the one most appropriate. The payload format is specified by |  | choose the one most appropriate. The payload format is specified by |
| the media type given in the Content-Type header field. The origin |  | the media type given in the Content-Type header field. The origin |
| server MUST create the resource before returning the 201 status code. |  | server MUST create the resource before returning the 201 status code. |
| If the action cannot be carried out immediately, the server SHOULD |  | If the action cannot be carried out immediately, the server SHOULD |
| respond with 202 (Accepted) response instead. |  | respond with 202 (Accepted) response instead. |
| A 201 response MAY contain an ETag response header field indicating |  | A 201 response MAY contain an ETag response header field indicating |
| the current value of the entity-tag for the representation of the |  | the current value of the entity-tag for the representation of the |
| resource just created (see Section 6.1 of [Part4]). |  | resource just created (see Section 2.2 of [Part4]). |
| 8.2.3. 202 Accepted |  | 8.2.3. 202 Accepted |
| The request has been accepted for processing, but the processing has |  | The request has been accepted for processing, but the processing has |
| not been completed. The request might or might not eventually be |  | not been completed. The request might or might not eventually be |
| acted upon, as it might be disallowed when processing actually takes |  | acted upon, as it might be disallowed when processing actually takes |
| place. There is no facility for re-sending a status code from an |  | place. There is no facility for re-sending a status code from an |
| asynchronous operation such as this. |  | asynchronous operation such as this. |
| The 202 response is intentionally non-committal. Its purpose is to |  | The 202 response is intentionally non-committal. Its purpose is to |
| skipping to change at page 25, line 21 |  | skipping to change at page 25, line 40 |
| information about the resource might result in a superset of the |  | information about the resource might result in a superset of the |
| metadata known by the origin server. Use of this response code is |  | metadata known by the origin server. Use of this response code is |
| not required and is only appropriate when the response would |  | not required and is only appropriate when the response would |
| otherwise be 200 (OK). |  | otherwise be 200 (OK). |
| 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 203 responses. |  | determine freshness for 203 responses. |
| 8.2.5. 204 No Content |  | 8.2.5. 204 No Content |
| The server has successfully fulfilled the request, but there is no |  | The 204 (No Content) status code indicates that the server has |
| additional content to return in the response payload body. The |  | successfully fulfilled the request and that there is no additional |
| resource metadata and representation metadata in the response |  | content to return in the response payload body. Metadata in the |
| message's header fields refer to the target resource and its current |  | response header fields refer to the target resource and its current |
| representation, respectively, after the requested action. For |  | representation after the requested action. |
| example, if a 204 status code is received in response to a PUT and |  |  |
| the response contains an ETag header field, then the value of that |  |  |
| field is the current entity-tag for the representation that was |  |  |
| successfully PUT. |  |  |
| If the client is a user agent, it SHOULD NOT change its document view |  | For example, if a 204 status code is received in response to a PUT |
| from that which caused the request to be sent. This response is |  | request and the response contains an ETag header field, then the PUT |
| primarily intended to allow input for actions to take place without |  | was successful and the ETag field-value contains the entity-tag for |
| causing a change to the user agent's active document view, although |  | the new representation of that target resource. |
| any new or updated metadata SHOULD be applied to the document |  |  |
| currently in the user agent's active view. |  | The 204 response allows a server to indicate that the action has been |
|  |  | successfully applied to the target resource while implying that the |
|  |  | user agent SHOULD NOT traverse away from its current "document view" |
|  |  | (if any). The server assumes that the user agent will provide some |
|  |  | indication of the success to its user, in accord with its own |
|  |  | interface, and apply any new or updated metadata in the response to |
|  |  | the active representation. For example, a 204 status code is |
|  |  | commonly used with document editing interfaces corresponding to a |
|  |  | "save" action, such that the document being saved remains available |
|  |  | to the user for editing. It is also frequently used with interfaces |
|  |  | that expect automated data transfers to be prevalent, such as within |
|  |  | distributed version control systems. |
| 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 |
| skipping to change at page 28, line 48 |  | skipping to change at page 29, line 30 |
| scope of HTTP and thus entirely determined by the URI owner(s). |  | scope of HTTP and thus entirely determined by the URI owner(s). |
| Except for responses to a HEAD request, the representation of a 303 |  | Except for responses to a HEAD request, the representation of a 303 |
| response SHOULD contain a short hypertext note with a hyperlink to |  | response SHOULD contain a short hypertext note with a hyperlink to |
| the Location URI. |  | the Location URI. |
| 8.3.5. 304 Not Modified |  | 8.3.5. 304 Not Modified |
| The response to the request has not been modified since the |  | The response to the request has not been modified since the |
| conditions indicated by the client's conditional GET request, as |  | conditions indicated by the client's conditional GET request, as |
| defined in Section 3.1 of [Part4]. |  | defined in Section 4.1 of [Part4]. |
| 8.3.6. 305 Use Proxy |  | 8.3.6. 305 Use Proxy |
| The 305 status code was defined in a previous version of this |  | The 305 status code was defined in a previous version of this |
| specification (see Appendix A), and is now deprecated. |  | specification (see Appendix A), and is now deprecated. |
| 8.3.7. 306 (Unused) |  | 8.3.7. 306 (Unused) |
| The 306 status code was used in a previous version of the |  | The 306 status code was used in a previous version of the |
| specification, is no longer used, and the code is reserved. |  | specification, is no longer used, and the code is reserved. |
| skipping to change at page 32, line 43 |  | skipping to change at page 33, line 21 |
| 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 header fields evaluated |  | The precondition given in one or more of the header fields evaluated |
| to false when it was tested on the server, as defined in Section 3.2 |  | to false when it was tested on the server, as defined in Section 4.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- |
| skipping to change at page 35, line 37 |  | skipping to change at page 36, line 17 |
| 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" header field lists the set of methods advertised as |  | The "Allow" header field lists the set of methods advertised 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 request methods associated |  | strictly to inform the recipient of valid request methods associated |
| with the resource. |  | with the resource. |
| Allow = "Allow" ":" OWS Allow-v |  | Allow = #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 -- it does not need to |  | A proxy MUST NOT modify the Allow header field -- it does not need to |
| understand all the methods specified in order to handle them |  | understand all the methods specified in order to handle them |
| according to the generic message handling rules. |  | according to the generic message handling rules. |
| 9.2. Expect |  | 9.2. Expect |
| The "Expect" header field is used to indicate that particular server |  | The "Expect" header field is used to indicate that particular server |
| behaviors are required by the client. |  | behaviors are required by the client. |
| Expect = "Expect" ":" OWS Expect-v |  | Expect = 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 |
| the expectation values in the Expect field of a request MUST respond |  | the expectation values in the Expect field of a request MUST respond |
| with appropriate error status code. The server MUST respond with a |  | with appropriate error status code. The server MUST respond with a |
| 417 (Expectation Failed) status code if any of the expectations |  | 417 (Expectation Failed) status code if any of the expectations |
| skipping to change at page 37, line 5 |  | skipping to change at page 37, line 28 |
| 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" header field, if given, SHOULD contain an Internet e-mail |  | The "From" header field, if given, SHOULD contain an Internet e-mail |
| address for the human user who controls the requesting user agent. |  | address for the human user who controls the requesting user agent. |
| The address SHOULD be machine-usable, as defined by "mailbox" in |  | The address SHOULD be machine-usable, as defined by "mailbox" in |
| Section 3.4 of [RFC5322]: |  | Section 3.4 of [RFC5322]: |
| From = "From" ":" OWS From-v |  | From = 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 |
| This header field MAY be used for logging purposes and as a means for |  | This header field MAY be used for logging purposes and as a means for |
| identifying the source of invalid or unwanted requests. It SHOULD |  | identifying the source of invalid or unwanted requests. It SHOULD |
| NOT be used as an insecure form of access protection. The |  | NOT be used as an insecure form of access protection. The |
| skipping to change at page 37, line 50 |  | skipping to change at page 38, line 23 |
| 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). |
| Location = "Location" ":" OWS Location-v |  | Location = URI-reference |
| Location-v = URI-reference |  |  |
| Examples are: |  | Examples are: |
| Location: http://www.example.org/pub/WWW/People.html#tim |  | Location: http://www.example.org/pub/WWW/People.html#tim |
| Location: /index.html |  | Location: /index.html |
| There are circumstances in which a fragment identifier in a Location |  | There are circumstances in which a fragment identifier in a Location |
| URI would not be appropriate: |  | URI would not be appropriate: |
| skipping to change at page 38, line 40 |  | skipping to change at page 39, line 13 |
| 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" header field provides a mechanism with the TRACE |  | The "Max-Forwards" header field provides a mechanism with the TRACE |
| (Section 7.8) and OPTIONS (Section 7.2) methods to limit the number |  | (Section 7.8) and OPTIONS (Section 7.2) methods to limit the number |
| of times that the request is forwarded by proxies. This can be |  | of times that the request is forwarded by proxies. This can be |
| useful when the client is attempting to trace a request which appears |  | useful when the client is attempting to trace a request 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 = 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 recipient of a TRACE or OPTIONS request containing a Max- |  | Each recipient of a TRACE or OPTIONS request containing a Max- |
| Forwards header field MUST check and update its value prior to |  | Forwards header field MUST check and update its value prior to |
| forwarding the request. If the received value is zero (0), the |  | forwarding the request. If the received value is zero (0), the |
| recipient MUST NOT forward the request; instead, it MUST respond as |  | recipient MUST NOT forward the request; instead, it MUST respond as |
| the final recipient. If the received Max-Forwards value is greater |  | the final recipient. If the received Max-Forwards value is greater |
| than zero, then the forwarded message MUST contain an updated Max- |  | than zero, then the forwarded message MUST contain an updated Max- |
| skipping to change at page 39, line 27 |  | skipping to change at page 39, line 48 |
| 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 |
| field MUST either be sent with the value "about:blank", or not be |  | field MUST either be sent with the value "about:blank", or not be |
| sent at all. Note that this requirement does not apply to sources |  | sent at all. Note that this requirement does not apply to sources |
| with non-HTTP URIs (e.g., FTP). |  | with non-HTTP URIs (e.g., FTP). |
| Referer = "Referer" ":" OWS Referer-v |  | Referer = absolute-URI / partial-URI |
| Referer-v = absolute-URI / partial-URI |  |  |
| Example: |  | Example: |
| Referer: http://www.example.org/hypertext/Overview.html |  | Referer: http://www.example.org/hypertext/Overview.html |
| If the field value is a relative URI, it SHOULD be interpreted |  | If the field value is a relative URI, it SHOULD be interpreted |
| relative to the 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 header "Retry-After" field can be used with a 503 (Service |  | The header "Retry-After" field can be used with a 503 (Service |
| Unavailable) response to indicate how long the service is expected to |  | Unavailable) response to indicate how long the service is expected to |
| be unavailable to the requesting client. This field MAY also be used |  | be unavailable to the requesting client. This field MAY also be used |
| with any 3xx (Redirection) response to indicate the minimum time the |  | with any 3xx (Redirection) response to indicate the minimum time the |
| user-agent is asked wait before issuing the redirected request. |  | user-agent is asked wait before issuing the 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 = 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. |
| delta-seconds = 1*DIGIT |  | delta-seconds = 1*DIGIT |
| Two examples of its use are |  | Two examples of its use are |
| Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |  | Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |
| Retry-After: 120 |  | Retry-After: 120 |
| skipping to change at page 40, line 25 |  | skipping to change at page 40, line 44 |
| 9.8. Server |  | 9.8. Server |
| The "Server" header field contains information about the software |  | The "Server" header field contains information about the 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 = product *( RWS ( product / comment ) ) |
| Server-v = product |  |  |
| *( 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 header field. Instead, it |  | application MUST NOT modify the Server header field. Instead, it |
| MUST include a Via field (as described in Section 9.9 of [Part1]). |  | MUST include a Via field (as described in Section 9.9 of [Part1]). |
| Note: Revealing the specific software version of the server might |  | Note: Revealing the specific software version of the server might |
| skipping to change at page 41, line 24 |  | skipping to change at page 41, line 40 |
| subproducts by third parties. Overly long and detailed User-Agent |  | subproducts by third parties. Overly long and detailed User-Agent |
| 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 = product *( RWS ( product / comment ) ) |
| User-Agent-v = product *( 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 request methods is defined by |  | The registration procedure for HTTP request methods is defined by |
| skipping to change at page 46, line 34 |  | skipping to change at page 46, line 34 |
| 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-13 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-14 |
| (work in progress), March 2011. |  | (work in progress), April 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-13 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-14 |
| (work in progress), March 2011. |  | (work in progress), April 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-13 (work in |  | Requests", draft-ietf-httpbis-p4-conditional-14 (work in |
| progress), March 2011. |  | progress), April 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-13 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-14 (work |
| in progress), March 2011. |  | in progress), April 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-13 (work in |  | 6: Caching", draft-ietf-httpbis-p6-cache-14 (work in |
| progress), March 2011. |  | progress), April 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-13 (work in progress), |  | draft-ietf-httpbis-p7-auth-14 (work in progress), |
| March 2011. |  | April 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 48, line 37 |  | skipping to change at page 48, line 37 |
| 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 |  | Define status 426 (Upgrade Required) (this was incorporated from |
| [RFC2817]). (Section 8.4.19) |  | [RFC2817]). (Section 8.4.19) |
|  |  | Change ABNF productions for header fields to only define the field |
|  |  | value. (Section 9) |
| 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) |
| skipping to change at page 48, line 49 |  | skipping to change at page 49, line 4 |
| 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, |  | Restrict Max-Forwards header field to OPTIONS and TRACE (previously, |
| extension methods could have used it as well). (Section 9.5) |  | 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 |
|  |  | Allow = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] |
| Allow = "Allow:" OWS Allow-v |  | Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) |
| Allow-v = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] |  |  |
| Expect = "Expect:" OWS Expect-v |  |  |
| Expect-v = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) |  |  |
| From = "From:" OWS From-v |  | From = mailbox |
| From-v = mailbox |  |  |
| HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |  | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |
| Location = "Location:" OWS Location-v |  | Location = URI-reference |
| Location-v = URI-reference |  |  |
| Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v |  | Max-Forwards = 1*DIGIT |
| Max-Forwards-v = 1*DIGIT |  |  |
| Method = token |  | Method = token |
| 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> |
| Reason-Phrase = *( WSP / VCHAR / obs-text ) |  | Reason-Phrase = *( WSP / VCHAR / obs-text ) |
| Referer = "Referer:" OWS Referer-v |  | Referer = absolute-URI / partial-URI |
| Referer-v = absolute-URI / partial-URI |  | Retry-After = HTTP-date / delta-seconds |
| Retry-After = "Retry-After:" OWS Retry-After-v |  |  |
| Retry-After-v = HTTP-date / delta-seconds |  |  |
| Server = "Server:" OWS Server-v |  | Server = product *( RWS ( product / comment ) ) |
| Server-v = product *( RWS ( product / comment ) ) |  |  |
| Status-Code = 3DIGIT |  | Status-Code = 3DIGIT |
| 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 = product *( RWS ( product / comment ) ) |
| User-Agent-v = product *( RWS ( product / comment ) ) |  |  |
| 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 ] |
| 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> |
| skipping to change at page 57, line 14 |  | skipping to change at page 57, line 41 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/226>: "proxies not |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/226>: "proxies not |
| supporting certain methods" |  | supporting certain methods" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/239>: "Migrate |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/239>: "Migrate |
| CONNECT from RFC2817 to p2" |  | CONNECT from RFC2817 to p2" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate |
| Upgrade details from RFC2817" |  | Upgrade details from RFC2817" |
| o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/267>: "clarify |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/267>: "clarify PUT |
| PUT semantics'" |  | semantics'" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/275>: "duplicate |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/275>: "duplicate |
| ABNF for 'Method'" |  | ABNF for 'Method'" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
| ABNFs for header fields" |  | ABNFs for header fields" |
|  |  | C.15. Since draft-ietf-httpbis-p2-semantics-13 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
|  |  | ABNFs for header fields" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/251>: "message-body |
|  |  | in CONNECT request" |
| Index |  | Index |
| 1 |  | 1 |
| 100 Continue (status code) 23 |  | 100 Continue (status code) 23 |
| 101 Switching Protocols (status code) 23 |  | 101 Switching Protocols (status code) 23 |
| 2 |  | 2 |
| 200 OK (status code) 23 |  | 200 OK (status code) 24 |
| 201 Created (status code) 24 |  | 201 Created (status code) 24 |
| 202 Accepted (status code) 24 |  | 202 Accepted (status code) 25 |
| 203 Non-Authoritative Information (status code) 25 |  | 203 Non-Authoritative Information (status code) 25 |
| 204 No Content (status code) 25 |  | 204 No Content (status code) 25 |
| 205 Reset Content (status code) 25 |  | 205 Reset Content (status code) 26 |
| 206 Partial Content (status code) 26 |  | 206 Partial Content (status code) 26 |
| 3 |  | 3 |
| 300 Multiple Choices (status code) 26 |  | 300 Multiple Choices (status code) 27 |
| 301 Moved Permanently (status code) 27 |  | 301 Moved Permanently (status code) 27 |
| 302 Found (status code) 27 |  | 302 Found (status code) 28 |
| 303 See Other (status code) 28 |  | 303 See Other (status code) 28 |
| 304 Not Modified (status code) 28 |  | 304 Not Modified (status code) 29 |
| 305 Use Proxy (status code) 29 |  | 305 Use Proxy (status code) 29 |
| 306 (Unused) (status code) 29 |  | 306 (Unused) (status code) 29 |
| 307 Temporary Redirect (status code) 29 |  | 307 Temporary Redirect (status code) 29 |
| 4 |  | 4 |
| 400 Bad Request (status code) 30 |  | 400 Bad Request (status code) 30 |
| 401 Unauthorized (status code) 30 |  | 401 Unauthorized (status code) 30 |
| 402 Payment Required (status code) 30 |  | 402 Payment Required (status code) 30 |
| 403 Forbidden (status code) 30 |  | 403 Forbidden (status code) 30 |
| 404 Not Found (status code) 30 |  | 404 Not Found (status code) 31 |
| 405 Method Not Allowed (status code) 30 |  | 405 Method Not Allowed (status code) 31 |
| 406 Not Acceptable (status code) 30 |  | 406 Not Acceptable (status code) 31 |
| 407 Proxy Authentication Required (status code) 31 |  | 407 Proxy Authentication Required (status code) 32 |
| 408 Request Timeout (status code) 31 |  | 408 Request Timeout (status code) 32 |
| 409 Conflict (status code) 31 |  | 409 Conflict (status code) 32 |
| 410 Gone (status code) 32 |  | 410 Gone (status code) 32 |
| 411 Length Required (status code) 32 |  | 411 Length Required (status code) 33 |
| 412 Precondition Failed (status code) 32 |  | 412 Precondition Failed (status code) 33 |
| 413 Request Entity Too Large (status code) 32 |  | 413 Request Entity Too Large (status code) 33 |
| 414 URI Too Long (status code) 33 |  | 414 URI Too Long (status code) 33 |
| 415 Unsupported Media Type (status code) 33 |  | 415 Unsupported Media Type (status code) 33 |
| 416 Requested Range Not Satisfiable (status code) 33 |  | 416 Requested Range Not Satisfiable (status code) 34 |
| 417 Expectation Failed (status code) 33 |  | 417 Expectation Failed (status code) 34 |
| 426 Upgrade Required (status code) 33 |  | 426 Upgrade Required (status code) 34 |
| 5 |  | 5 |
| 500 Internal Server Error (status code) 34 |  | 500 Internal Server Error (status code) 34 |
| 501 Not Implemented (status code) 34 |  | 501 Not Implemented (status code) 35 |
| 502 Bad Gateway (status code) 34 |  | 502 Bad Gateway (status code) 35 |
| 503 Service Unavailable (status code) 34 |  | 503 Service Unavailable (status code) 35 |
| 504 Gateway Timeout (status code) 35 |  | 504 Gateway Timeout (status code) 35 |
| 505 HTTP Version Not Supported (status code) 35 |  | 505 HTTP Version Not Supported (status code) 35 |
| A |  | A |
| Allow header field 35 |  | Allow header field 36 |
| C |  | C |
| CONNECT method 21 |  | CONNECT method 21 |
| D |  | D |
| DELETE method 20 |  | DELETE method 20 |
| E |  | E |
| Expect header field 36 |  | Expect header field 36 |
| F |  | F |
| From header field 36 |  | From header field 37 |
| G |  | G |
| GET method 16 |  | GET method 16 |
| Grammar |  | Grammar |
| Allow 35 |  | Allow 36 |
| Allow-v 35 |  |  |
| delta-seconds 40 |  | delta-seconds 40 |
| Expect 36 |  | Expect 36 |
| expect-params 36 |  | expect-params 36 |
| Expect-v 36 |  |  |
| expectation 36 |  | expectation 36 |
| expectation-extension 36 |  | expectation-extension 36 |
| extension-code 10 |  | extension-code 10 |
| From 37 |  | From 37 |
| From-v 37 |  | Location 38 |
| Location 37 |  | Max-Forwards 39 |
| Location-v 37 |  |  |
| Max-Forwards 38 |  |  |
| Max-Forwards-v 38 |  |  |
| Method 7 |  | Method 7 |
| Reason-Phrase 10 |  | Reason-Phrase 10 |
| Referer 39 |  | Referer 39 |
| Referer-v 39 |  | Retry-After 40 |
| Retry-After 39 |  |  |
| Retry-After-v 39 |  |  |
| Server 40 |  | Server 40 |
| Server-v 40 |  |  |
| Status-Code 10 |  | Status-Code 10 |
| User-Agent 41 |  | User-Agent 41 |
| User-Agent-v 41 |  |  |
| H |  | H |
| HEAD method 17 |  | HEAD method 17 |
| Header Fields |  | Header Fields |
| Allow 35 |  | Allow 36 |
| Expect 36 |  | Expect 36 |
| From 36 |  | From 37 |
| Location 37 |  | Location 38 |
| Max-Forwards 38 |  | Max-Forwards 39 |
| Referer 39 |  | Referer 39 |
| Retry-After 39 |  | Retry-After 40 |
| Server 40 |  | Server 40 |
| User-Agent 40 |  | User-Agent 41 |
| I |  | I |
| Idempotent Methods 15 |  | Idempotent Methods 15 |
| L |  | L |
| Location header field 37 |  | Location header field 38 |
| M |  | M |
| Max-Forwards header field 38 |  | Max-Forwards header field 39 |
| Methods |  | Methods |
| CONNECT 21 |  | CONNECT 21 |
| DELETE 20 |  | DELETE 20 |
| GET 16 |  | GET 16 |
| HEAD 17 |  | HEAD 17 |
| OPTIONS 15 |  | OPTIONS 15 |
| POST 17 |  | POST 17 |
| PUT 18 |  | PUT 18 |
| TRACE 21 |  | 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 field 39 |  | Referer header field 39 |
| Retry-After header field 39 |  | Retry-After header field 40 |
| S |  | S |
| Safe Methods 14 |  | Safe Methods 14 |
| Server header field 40 |  | Server header field 40 |
| Status Codes |  | Status Codes |
| 100 Continue 23 |  | 100 Continue 23 |
| 101 Switching Protocols 23 |  | 101 Switching Protocols 23 |
| 200 OK 23 |  | 200 OK 24 |
| 201 Created 24 |  | 201 Created 24 |
| 202 Accepted 24 |  | 202 Accepted 25 |
| 203 Non-Authoritative Information 25 |  | 203 Non-Authoritative Information 25 |
| 204 No Content 25 |  | 204 No Content 25 |
| 205 Reset Content 25 |  | 205 Reset Content 26 |
| 206 Partial Content 26 |  | 206 Partial Content 26 |
| 300 Multiple Choices 26 |  | 300 Multiple Choices 27 |
| 301 Moved Permanently 27 |  | 301 Moved Permanently 27 |
| 302 Found 27 |  | 302 Found 28 |
| 303 See Other 28 |  | 303 See Other 28 |
| 304 Not Modified 28 |  | 304 Not Modified 29 |
| 305 Use Proxy 29 |  | 305 Use Proxy 29 |
| 306 (Unused) 29 |  | 306 (Unused) 29 |
| 307 Temporary Redirect 29 |  | 307 Temporary Redirect 29 |
| 400 Bad Request 30 |  | 400 Bad Request 30 |
| 401 Unauthorized 30 |  | 401 Unauthorized 30 |
| 402 Payment Required 30 |  | 402 Payment Required 30 |
| 403 Forbidden 30 |  | 403 Forbidden 30 |
| 404 Not Found 30 |  | 404 Not Found 31 |
| 405 Method Not Allowed 30 |  | 405 Method Not Allowed 31 |
| 406 Not Acceptable 30 |  | 406 Not Acceptable 31 |
| 407 Proxy Authentication Required 31 |  | 407 Proxy Authentication Required 32 |
| 408 Request Timeout 31 |  | 408 Request Timeout 32 |
| 409 Conflict 31 |  | 409 Conflict 32 |
| 410 Gone 32 |  | 410 Gone 32 |
| 411 Length Required 32 |  | 411 Length Required 33 |
| 412 Precondition Failed 32 |  | 412 Precondition Failed 33 |
| 413 Request Entity Too Large 32 |  | 413 Request Entity Too Large 33 |
| 414 URI Too Long 33 |  | 414 URI Too Long 33 |
| 415 Unsupported Media Type 33 |  | 415 Unsupported Media Type 33 |
| 416 Requested Range Not Satisfiable 33 |  | 416 Requested Range Not Satisfiable 34 |
| 417 Expectation Failed 33 |  | 417 Expectation Failed 34 |
| 426 Upgrade Required 33 |  | 426 Upgrade Required 34 |
| 500 Internal Server Error 34 |  | 500 Internal Server Error 34 |
| 501 Not Implemented 34 |  | 501 Not Implemented 35 |
| 502 Bad Gateway 34 |  | 502 Bad Gateway 35 |
| 503 Service Unavailable 34 |  | 503 Service Unavailable 35 |
| 504 Gateway Timeout 35 |  | 504 Gateway Timeout 35 |
| 505 HTTP Version Not Supported 35 |  | 505 HTTP Version Not Supported 35 |
| T |  | T |
| TRACE method 21 |  | TRACE method 21 |
| U |  | U |
| User-Agent header field 40 |  | User-Agent header field 41 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Adobe Systems Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| EMail: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
End of changes. 110 change blocks.
| 200 lines changed or deleted |  | 213 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/