| draft-ietf-httpbis-p2-semantics-11.txt |  | draft-ietf-httpbis-p2-semantics-12.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Updates: 2817 (if approved) Alcatel-Lucent |  | Updates: 2817 (if approved) Alcatel-Lucent |
| Intended status: Standards Track J. Mogul |  | Intended status: Standards Track J. Mogul |
| Expires: February 5, 2011 HP |  | Expires: April 28, 2011 HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe Systems |  | Adobe Systems |
| P. Leach |  | P. Leach |
| Microsoft |  | Microsoft |
| T. Berners-Lee |  | T. Berners-Lee |
| W3C/MIT |  | W3C/MIT |
| Y. Lafon, Ed. |  | Y. Lafon, Ed. |
| W3C |  | W3C |
| J. Reschke, Ed. |  | J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| August 4, 2010 |  | October 25, 2010 |
| HTTP/1.1, part 2: Message Semantics |  | HTTP/1.1, part 2: Message Semantics |
| draft-ietf-httpbis-p2-semantics-11 |  | draft-ietf-httpbis-p2-semantics-12 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypermedia information |  | protocol for distributed, collaborative, hypermedia information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| information initiative since 1990. This document is Part 2 of the |  | information initiative since 1990. This document is Part 2 of the |
| seven-part specification that defines the protocol referred to as |  | seven-part specification that defines the protocol referred to as |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines |
| the semantics of HTTP messages as expressed by request methods, |  | the semantics of HTTP messages as expressed by request methods, |
| skipping to change at page 1, line 46 |  | skipping to change at page 1, line 46 |
| 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.12. |  | The changes in this draft are summarized in Appendix C.13. |
| 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 February 5, 2011. |  | This Internet-Draft will expire on April 28, 2011. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2010 IETF Trust and the persons identified as the |  | Copyright (c) 2010 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 8 |  | skipping to change at page 3, line 8 |
| 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 |
| 2.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 8 |  | 2.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 8 |
|  |  | 2.1.1. Considerations for New Methods . . . . . . . . . . . . 9 |
| 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. Status Code Registry . . . . . . . . . . . . . . . . . . . 12 |
| 5. Response Header Fields . . . . . . . . . . . . . . . . . . . . 12 |  | 4.1.1. Considerations for New Status Codes . . . . . . . . . 12 |
|  |  | 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 . . . . . . . . . . . . . . . . . . . . . . 13 |  | Representation . . . . . . . . . . . . . . . . . . . . . . 14 |
| 7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 14 |  | 7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 14 |
| 7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 14 |  | 7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 15 |
| 7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 14 |  | 7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 15 |
| 7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 14 |  | 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 20 |  | 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 20 |
| 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 20 |  | 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 20 |
| 8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 20 |  | 8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 21 |
| 8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 21 |  | 8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 21 |
| 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 21 |  | 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 21 |
| 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 21 |  | 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 22 |
| 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 21 |  | 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 22 |
| 8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 22 |  | 8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 22 |
| 8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 22 |  | 8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 23 |
| 8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 22 |  | 8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 23 |
| 8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 23 |  | 8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 23 |
| 8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 23 |  | 8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 24 |
| 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 23 |  | 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 24 |
| 8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 24 |  | 8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 24 |
| 8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 24 |  | 8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 25 |
| 8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 25 |  | 8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 25 |
| 8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 25 |  | 8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 26 |
| 8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 26 |  | 8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 26 |
| 8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 26 |  | 8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 27 |
| 8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 26 |  | 8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 27 |
| 8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 26 |  | 8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 27 |
| 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 27 |  | 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 27 |
| 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 27 |  | 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 28 |
| 8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 27 |  | 8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 28 |
| 8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 27 |  | 8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 28 |
| 8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 27 |  | 8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 28 |
| 8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 28 |  | 8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 28 |
| 8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 28 |  | 8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 28 |
| 8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 28 |  | 8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 28 |
| 8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 28 |  | 8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 29 |
| 8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 29 |  | 8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 29 |
| 8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 29 |  | 8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 29 |
| 8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 30 |
| 8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 30 |  | 8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 30 |
| 8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 30 |  | 8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 30 |
| 8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 30 |  | 8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 30 |
| 8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 30 |  | 8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 31 |
| 8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 30 |  | 8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 31 |
| 8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 30 |  | 8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 31 |
| 8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 31 |  | 8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 31 |
| 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 31 |  | 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 31 |
| 8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 31 |  | 8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 32 |
| 8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 31 |  | 8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 32 |
| 8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 31 |  | 8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 32 |
| 8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 31 |  | 8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 32 |
| 8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 32 |  | 8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 32 |
| 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 32 |  | 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 32 |
| 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 32 |  | 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 33 |
| 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 |
| 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 34 |  | 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 35 |
| 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 35 |  | 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 36 |
| 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 36 |  | 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 36 |
| 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 36 |  | 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 37 |
| 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 37 |  | 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 37 |
| 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 37 |  | 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 38 |
| 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 |  | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 |
| 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 38 |  | 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 39 |
| 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 38 |  | 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 39 |
| 10.3. Header Field Registration . . . . . . . . . . . . . . . . 39 |  | 10.3. Header Field Registration . . . . . . . . . . . . . . . . 40 |
| 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 |  | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 |
| 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 40 |  | 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 41 |
| 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 41 |  | 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 42 |
| 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 42 |  | 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 43 |
| 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 |  | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 |
| 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |  | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 |
| 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42 |  | 13.1. Normative References . . . . . . . . . . . . . . . . . . . 43 |
| 13.2. Informative References . . . . . . . . . . . . . . . . . . 43 |  | 13.2. Informative References . . . . . . . . . . . . . . . . . . 44 |
| Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 43 |  | Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 44 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 44 |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 45 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 47 |  | publication) . . . . . . . . . . . . . . . . . . . . 48 |
|  |  | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 48 |
| C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 47 |  | C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 48 |
| C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 47 |  | C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 49 |
| C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 47 |  | C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 49 |
| C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 48 |  | C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 50 |
| C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 49 |  | C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 50 |
| C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 49 |  | C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 51 |
| C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 49 |  | C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 51 |
| C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 50 |  | C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 51 |
| C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 50 |  | C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 52 |
| C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 51 |  | C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 52 |
| C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 51 |  | C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 52 |
| C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 51 |  | C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 53 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 |
| 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. The next 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, general header fields, methods, |
| request modifiers, response status, and resource metadata. The |  | request modifiers, response status, and resource metadata. The |
| current mess reflects how widely dispersed these topics and |  | current mess reflects how widely dispersed these topics and |
| associated requirements had become in [RFC2616]. |  | 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", |
| skipping to change at page 8, line 7 |  | skipping to change at page 8, line 7 |
| If-None-Match = <If-None-Match, defined in [Part4], Section 6.4> |  | If-None-Match = <If-None-Match, defined in [Part4], Section 6.4> |
| If-Unmodified-Since = |  | If-Unmodified-Since = |
| <If-Unmodified-Since, defined in [Part4], Section 6.5> |  | <If-Unmodified-Since, defined in [Part4], Section 6.5> |
| Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 5.1> |  | Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 5.1> |
| If-Range = <If-Range, defined in [Part5], Section 5.3> |  | If-Range = <If-Range, defined in [Part5], Section 5.3> |
| Range = <Range, defined in [Part5], Section 5.4> |  | Range = <Range, defined in [Part5], Section 5.4> |
| Age = <Age, defined in [Part6], Section 3.1> |  | Age = <Age, defined in [Part6], Section 3.1> |
| Vary = <Vary, defined in [Part6], Section 3.5> |  | Vary = <Vary, defined in [Part6], Section 3.5> |
| Authorization = <Authorization, defined in [Part7], Section 3.1> |  | Authorization = <Authorization, defined in [Part7], Section 4.1> |
| Proxy-Authenticate = |  | Proxy-Authenticate = |
| <Proxy-Authenticate, defined in [Part7], Section 3.2> |  | <Proxy-Authenticate, defined in [Part7], Section 4.2> |
| Proxy-Authorization = |  | Proxy-Authorization = |
| <Proxy-Authorization, defined in [Part7], Section 3.3> |  | <Proxy-Authorization, defined in [Part7], Section 4.3> |
| WWW-Authenticate = |  | WWW-Authenticate = |
| <WWW-Authenticate, defined in [Part7], Section 3.4> |  | <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 method to be performed on the target |
| resource (Section 4.3 of [Part1]). The method is case-sensitive. |  | resource (Section 4.3 of [Part1]). The method is case-sensitive. |
| Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 7.2 |  | Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 7.2 |
| / %x47.45.54 ; "GET", Section 7.3 |  | / %x47.45.54 ; "GET", Section 7.3 |
| / %x48.45.41.44 ; "HEAD", Section 7.4 |  | / %x48.45.41.44 ; "HEAD", Section 7.4 |
| / %x50.4F.53.54 ; "POST", Section 7.5 |  | / %x50.4F.53.54 ; "POST", Section 7.5 |
| skipping to change at page 9, line 17 |  | skipping to change at page 9, line 17 |
| 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 |
|  |  | 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 |
|  |  | defined methods are inadequate, it may be appropriate to register a |
|  |  | new method. |
|  |  | HTTP methods are generic; that is, they are potentially applicable to |
|  |  | any resource, not just one particular media type, "type" of resource, |
|  |  | or application. As such, it is preferred that new HTTP methods be |
|  |  | registered in a document that isn't specific to a single application, |
|  |  | so that this is clear. |
|  |  | Due to the parsing rules defined in Section 3.3 of [Part1], |
|  |  | definitions of HTTP methods cannot prohibit the presence of a |
|  |  | message-body on either the request or the response message (with |
|  |  | responses to HEAD requests being the single exception). Definitions |
|  |  | of new methods cannot change this rule, but they can specify that |
|  |  | only zero-length bodies (as opposed to absent bodies) are allowed. |
|  |  | New method definitions need to indicate whether they are safe |
|  |  | (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 |
|  |  | particular what conditions a cache may store the response, and under |
|  |  | what conditions such a stored 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. |
| request-header = Accept ; [Part3], Section 6.1 |  | request-header = Accept ; [Part3], Section 6.1 |
| / Accept-Charset ; [Part3], Section 6.2 |  | / Accept-Charset ; [Part3], Section 6.2 |
| / Accept-Encoding ; [Part3], Section 6.3 |  | / Accept-Encoding ; [Part3], Section 6.3 |
| / Accept-Language ; [Part3], Section 6.4 |  | / Accept-Language ; [Part3], Section 6.4 |
| / Authorization ; [Part7], Section 3.1 |  | / Authorization ; [Part7], Section 4.1 |
| / Expect ; Section 9.2 |  | / Expect ; Section 9.2 |
| / From ; Section 9.3 |  | / From ; Section 9.3 |
| / Host ; [Part1], Section 9.4 |  | / Host ; [Part1], Section 9.4 |
| / If-Match ; [Part4], Section 6.2 |  | / If-Match ; [Part4], Section 6.2 |
| / If-Modified-Since ; [Part4], Section 6.3 |  | / If-Modified-Since ; [Part4], Section 6.3 |
| / If-None-Match ; [Part4], Section 6.4 |  | / If-None-Match ; [Part4], Section 6.4 |
| / If-Range ; [Part5], Section 5.3 |  | / If-Range ; [Part5], Section 5.3 |
| / If-Unmodified-Since ; [Part4], Section 6.5 |  | / If-Unmodified-Since ; [Part4], Section 6.5 |
| / Max-Forwards ; Section 9.5 |  | / Max-Forwards ; Section 9.5 |
| / Proxy-Authorization ; [Part7], Section 3.3 |  | / Proxy-Authorization ; [Part7], Section 4.3 |
| / Range ; [Part5], Section 5.4 |  | / Range ; [Part5], Section 5.4 |
| / Referer ; Section 9.6 |  | / Referer ; Section 9.6 |
| / TE ; [Part1], Section 9.5 |  | / TE ; [Part1], Section 9.5 |
| / User-Agent ; Section 9.9 |  | / User-Agent ; Section 9.9 |
| Request-header field names can be extended reliably only in |  | Request-header field names can be extended reliably only in |
| combination with a change in the protocol version. However, new or |  | combination with a change in the protocol version. However, new or |
| experimental header fields MAY be given the semantics of request- |  | experimental header fields MAY be given the semantics of request- |
| header fields if all parties in the communication recognize them to |  | header fields if all parties in the communication recognize them to |
| be request-header fields. |  | 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. The status codes |
| listed below are defined in Section 8, Section 3 of [Part4], Section |  | listed below are defined in Section 8, Section 3 of [Part4], Section |
| 3 of [Part5], and Section 2 of [Part7]. |  | 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. The Status-Code is intended for use by automata and |
| the Reason-Phrase is intended for the human user. The client is not |  | the Reason-Phrase is intended for the human user. The client is not |
| required 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 |  | The individual values of the numeric status codes defined for |
| HTTP/1.1, and an example set of corresponding Reason-Phrase values, |  | HTTP/1.1, and an example set of corresponding Reason-Phrase values, |
| are presented below. The reason phrases listed here are only |  | are presented below. The reason phrases listed here are only |
| recommendations -- they MAY be replaced by local equivalents without |  | recommendations -- they MAY be replaced by local equivalents without |
| skipping to change at page 11, line 23 |  | skipping to change at page 11, line 23 |
| / "205" ; Section 8.2.6: Reset Content |  | / "205" ; Section 8.2.6: Reset Content |
| / "206" ; [Part5], Section 3.1: Partial Content |  | / "206" ; [Part5], Section 3.1: Partial Content |
| / "300" ; Section 8.3.1: Multiple Choices |  | / "300" ; Section 8.3.1: Multiple Choices |
| / "301" ; Section 8.3.2: Moved Permanently |  | / "301" ; Section 8.3.2: Moved Permanently |
| / "302" ; Section 8.3.3: Found |  | / "302" ; Section 8.3.3: Found |
| / "303" ; Section 8.3.4: See Other |  | / "303" ; Section 8.3.4: See Other |
| / "304" ; [Part4], Section 3.1: Not Modified |  | / "304" ; [Part4], Section 3.1: Not Modified |
| / "305" ; Section 8.3.6: Use Proxy |  | / "305" ; Section 8.3.6: Use Proxy |
| / "307" ; Section 8.3.8: Temporary Redirect |  | / "307" ; Section 8.3.8: Temporary Redirect |
| / "400" ; Section 8.4.1: Bad Request |  | / "400" ; Section 8.4.1: Bad Request |
| / "401" ; [Part7], Section 2.1: Unauthorized |  | / "401" ; [Part7], Section 3.1: Unauthorized |
| / "402" ; Section 8.4.3: Payment Required |  | / "402" ; Section 8.4.3: Payment Required |
| / "403" ; Section 8.4.4: Forbidden |  | / "403" ; Section 8.4.4: Forbidden |
| / "404" ; Section 8.4.5: Not Found |  | / "404" ; Section 8.4.5: Not Found |
| / "405" ; Section 8.4.6: Method Not Allowed |  | / "405" ; Section 8.4.6: Method Not Allowed |
| / "406" ; Section 8.4.7: Not Acceptable |  | / "406" ; Section 8.4.7: Not Acceptable |
| / "407" ; [Part7], Section 2.2: Proxy Authentication Required |  | / "407" ; [Part7], Section 3.2: Proxy Authentication Required |
| / "408" ; Section 8.4.9: Request Time-out |  | / "408" ; Section 8.4.9: Request Time-out |
| / "409" ; Section 8.4.10: Conflict |  | / "409" ; Section 8.4.10: Conflict |
| / "410" ; Section 8.4.11: Gone |  | / "410" ; Section 8.4.11: Gone |
| / "411" ; Section 8.4.12: Length Required |  | / "411" ; Section 8.4.12: Length Required |
| / "412" ; [Part4], Section 3.2: Precondition Failed |  | / "412" ; [Part4], Section 3.2: Precondition Failed |
| / "413" ; Section 8.4.14: Request Entity Too Large |  | / "413" ; Section 8.4.14: Request Entity Too Large |
| / "414" ; Section 8.4.15: URI Too Long |  | / "414" ; Section 8.4.15: URI Too Long |
| / "415" ; Section 8.4.16: Unsupported Media Type |  | / "415" ; Section 8.4.16: Unsupported Media Type |
| / "416" ; [Part5], Section 3.2: Requested range not satisfiable |  | / "416" ; [Part5], Section 3.2: Requested range not satisfiable |
| / "417" ; Section 8.4.18: Expectation Failed |  | / "417" ; Section 8.4.18: Expectation Failed |
| skipping to change at page 12, line 28 |  | skipping to change at page 12, line 28 |
| 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 |
|  |  | When it is necessary to express new semantics for a HTTP response |
|  |  | that aren't specific to a single application or media type, and |
|  |  | currently defined status codes are inadequate, a new status code can |
|  |  | be registered. |
|  |  | HTTP status codes are generic; that is, they are potentially |
|  |  | applicable to any resource, not just one particular media type, |
|  |  | "type" of resource, or application. As such, it is preferred that |
|  |  | new HTTP status codes be registered in a document that isn't specific |
|  |  | to a single application, so that this is clear. |
|  |  | Definitions of new HTTP status codes typically explain the request |
|  |  | conditions that produce a response containing the status code (e.g., |
|  |  | combinations of request headers and/or method(s)), along with any |
|  |  | interactions with response headers (e.g., those that are required, |
|  |  | those that modify the semantics of the response). |
|  |  | New HTTP status codes are required to fall under one of the |
|  |  | categories defined in Section 8. To allow existing parsers to |
|  |  | properly handle them, new status codes cannot disallow a response |
|  |  | body, although they can mandate a zero-length response body. They |
|  |  | can require the presence of one or more particular HTTP response |
|  |  | header(s). |
|  |  | Likewise, their definitions can specify that caches are allowed to |
|  |  | use heuristics to determine their freshness (see [Part6]; by default, |
|  |  | it is not allowed), and can define how to determine the resource |
|  |  | which they carry a representation for (see Section 6.1; by default, |
|  |  | 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 |  | response-header = Accept-Ranges ; [Part5], Section 5.1 |
| / Age ; [Part6], Section 3.1 |  | / Age ; [Part6], Section 3.1 |
| / Allow ; Section 9.1 |  | / Allow ; Section 9.1 |
| / ETag ; [Part4], Section 6.1 |  | / ETag ; [Part4], Section 6.1 |
| / Location ; Section 9.4 |  | / Location ; Section 9.4 |
| / Proxy-Authenticate ; [Part7], Section 3.2 |  | / Proxy-Authenticate ; [Part7], Section 4.2 |
| / Retry-After ; Section 9.7 |  | / Retry-After ; Section 9.7 |
| / Server ; Section 9.8 |  | / Server ; Section 9.8 |
| / Vary ; [Part6], Section 3.5 |  | / Vary ; [Part6], Section 3.5 |
| / WWW-Authenticate ; [Part7], Section 3.4 |  | / WWW-Authenticate ; [Part7], Section 4.4 |
| Response-header field names can be extended reliably only in |  | Response-header field names can be extended reliably only in |
| combination with a change in the protocol version. However, new or |  | combination with a change in the protocol version. However, new or |
| experimental header fields MAY be given the semantics of response- |  | experimental header fields MAY be given the semantics of response- |
| header fields if all parties in the communication recognize them to |  | header fields if all parties in the communication recognize them to |
| be response-header fields. |  | 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 |
| skipping to change at page 13, line 43 |  | skipping to change at page 14, line 27 |
| 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 (see Section 2.8 of [Part6]). |
| 3. If the response has a Content-Location header, and that URI is |  | 3. If the response has a Content-Location header field, and that URI |
| the same as the effective request URI, the response payload is a |  | is the same as the effective request URI, the response payload is |
| representation of the target resource. |  | a representation of the target resource. |
| 4. If the response has a Content-Location header, and that URI is |  | 4. If the response has a Content-Location header field, and that URI |
| 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 |
| means (not defined by HTTP). |  | means (not defined by HTTP). |
| 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 |
| skipping to change at page 16, line 42 |  | skipping to change at page 17, line 24 |
| 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 headers in response to a HEAD request SHOULD be identical to the |  | HTTP header fields in response to a HEAD request SHOULD be identical |
| information sent in response to a GET request. This method can be |  | to the information sent in response to a GET request. This method |
| used for obtaining metadata about the representation implied by the |  | can be used for obtaining metadata about the representation implied |
| request without transferring the representation body. This method is |  | by the request without transferring the representation body. This |
| often used for testing hypertext links for validity, accessibility, |  | method is often used for testing hypertext links for validity, |
| 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. |
| 7.5. POST |  | 7.5. POST |
| skipping to change at page 17, line 37 |  | skipping to change at page 18, line 22 |
| The action performed by the POST method might not result in a |  | The action performed by the POST method might not result in a |
| resource that can be identified by a URI. In this case, either 200 |  | resource that can be identified by a URI. In this case, either 200 |
| (OK) or 204 (No Content) is the appropriate response status code, |  | (OK) or 204 (No Content) is the appropriate response status code, |
| depending on whether or not the response includes a representation |  | depending on whether or not the response includes a representation |
| that describes the result. |  | that describes the result. |
| If a resource has been created on the origin server, the response |  | If a resource has been created on the origin server, the response |
| SHOULD be 201 (Created) and contain a representation which describes |  | SHOULD be 201 (Created) and contain a representation which describes |
| the status of the request and refers to the new resource, and a |  | the status of the request and refers to the new resource, and a |
| Location header (see Section 9.4). |  | Location header field (see Section 9.4). |
| Responses to POST requests are only cacheable when they include |  | Responses to POST requests are only cacheable when they include |
| explicit freshness information (see Section 2.3.1 of [Part6]). A |  | explicit freshness information (see Section 2.3.1 of [Part6]). A |
| cached POST response with a Content-Location header (see Section 6.7 |  | cached POST response with a Content-Location header field (see |
| of [Part3]) whose value is the effective Request URI MAY be used to |  | Section 6.7 of [Part3]) whose value is the effective Request URI MAY |
| 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 enclosed representation be stored at |
| the effective request URI. If the effective request URI refers to an |  | the effective request URI. If the effective request URI refers to an |
| already existing resource, the enclosed representation SHOULD be |  | already existing resource, the enclosed representation SHOULD be |
| skipping to change at page 18, line 25 |  | skipping to change at page 19, line 5 |
| If a new resource is created at the effective request URI, the origin |  | If a new resource is created at the effective request URI, the origin |
| server MUST inform the user agent via the 201 (Created) response. If |  | server MUST inform the user agent via the 201 (Created) response. If |
| an existing resource is modified, either the 200 (OK) or 204 (No |  | an existing resource is modified, either the 200 (OK) or 204 (No |
| Content) response codes SHOULD be sent to indicate successful |  | Content) response codes SHOULD be sent to indicate successful |
| completion of the request. |  | completion of the request. |
| If the target resource could not be created or modified, an |  | If the target resource could not be created or modified, an |
| appropriate error response SHOULD be given that reflects the nature |  | appropriate error response SHOULD be given that reflects the nature |
| of the problem. The recipient of the representation MUST NOT ignore |  | of the problem. The recipient of the representation MUST NOT ignore |
| any Content-* headers (headers starting with the prefix "Content-") |  | any Content-* header fields (headers starting with the prefix |
| that it does not understand or implement and MUST return a 501 (Not |  | "Content-") that it does not understand or implement and MUST return |
| Implemented) response in such cases. |  | a 501 (Not Implemented) response in such cases. |
| If the request passes through a cache that has one or more stored |  | If the request passes through a cache that has one or more stored |
| responses for the effective request URI, those stored responses |  | responses for the effective request URI, those stored responses |
| SHOULD be marked as stale if the response to the PUT request has a |  | SHOULD be marked as stale if the response to the PUT request has a |
| success status code. Responses to the PUT method are not cacheable. |  | success status code. Responses to the PUT method are not cacheable. |
| The fundamental difference between the POST and PUT requests is |  | The fundamental difference between the POST and PUT requests is |
| reflected in the different meaning of the effective request URI. The |  | reflected in the different meaning of the effective request URI. The |
| URI in a POST request identifies the resource that will handle the |  | URI in a POST request identifies the resource that will handle the |
| enclosed representation. That resource might be a data-accepting |  | enclosed representation. That resource might be a data-accepting |
| skipping to change at page 20, line 21 |  | skipping to change at page 20, line 52 |
| tunneling [RFC2817]). |  | tunneling [RFC2817]). |
| 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 headers, and is |  | consisting only of the Status-Line and optional header fields, and is |
| terminated by an empty line. There are no required headers for this |  | terminated by an empty line. There are no required header fields for |
| class of status code. Since HTTP/1.0 did not define any 1xx status |  | this class of status code. Since HTTP/1.0 did not define any 1xx |
| codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client |  | status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 |
| except under experimental conditions. |  | client except under experimental conditions. |
| A client MUST be prepared to accept one or more 1xx status responses |  | A client MUST be prepared to accept one or more 1xx status responses |
| prior to a regular response, even if the client does not expect a 100 |  | prior to a regular response, even if the client does not expect a 100 |
| (Continue) status message. Unexpected 1xx status responses MAY be |  | (Continue) status message. Unexpected 1xx status responses MAY be |
| ignored by a user agent. |  | ignored by a user agent. |
| Proxies MUST forward 1xx responses, unless the connection between the |  | Proxies MUST forward 1xx responses, unless the connection between the |
| proxy and its client has been closed, or unless the proxy itself |  | proxy and its client has been closed, or unless the proxy itself |
| requested the generation of the 1xx response. (For example, if a |  | requested the generation of the 1xx response. (For example, if a |
| proxy adds a "Expect: 100-continue" field when it forwards a request, |  | proxy adds a "Expect: 100-continue" field when it forwards a request, |
| skipping to change at page 24, line 7 |  | skipping to change at page 24, line 33 |
| detect infinite redirection loops, since such loops generate network |  | detect infinite redirection loops, since such loops generate network |
| traffic for each redirection. |  | traffic for each redirection. |
| Note: An earlier version of this specification recommended a |  | Note: An earlier version of this specification recommended a |
| maximum of five redirections ([RFC2068], Section 10.3). Content |  | maximum of five redirections ([RFC2068], Section 10.3). Content |
| developers need to be aware that some clients might implement such |  | developers need to be aware that some clients might implement such |
| a fixed limitation. |  | a fixed limitation. |
| 8.3.1. 300 Multiple Choices |  | 8.3.1. 300 Multiple Choices |
| The target resource more than one representation, each with its own |  | The target resource has more than one representation, each with its |
| specific location, and agent-driven negotiation information (Section |  | own specific location, and agent-driven negotiation information |
| 5 of [Part3]) is being provided so that the user (or user agent) can |  | (Section 5 of [Part3]) is being provided so that the user (or user |
| select a preferred representation by redirecting its request to that |  | agent) can select a preferred representation by redirecting its |
| location. |  | request to that location. |
| Unless it was a HEAD request, the response SHOULD include a |  | Unless it was a HEAD request, the response SHOULD include a |
| representation containing a list of representation metadata and |  | representation containing a list of representation metadata and |
| location(s) from which the user or user agent can choose the one most |  | location(s) from which the user or user agent can choose the one most |
| appropriate. The data format is specified by the media type given in |  | appropriate. The data format is specified by the media type given in |
| the Content-Type header field. Depending upon the format and the |  | the Content-Type header field. Depending upon the format and the |
| capabilities of the user agent, selection of the most appropriate |  | capabilities of the user agent, selection of the most appropriate |
| choice MAY be performed automatically. However, this specification |  | choice MAY be performed automatically. However, this specification |
| does not define any standard for such automatic selection. |  | does not define any standard for such automatic selection. |
| skipping to change at page 26, line 45 |  | skipping to change at page 27, line 24 |
| 8.3.8. 307 Temporary Redirect |  | 8.3.8. 307 Temporary Redirect |
| The target resource resides temporarily under a different URI. Since |  | The target resource resides temporarily under a different URI. Since |
| the redirection can change over time, the client SHOULD continue to |  | the redirection can change over time, the client SHOULD continue to |
| use the effective request URI for future requests. |  | use the effective request URI for future requests. |
| The temporary URI SHOULD be given by the Location field in the |  | The temporary URI SHOULD be given by the Location field in the |
| response. Unless the request method was HEAD, the representation of |  | response. Unless the request method was HEAD, the representation of |
| the response SHOULD contain a short hypertext note with a hyperlink |  | the response SHOULD contain a short hypertext note with a hyperlink |
| to the new URI(s) , since many pre-HTTP/1.1 user agents do not |  | to the new URI(s), since many pre-HTTP/1.1 user agents do not |
| understand the 307 status code. Therefore, the note SHOULD contain |  | understand the 307 status code. Therefore, the note SHOULD contain |
| the information necessary for a user to repeat the original request |  | the information necessary for a user to repeat the original request |
| on the new URI. |  | on the new URI. |
| If the 307 status code is received in response to a request method |  | If the 307 status code is received in response to a request method |
| that is known to be "safe", as defined in Section 7.1.1, then the |  | that is known to be "safe", as defined in Section 7.1.1, then the |
| request MAY be automatically redirected by the user agent without |  | request MAY be automatically redirected by the user agent without |
| confirmation. Otherwise, the user agent MUST NOT automatically |  | confirmation. Otherwise, the user agent MUST NOT automatically |
| redirect the request unless it can be confirmed by the user, since |  | redirect the request unless it can be confirmed by the user, since |
| this might change the conditions under which the request was issued. |  | this might change the conditions under which the request was issued. |
| skipping to change at page 27, line 36 |  | skipping to change at page 28, line 14 |
| application. |  | application. |
| 8.4.1. 400 Bad Request |  | 8.4.1. 400 Bad Request |
| The request could not be understood by the server due to malformed |  | The request could not be understood by the server due to malformed |
| syntax. The client SHOULD NOT repeat the request without |  | syntax. The client SHOULD NOT repeat the request without |
| modifications. |  | modifications. |
| 8.4.2. 401 Unauthorized |  | 8.4.2. 401 Unauthorized |
| The request requires user authentication (see Section 2.1 of |  | The request requires user authentication (see Section 3.1 of |
| [Part7]). |  | [Part7]). |
| 8.4.3. 402 Payment Required |  | 8.4.3. 402 Payment Required |
| This code is reserved for future use. |  | This code is reserved for future use. |
| 8.4.4. 403 Forbidden |  | 8.4.4. 403 Forbidden |
| The server understood the request, but is refusing to fulfill it. |  | The server understood the request, but is refusing to fulfill it. |
| Authorization will not help and the request SHOULD NOT be repeated. |  | Authorization will not help and the request SHOULD NOT be repeated. |
| skipping to change at page 28, line 19 |  | skipping to change at page 28, line 45 |
| permanent. The 410 (Gone) status code SHOULD be used if the server |  | permanent. The 410 (Gone) status code SHOULD be used if the server |
| knows, through some internally configurable mechanism, that an old |  | knows, through some internally configurable mechanism, that an old |
| resource is permanently unavailable and has no forwarding address. |  | resource is permanently unavailable and has no forwarding address. |
| This status code is commonly used when the server does not wish to |  | This status code is commonly used when the server does not wish to |
| reveal exactly why the request has been refused, or when no other |  | reveal exactly why the request has been refused, or when no other |
| response is applicable. |  | response is applicable. |
| 8.4.6. 405 Method Not Allowed |  | 8.4.6. 405 Method Not Allowed |
| The method specified in the Request-Line is not allowed for the |  | The method specified in the Request-Line is not allowed for the |
| target resource. The response MUST include an Allow header |  | target resource. The response MUST include an Allow header field |
| containing a list of valid methods for the requested resource. |  | containing a list of valid methods for the requested resource. |
| 8.4.7. 406 Not Acceptable |  | 8.4.7. 406 Not Acceptable |
| The resource identified by the request is only capable of generating |  | The resource identified by the request is only capable of generating |
| response representations which have content characteristics not |  | response representations which have content characteristics not |
| acceptable according to the accept headers sent in the request. |  | acceptable according to the accept header fields sent in the request. |
| Unless it was a HEAD request, the response SHOULD include a |  | Unless it was a HEAD request, the response SHOULD include a |
| representation containing a list of available representation |  | representation containing a list of available representation |
| 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 data format is specified by the |  | choose the one most appropriate. The data format is specified by the |
| media type given in the Content-Type header field. Depending upon |  | media type given in the Content-Type header field. Depending upon |
| the format and the capabilities of the user agent, selection of the |  | the format and the capabilities of the user agent, selection of the |
| most appropriate choice MAY be performed automatically. However, |  | most appropriate choice MAY be performed automatically. However, |
| this specification does not define any standard for such automatic |  | this specification does not define any standard for such automatic |
| selection. |  | selection. |
| Note: HTTP/1.1 servers are allowed to return responses which are |  | Note: HTTP/1.1 servers are allowed to return responses which are |
| not acceptable according to the accept headers sent in the |  | not acceptable according to the accept header fields sent in the |
| request. In some cases, this might even be preferable to sending |  | request. In some cases, this might even be preferable to sending |
| a 406 response. User agents are encouraged to inspect the headers |  | a 406 response. User agents are encouraged to inspect the header |
| of an incoming response to determine if it is acceptable. |  | fields of an incoming response to determine if it is acceptable. |
| If the response could be unacceptable, a user agent SHOULD |  | If the response could be unacceptable, a user agent SHOULD |
| temporarily stop receipt of more data and query the user for a |  | temporarily stop receipt of more data and query the user for a |
| decision on further actions. |  | decision on further actions. |
| 8.4.8. 407 Proxy Authentication Required |  | 8.4.8. 407 Proxy Authentication Required |
| This code is similar to 401 (Unauthorized), but indicates that the |  | This code is similar to 401 (Unauthorized), but indicates that the |
| client must first authenticate itself with the proxy (see Section 2.2 |  | client must first authenticate itself with the proxy (see Section 3.2 |
| of [Part7]). |  | of [Part7]). |
| 8.4.9. 408 Request Timeout |  | 8.4.9. 408 Request Timeout |
| The client did not produce a request within the time that the server |  | The client did not produce a request within the time that the server |
| was prepared to wait. The client MAY repeat the request without |  | was prepared to wait. The client MAY repeat the request without |
| modifications at any later time. |  | modifications at any later time. |
| 8.4.10. 409 Conflict |  | 8.4.10. 409 Conflict |
| skipping to change at page 31, line 46 |  | skipping to change at page 32, line 29 |
| The server, while acting as a gateway or proxy, received an invalid |  | The server, while acting as a gateway or proxy, received an invalid |
| response from the upstream server it accessed in attempting to |  | response from the upstream server it accessed in attempting to |
| fulfill the request. |  | fulfill the request. |
| 8.5.4. 503 Service Unavailable |  | 8.5.4. 503 Service Unavailable |
| The server is currently unable to handle the request due to a |  | The server is currently unable to handle the request due to a |
| temporary overloading or maintenance of the server. The implication |  | temporary overloading or maintenance of the server. The implication |
| is that this is a temporary condition which will be alleviated after |  | is that this is a temporary condition which will be alleviated after |
| some delay. If known, the length of the delay MAY be indicated in a |  | some delay. If known, the length of the delay MAY be indicated in a |
| Retry-After header. If no Retry-After is given, the client SHOULD |  | Retry-After header field. If no Retry-After is given, the client |
| handle the response as it would for a 500 response. |  | SHOULD handle the response as it would for a 500 response. |
| Note: The existence of the 503 status code does not imply that a |  | Note: The existence of the 503 status code does not imply that a |
| server must use it when becoming overloaded. Some servers might |  | server must use it when becoming overloaded. Some servers might |
| wish to simply refuse the connection. |  | wish to simply refuse the connection. |
| 8.5.5. 504 Gateway Timeout |  | 8.5.5. 504 Gateway Timeout |
| The server, while acting as a gateway or proxy, did not receive a |  | The server, while acting as a gateway or proxy, did not receive a |
| timely response from the upstream server specified by the URI (e.g., |  | timely response from the upstream server specified by the URI (e.g., |
| HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed |  | HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed |
| skipping to change at page 33, line 37 |  | skipping to change at page 34, line 17 |
| 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 itself is end-to-end; it MUST be forwarded if the |  | request-header field itself is end-to-end; it MUST be forwarded if |
| request is forwarded. |  | the request is forwarded. |
| Many older HTTP/1.0 and HTTP/1.1 applications do not understand the |  | Many older HTTP/1.0 and HTTP/1.1 applications do not understand the |
| Expect header. |  | Expect header 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" request-header field, if given, SHOULD contain an Internet |
| e-mail address for the human user who controls the requesting user |  | e-mail address for the human user who controls the requesting user |
| agent. The address SHOULD be machine-usable, as defined by "mailbox" |  | agent. The address SHOULD be machine-usable, as defined by "mailbox" |
| in Section 3.4 of [RFC5322]: |  | in Section 3.4 of [RFC5322]: |
| skipping to change at page 34, line 20 |  | skipping to change at page 34, line 48 |
| 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 |
| interpretation of this field is that the request is being performed |  | interpretation of this field is that the request is being performed |
| on behalf of the person given, who accepts responsibility for the |  | on behalf of the person given, who accepts responsibility for the |
| method performed. In particular, robot agents SHOULD include this |  | method performed. In particular, robot agents SHOULD include this |
| header so that the person responsible for running the robot can be |  | header field so that the person responsible for running the robot can |
| contacted if problems occur on the receiving end. |  | be contacted if problems occur on the receiving end. |
| The Internet e-mail address in this field MAY be separate from the |  | The Internet e-mail address in this field MAY be separate from the |
| Internet host which issued the request. For example, when a request |  | Internet host which issued the request. For example, when a request |
| is passed through a proxy the original issuer's address SHOULD be |  | is passed through a proxy the original issuer's address SHOULD be |
| used. |  | used. |
| The client SHOULD NOT send the From header field without the user's |  | The client SHOULD NOT send the From header field without the user's |
| approval, as it might conflict with the user's privacy interests or |  | approval, as it might conflict with the user's privacy interests or |
| their site's security policy. It is strongly recommended that the |  | their site's security policy. It is strongly recommended that the |
| user be able to disable, enable, and modify the value of this field |  | user be able to disable, enable, and modify the value of this field |
| skipping to change at page 35, line 15 |  | skipping to change at page 35, line 42 |
| 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: |
| o With a 201 Created response, because in this usage the Location |  | o With a 201 Created response, because in this usage the Location |
| header specifies the 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. |
| 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 |
| skipping to change at page 36, line 13 |  | skipping to change at page 36, line 43 |
| The Max-Forwards header field MAY be ignored for all other methods |  | The Max-Forwards header field MAY be ignored for all other methods |
| defined by this specification and for any extension methods for which |  | defined by this specification and for any extension methods for which |
| it is not explicitly referred to as part of that method definition. |  | it is not explicitly referred to as part of that method definition. |
| 9.6. Referer |  | 9.6. Referer |
| The "Referer" [sic] request-header field allows the client to specify |  | The "Referer" [sic] request-header field allows the client to specify |
| the URI of the resource from which the effective request URI was |  | the URI of the resource from which the effective request URI was |
| obtained (the "referrer", although the header field is misspelled.). |  | obtained (the "referrer", although the header field is misspelled.). |
| The Referer header allows servers to generate lists of back-links to |  | The Referer header field allows servers to generate lists of back- |
| resources for interest, logging, optimized caching, etc. It also |  | links to resources for interest, logging, optimized caching, etc. It |
| allows obsolete or mistyped links to be traced for maintenance. Some |  | also allows obsolete or mistyped links to be traced for maintenance. |
| servers use Referer as a means of controlling where they allow links |  | Some servers use Referer as a means of controlling where they allow |
| 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 = "Referer" ":" OWS Referer-v |
| Referer-v = absolute-URI / partial-URI |  | Referer-v = absolute-URI / partial-URI |
| skipping to change at page 37, line 36 |  | skipping to change at page 38, line 16 |
| 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. Instead, it |  | application MUST NOT modify the Server response-header field. |
| MUST include a Via field (as described in Section 9.9 of [Part1]). |  | Instead, it 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 |
| 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" request-header field contains information about the |
| user agent originating the request. This is for statistical |  | user agent originating the request. User agents SHOULD include this |
| purposes, the tracing of protocol violations, and automated |  | field with requests. |
| recognition of user agents for the sake of tailoring responses to |  |  |
| avoid particular user agent limitations. |  |  |
| User agents SHOULD include this field with requests. The field can |  | Typically, it is used for statistical purposes, the tracing of |
| contain multiple product tokens (Section 6.3 of [Part1]) and comments |  | protocol violations, and tailoring responses to avoid particular user |
| (Section 3.2 of [Part1]) identifying the agent and any subproducts |  | agent limitations. |
| which form a significant part of the user agent. By convention, the |  |  |
| product tokens are listed in order of their significance for |  | The field can contain multiple product tokens (Section 6.3 of |
| identifying the application. |  | [Part1]) and comments (Section 3.2 of [Part1]) identifying the agent |
|  |  | and its significant subproducts. By convention, the product tokens |
|  |  | are listed in order of their significance for identifying the |
|  |  | application. |
|  |  | Because this field is usually sent on every request a user agent |
|  |  | makes, implementations are encouraged not to include needlessly fine- |
|  |  | grained detail, and to limit (or even prohibit) the addition of |
|  |  | subproducts by third parties. Overly long and detailed User-Agent |
|  |  | field values make requests larger and can also be used to identify |
|  |  | ("fingerprint") the user against their wishes. |
|  |  | Likewise, implementations are encouraged not to use the product |
|  |  | tokens of other implementations in order to declare compatibility |
|  |  | with them, as this circumvents the purpose of the field. Finally, |
|  |  | they are encouraged not to use comments to identify products; doing |
|  |  | 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 |
| skipping to change at page 40, line 51 |  | skipping to change at page 41, line 51 |
| server machine to become more vulnerable to attacks against software |  | server machine to become more vulnerable to attacks against software |
| that is known to contain security holes. Implementors SHOULD make |  | that is known to contain security holes. Implementors SHOULD make |
| the Server header field a configurable option. |  | the Server header field a configurable option. |
| Proxies which serve as a portal through a network firewall SHOULD |  | Proxies which serve as a portal through a network firewall SHOULD |
| take special precautions regarding the transfer of header information |  | take special precautions regarding the transfer of header information |
| that identifies the hosts behind the firewall. In particular, they |  | that identifies the hosts behind the firewall. In particular, they |
| SHOULD remove, or replace with sanitized versions, any Via fields |  | SHOULD remove, or replace with sanitized versions, any Via fields |
| generated behind the firewall. |  | generated behind the firewall. |
| The Referer header allows reading patterns to be studied and reverse |  | The Referer header field allows reading patterns to be studied and |
| links drawn. Although it can be very useful, its power can be abused |  | reverse links drawn. Although it can be very useful, its power can |
| if user details are not separated from the information contained in |  | be abused if user details are not separated from the information |
| the Referer. Even when the personal information has been removed, |  | contained in the Referer. Even when the personal information has |
| the Referer header might indicate a private document's URI whose |  | been removed, the Referer header field might indicate a private |
| publication would be inappropriate. |  | document's URI whose publication would be inappropriate. |
| The information sent in the From field might conflict with the user's |  | The information sent in the From field might conflict with the user's |
| privacy interests or their site's security policy, and hence it |  | privacy interests or their site's security policy, and hence it |
| SHOULD NOT be transmitted without the user being able to disable, |  | SHOULD NOT be transmitted without the user being able to disable, |
| enable, and modify the contents of the field. The user MUST be able |  | enable, and modify the contents of the field. The user MUST be able |
| to set the contents of this field within a user preference or |  | to set the contents of this field within a user preference or |
| application defaults configuration. |  | application defaults configuration. |
| We suggest, though do not require, that a convenient toggle interface |  | We suggest, though do not require, that a convenient toggle interface |
| be provided for the user to enable or disable the sending of From and |  | be provided for the user to enable or disable the sending of From and |
| Referer information. |  | Referer information. |
| The User-Agent (Section 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 |
|  |  | to be used, possibly in conjunction with other material, to uniquely |
|  |  | identify the user. |
| Some methods, like TRACE (Section 7.8), expose information that was |  | Some methods, like TRACE (Section 7.8), expose information that was |
| sent in request headers within the body of their response. Clients |  | sent in request header fields within the body of their response. |
| SHOULD be careful with sensitive information, like Cookies, |  | Clients SHOULD be careful with sensitive information, like Cookies, |
| Authorization credentials and other headers that might be used to |  | Authorization credentials and other header fields that might be used |
| collect data from the client. |  | 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 42, line 9 |  | skipping to change at page 43, line 13 |
| of sensitive data because that data will be placed in the request- |  | of sensitive data because that data will be placed in the request- |
| target. Many existing servers, proxies, and user agents log or |  | target. Many existing servers, proxies, and user agents log or |
| display the request-target in places where it might be visible to |  | display the request-target in places where it might be visible to |
| third parties. Such services can use POST-based form submission |  | third parties. Such services can use POST-based form submission |
| 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 headers in responses that are generated under control of |  | Location header fields in responses that are generated under control |
| 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. |
| 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-11 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-12 |
| (work in progress), August 2010. |  | (work in progress), October 2010. |
| [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-11 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-12 |
| (work in progress), August 2010. |  | (work in progress), October 2010. |
| [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-11 (work in |  | Requests", draft-ietf-httpbis-p4-conditional-12 (work in |
| progress), August 2010. |  | progress), October 2010. |
| [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-11 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-12 (work |
| in progress), August 2010. |  | in progress), October 2010. |
| [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-11 (work in |  | 6: Caching", draft-ietf-httpbis-p6-cache-12 (work in |
| progress), August 2010. |  | progress), October 2010. |
| [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-11 (work in progress), |  | draft-ietf-httpbis-p7-auth-12 (work in progress), |
| August 2010. |  | October 2010. |
| [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", RFC 3986, |  | Resource Identifier (URI): Generic Syntax", STD 66, |
| STD 66, 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. |
| 13.2. Informative References |  | 13.2. Informative References |
| [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext |  | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext |
| Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. |  | Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. |
| [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |  | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |
| skipping to change at page 44, line 13 |  | skipping to change at page 45, line 17 |
| 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) |
| Reclassify Allow header as response header, 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 and remove requirement on clients to |  | contents of the Allow header field and remove requirement on clients |
| always trust the header value. (Section 9.1) |  | to always trust the header field value. (Section 9.1) |
| Correct syntax of Location header to allow URI references (including |  | Correct syntax of Location header field to allow URI references |
| relative references and fragments), as referred symbol "absoluteURI" |  | (including relative references and fragments), as referred symbol |
| wasn't what was expected, and add some clarifications as to when use |  | "absoluteURI" wasn't what was expected, and add some clarifications |
| of fragments would not be appropriate. (Section 9.4) |  | as to when use of fragments would not be appropriate. (Section 9.4) |
| Allow Referer value of "about:blank" as alternative to not specifying |  | Allow Referer field value of "about:blank" as alternative to not |
| it. (Section 9.6) |  | specifying it. (Section 9.6) |
| In the description of the Server header, the Via field was described |  | In the description of the Server header field, the Via field was |
| as a SHOULD. The requirement was and is stated correctly in the |  | described as a SHOULD. The requirement was and is stated correctly |
| description of the Via header 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 = <Accept, defined in [Part3], Section 6.1> |
| Accept-Charset = <Accept-Charset, defined in [Part3], Section 6.2> |  | Accept-Charset = <Accept-Charset, defined in [Part3], Section 6.2> |
| Accept-Encoding = <Accept-Encoding, defined in [Part3], Section 6.3> |  | Accept-Encoding = <Accept-Encoding, defined in [Part3], Section 6.3> |
| Accept-Language = <Accept-Language, defined in [Part3], Section 6.4> |  | Accept-Language = <Accept-Language, defined in [Part3], Section 6.4> |
| Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 5.1> |  | Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 5.1> |
| Age = <Age, defined in [Part6], Section 3.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 3.1> |  | Authorization = <Authorization, defined in [Part7], Section 4.1> |
| ETag = <ETag, defined in [Part4], Section 6.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> |  | Host = <Host, defined in [Part1], Section 2.6> |
| skipping to change at page 45, line 30 |  | skipping to change at page 46, line 35 |
| / %x50.4F.53.54 ; POST |  | / %x50.4F.53.54 ; POST |
| / %x50.55.54 ; PUT |  | / %x50.55.54 ; PUT |
| / %x44.45.4C.45.54.45 ; DELETE |  | / %x44.45.4C.45.54.45 ; DELETE |
| / %x54.52.41.43.45 ; TRACE |  | / %x54.52.41.43.45 ; TRACE |
| / %x43.4F.4E.4E.45.43.54 ; CONNECT |  | / %x43.4F.4E.4E.45.43.54 ; CONNECT |
| / extension-method |  | / extension-method |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| Proxy-Authenticate = |  | Proxy-Authenticate = |
| <Proxy-Authenticate, defined in [Part7], Section 3.2> |  | <Proxy-Authenticate, defined in [Part7], Section 4.2> |
| Proxy-Authorization = |  | Proxy-Authorization = |
| <Proxy-Authorization, defined in [Part7], Section 3.3> |  | <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> |  | 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 |
| skipping to change at page 46, line 4 |  | skipping to change at page 47, line 12 |
| 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 = "100" / "101" / "200" / "201" / "202" / "203" / "204" / |
| "205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" / |  | "205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" / |
| "307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" / |  | "307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" / |
| "407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" / |  | "407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" / |
| "415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" / |  | "415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" / |
| "505" / extension-code |  | "505" / extension-code |
| TE = <TE, defined in [Part1], Section 9.5> |  | 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> |  | Vary = <Vary, defined in [Part6], Section 3.5> |
| WWW-Authenticate = |  | WWW-Authenticate = |
| <WWW-Authenticate, defined in [Part7], Section 3.4> |  | <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 ) |
| skipping to change at page 47, line 7 |  | skipping to change at page 48, line 16 |
| ABNF diagnostics: |  | ABNF diagnostics: |
| ; Reason-Phrase defined but not used |  | ; Reason-Phrase defined but not used |
| ; Status-Code defined but not used |  | ; Status-Code defined but not used |
| ; request-header defined but not used |  | ; request-header defined but not used |
| ; response-header 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 RFC2616 |  | 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: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a MUST" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a MUST" |
| (<http://purl.org/NET/http-errata#via-must>) |  | (<http://purl.org/NET/http-errata#via-must>) |
| skipping to change at page 48, line 12 |  | skipping to change at page 49, line 21 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side |
| effects" |  | effects" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate Host |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate Host |
| header requirements" |  | header requirements" |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Move "Product Tokens" section (back) into Part 1, as "token" is |  | o Move "Product Tokens" section (back) into Part 1, as "token" is |
| used in the definition of the Upgrade header. |  | used in the definition of the Upgrade header field. |
| o Add explicit references to BNF syntax and rules imported from |  | o Add explicit references to BNF syntax and rules imported from |
| other parts of the specification. |  | other parts of the specification. |
| o Copy definition of delta-seconds from Part6 instead of referencing |  | o Copy definition of delta-seconds from Part6 instead of referencing |
| it. |  | it. |
| C.4. Since draft-ietf-httpbis-p2-semantics-02 |  | C.4. Since draft-ietf-httpbis-p2-semantics-02 |
| Closed issues: |  | Closed issues: |
| skipping to change at page 48, line 44 |  | skipping to change at page 50, line 5 |
| of 303 response" |  | of 303 response" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use Proxy" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use Proxy" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/105>: |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/105>: |
| "Classification for Allow header" |  | "Classification for Allow header" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store |
| under' vs 'store at'" |  | under' vs 'store at'" |
| Ongoing work on IANA Message Header Registration |  | Ongoing work on IANA Message Header Field Registration |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |
| o Reference RFC 3984, and update header registrations for headers |  | o Reference RFC 3984, and update header field registrations for |
| defined in this document. |  | headers defined in this document. |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Replace string literals when the string really is case-sensitive |  | o Replace string literals when the string really is case-sensitive |
| (method). |  | (method). |
| C.5. Since draft-ietf-httpbis-p2-semantics-03 |  | C.5. Since draft-ietf-httpbis-p2-semantics-03 |
| Closed issues: |  | Closed issues: |
| skipping to change at page 49, line 46 |  | skipping to change at page 51, line 6 |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Use "/" instead of "|" for alternatives. |  | o Use "/" instead of "|" for alternatives. |
| o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |  | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
| whitespace ("OWS") and required whitespace ("RWS"). |  | whitespace ("OWS") and required whitespace ("RWS"). |
| o Rewrite ABNFs to spell out whitespace rules, factor out header |  | o Rewrite ABNFs to spell out whitespace rules, factor out header |
| value format definitions. |  | field value format definitions. |
| C.7. Since draft-ietf-httpbis-p2-semantics-05 |  | C.7. Since draft-ietf-httpbis-p2-semantics-05 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase |
| BNF" |  | BNF" |
| Final work on ABNF conversion |  | Final work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| skipping to change at page 52, line 11 |  | skipping to change at page 53, line 17 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/190>: "OPTIONS vs |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/190>: "OPTIONS vs |
| Max-Forwards" |  | Max-Forwards" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: "Status codes |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: "Status codes |
| and caching" |  | and caching" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |
| removing the 'changes from 2068' sections" |  | removing the 'changes from 2068' sections" |
|  |  | C.13. Since draft-ietf-httpbis-p2-semantics-11 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/229>: |
|  |  | "Considerations for new status codes" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/230>: |
|  |  | "Considerations for new methods" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/232>: "User-Agent |
|  |  | guidelines" (relating to the 'User-Agent' header field) |
| Index |  | Index |
| 1 |  | 1 |
| 100 Continue (status code) 20 |  | 100 Continue (status code) 21 |
| 101 Switching Protocols (status code) 21 |  | 101 Switching Protocols (status code) 21 |
| 2 |  | 2 |
| 200 OK (status code) 21 |  | 200 OK (status code) 22 |
| 201 Created (status code) 21 |  | 201 Created (status code) 22 |
| 202 Accepted (status code) 22 |  | 202 Accepted (status code) 22 |
| 203 Non-Authoritative Information (status code) 22 |  | 203 Non-Authoritative Information (status code) 23 |
| 204 No Content (status code) 22 |  | 204 No Content (status code) 23 |
| 205 Reset Content (status code) 23 |  | 205 Reset Content (status code) 23 |
| 206 Partial Content (status code) 23 |  | 206 Partial Content (status code) 24 |
| 3 |  | 3 |
| 300 Multiple Choices (status code) 24 |  | 300 Multiple Choices (status code) 24 |
| 301 Moved Permanently (status code) 24 |  | 301 Moved Permanently (status code) 25 |
| 302 Found (status code) 25 |  | 302 Found (status code) 25 |
| 303 See Other (status code) 25 |  | 303 See Other (status code) 26 |
| 304 Not Modified (status code) 26 |  | 304 Not Modified (status code) 26 |
| 305 Use Proxy (status code) 26 |  | 305 Use Proxy (status code) 27 |
| 306 (Unused) (status code) 26 |  | 306 (Unused) (status code) 27 |
| 307 Temporary Redirect (status code) 26 |  | 307 Temporary Redirect (status code) 27 |
| 4 |  | 4 |
| 400 Bad Request (status code) 27 |  | 400 Bad Request (status code) 28 |
| 401 Unauthorized (status code) 27 |  | 401 Unauthorized (status code) 28 |
| 402 Payment Required (status code) 27 |  | 402 Payment Required (status code) 28 |
| 403 Forbidden (status code) 27 |  | 403 Forbidden (status code) 28 |
| 404 Not Found (status code) 28 |  | 404 Not Found (status code) 28 |
| 405 Method Not Allowed (status code) 28 |  | 405 Method Not Allowed (status code) 28 |
| 406 Not Acceptable (status code) 28 |  | 406 Not Acceptable (status code) 28 |
| 407 Proxy Authentication Required (status code) 28 |  | 407 Proxy Authentication Required (status code) 29 |
| 408 Request Timeout (status code) 29 |  | 408 Request Timeout (status code) 29 |
| 409 Conflict (status code) 29 |  | 409 Conflict (status code) 29 |
| 410 Gone (status code) 29 |  | 410 Gone (status code) 30 |
| 411 Length Required (status code) 30 |  | 411 Length Required (status code) 30 |
| 412 Precondition Failed (status code) 30 |  | 412 Precondition Failed (status code) 30 |
| 413 Request Entity Too Large (status code) 30 |  | 413 Request Entity Too Large (status code) 30 |
| 414 URI Too Long (status code) 30 |  | 414 URI Too Long (status code) 31 |
| 415 Unsupported Media Type (status code) 30 |  | 415 Unsupported Media Type (status code) 31 |
| 416 Requested Range Not Satisfiable (status code) 30 |  | 416 Requested Range Not Satisfiable (status code) 31 |
| 417 Expectation Failed (status code) 31 |  | 417 Expectation Failed (status code) 31 |
| 5 |  | 5 |
| 500 Internal Server Error (status code) 31 |  | 500 Internal Server Error (status code) 32 |
| 501 Not Implemented (status code) 31 |  | 501 Not Implemented (status code) 32 |
| 502 Bad Gateway (status code) 31 |  | 502 Bad Gateway (status code) 32 |
| 503 Service Unavailable (status code) 31 |  | 503 Service Unavailable (status code) 32 |
| 504 Gateway Timeout (status code) 32 |  | 504 Gateway Timeout (status code) 32 |
| 505 HTTP Version Not Supported (status code) 32 |  | 505 HTTP Version Not Supported (status code) 32 |
| A |  | A |
| Allow header 32 |  | Allow header 33 |
| C |  | C |
| CONNECT method 20 |  | CONNECT method 20 |
| D |  | D |
| DELETE method 19 |  | DELETE method 19 |
| E |  | E |
| Expect header 33 |  | Expect header 33 |
| F |  | F |
| From header 33 |  | From header 34 |
| G |  | G |
| GET method 16 |  | GET method 16 |
| Grammar |  | Grammar |
| Allow 32 |  | Allow 33 |
| Allow-v 32 |  | Allow-v 33 |
| delta-seconds 37 |  | delta-seconds 37 |
| Expect 33 |  | Expect 33 |
| expect-params 33 |  | expect-params 33 |
| Expect-v 33 |  | Expect-v 33 |
| expectation 33 |  | expectation 33 |
| expectation-extension 33 |  | expectation-extension 33 |
| extension-code 11 |  | extension-code 11 |
| extension-method 8 |  | extension-method 8 |
| From 34 |  | From 34 |
| From-v 34 |  | From-v 34 |
| Location 34 |  | Location 35 |
| Location-v 34 |  | Location-v 35 |
| Max-Forwards 35 |  | Max-Forwards 36 |
| Max-Forwards-v 35 |  | Max-Forwards-v 36 |
| Method 8 |  | Method 8 |
| Reason-Phrase 11 |  | Reason-Phrase 11 |
| Referer 36 |  | Referer 37 |
| Referer-v 36 |  | Referer-v 37 |
| request-header 9 |  | request-header 10 |
| response-header 12 |  | response-header 13 |
| Retry-After 36 |  | Retry-After 37 |
| Retry-After-v 36 |  | Retry-After-v 37 |
| Server 37 |  | Server 38 |
| Server-v 37 |  | Server-v 38 |
| Status-Code 11 |  | Status-Code 11 |
| User-Agent 38 |  | User-Agent 39 |
| User-Agent-v 38 |  | User-Agent-v 39 |
| H |  | H |
| HEAD method 16 |  | HEAD method 17 |
| Headers |  | Headers |
| Allow 32 |  | Allow 33 |
| Expect 33 |  | Expect 33 |
| From 33 |  | From 34 |
| Location 34 |  | Location 35 |
| Max-Forwards 35 |  | Max-Forwards 36 |
| Referer 36 |  | Referer 36 |
| Retry-After 36 |  | Retry-After 37 |
| Server 37 |  | Server 37 |
| User-Agent 37 |  | User-Agent 38 |
| I |  | I |
| Idempotent Methods 14 |  | Idempotent Methods 15 |
| L |  | L |
| Location header 34 |  | Location header 35 |
| M |  | M |
| Max-Forwards header 35 |  | Max-Forwards header 36 |
| Methods |  | Methods |
| CONNECT 20 |  | CONNECT 20 |
| DELETE 19 |  | DELETE 19 |
| GET 16 |  | GET 16 |
| HEAD 16 |  | HEAD 17 |
| OPTIONS 15 |  | OPTIONS 15 |
| POST 17 |  | POST 17 |
| PUT 18 |  | PUT 18 |
| TRACE 19 |  | TRACE 20 |
| 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 36 |
| Retry-After header 36 |  | Retry-After header 37 |
| S |  | S |
| Safe Methods 14 |  | Safe Methods 15 |
| Server header 37 |  | Server header 37 |
| Status Codes |  | Status Codes |
| 100 Continue 20 |  | 100 Continue 21 |
| 101 Switching Protocols 21 |  | 101 Switching Protocols 21 |
| 200 OK 21 |  | 200 OK 22 |
| 201 Created 21 |  | 201 Created 22 |
| 202 Accepted 22 |  | 202 Accepted 22 |
| 203 Non-Authoritative Information 22 |  | 203 Non-Authoritative Information 23 |
| 204 No Content 22 |  | 204 No Content 23 |
| 205 Reset Content 23 |  | 205 Reset Content 23 |
| 206 Partial Content 23 |  | 206 Partial Content 24 |
| 300 Multiple Choices 24 |  | 300 Multiple Choices 24 |
| 301 Moved Permanently 24 |  | 301 Moved Permanently 25 |
| 302 Found 25 |  | 302 Found 25 |
| 303 See Other 25 |  | 303 See Other 26 |
| 304 Not Modified 26 |  | 304 Not Modified 26 |
| 305 Use Proxy 26 |  | 305 Use Proxy 27 |
| 306 (Unused) 26 |  | 306 (Unused) 27 |
| 307 Temporary Redirect 26 |  | 307 Temporary Redirect 27 |
| 400 Bad Request 27 |  | 400 Bad Request 28 |
| 401 Unauthorized 27 |  | 401 Unauthorized 28 |
| 402 Payment Required 27 |  | 402 Payment Required 28 |
| 403 Forbidden 27 |  | 403 Forbidden 28 |
| 404 Not Found 28 |  | 404 Not Found 28 |
| 405 Method Not Allowed 28 |  | 405 Method Not Allowed 28 |
| 406 Not Acceptable 28 |  | 406 Not Acceptable 28 |
| 407 Proxy Authentication Required 28 |  | 407 Proxy Authentication Required 29 |
| 408 Request Timeout 29 |  | 408 Request Timeout 29 |
| 409 Conflict 29 |  | 409 Conflict 29 |
| 410 Gone 29 |  | 410 Gone 30 |
| 411 Length Required 30 |  | 411 Length Required 30 |
| 412 Precondition Failed 30 |  | 412 Precondition Failed 30 |
| 413 Request Entity Too Large 30 |  | 413 Request Entity Too Large 30 |
| 414 URI Too Long 30 |  | 414 URI Too Long 31 |
| 415 Unsupported Media Type 30 |  | 415 Unsupported Media Type 31 |
| 416 Requested Range Not Satisfiable 30 |  | 416 Requested Range Not Satisfiable 31 |
| 417 Expectation Failed 31 |  | 417 Expectation Failed 31 |
| 500 Internal Server Error 31 |  | 500 Internal Server Error 32 |
| 501 Not Implemented 31 |  | 501 Not Implemented 32 |
| 502 Bad Gateway 31 |  | 502 Bad Gateway 32 |
| 503 Service Unavailable 31 |  | 503 Service Unavailable 32 |
| 504 Gateway Timeout 32 |  | 504 Gateway Timeout 32 |
| 505 HTTP Version Not Supported 32 |  | 505 HTTP Version Not Supported 32 |
| T |  | T |
| TRACE method 19 |  | TRACE method 20 |
| U |  | U |
| User-Agent header 37 |  | User-Agent header 38 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Day Software |  | Day Software |
| 23 Corporate Plaza DR, Suite 280 |  | 23 Corporate Plaza DR, Suite 280 |
| Newport Beach, CA 92660 |  | Newport Beach, CA 92660 |
| USA |  | USA |
| Phone: +1-949-706-5300 |  | Phone: +1-949-706-5300 |
End of changes. 136 change blocks.
| 276 lines changed or deleted |  | 370 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/