| draft-ietf-httpbis-p2-semantics-17.txt |  | draft-ietf-httpbis-p2-semantics-18.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Updates: 2817 (if approved) Alcatel-Lucent |  | Updates: 2817 (if approved) Alcatel-Lucent |
| Intended status: Standards Track J. Mogul |  | Intended status: Standards Track J. Mogul |
| Expires: May 3, 2012 HP |  | Expires: July 7, 2012 HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe |  | Adobe |
| P. Leach |  | P. Leach |
| Microsoft |  | Microsoft |
| T. Berners-Lee |  | T. Berners-Lee |
| W3C/MIT |  | W3C/MIT |
| Y. Lafon, Ed. |  | Y. Lafon, Ed. |
| W3C |  | W3C |
| J. Reschke, Ed. |  | J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| October 31, 2011 |  | January 4, 2012 |
| HTTP/1.1, part 2: Message Semantics |  | HTTP/1.1, part 2: Message Semantics |
| draft-ietf-httpbis-p2-semantics-17 |  | draft-ietf-httpbis-p2-semantics-18 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypertext information |  | protocol for distributed, collaborative, hypertext 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. |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. |
| skipping to change at page 2, line 5 |  | skipping to change at page 2, line 5 |
| 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), which is archived at |  | group mailing list (ietf-http-wg@w3.org), which is archived at |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
| The current issues list is at |  | The current issues list is at |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <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.18. |  | The changes in this draft are summarized in Appendix C.19. |
| 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 May 3, 2012. |  | This Internet-Draft will expire on July 7, 2012. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2011 IETF Trust and the persons identified as the |  | Copyright (c) 2012 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| carefully, as they describe your rights and restrictions with respect |  | carefully, as they describe your rights and restrictions with respect |
| to this document. Code Components extracted from this document must |  | to this document. Code Components extracted from this document must |
| include Simplified BSD License text as described in Section 4.e of |  | include Simplified BSD License text as described in Section 4.e of |
| the Trust Legal Provisions and are provided without warranty as |  | the Trust Legal Provisions and are provided without warranty as |
| skipping to change at page 3, line 18 |  | skipping to change at page 3, line 18 |
| 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.1. Overview of Methods . . . . . . . . . . . . . . . . . . . 8 |  | 2.1. Overview of Methods . . . . . . . . . . . . . . . . . . . 8 |
| 2.2. Method Registry . . . . . . . . . . . . . . . . . . . . . 8 |  | 2.2. Method Registry . . . . . . . . . . . . . . . . . . . . . 8 |
| 2.2.1. Considerations for New Methods . . . . . . . . . . . . 9 |  | 2.2.1. Considerations for New Methods . . . . . . . . . . . . 9 |
| 3. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 9 |  | 3. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 9 |
| 3.1. Considerations for Creating Header Fields . . . . . . . . 9 |  | 3.1. Considerations for Creating Header Fields . . . . . . . . 9 |
| 3.2. Request Header Fields . . . . . . . . . . . . . . . . . . 11 |  | 3.2. Request Header Fields . . . . . . . . . . . . . . . . . . 11 |
| 3.3. Response Header Fields . . . . . . . . . . . . . . . . . . 12 |  | 3.3. Response Header Fields . . . . . . . . . . . . . . . . . . 12 |
| 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 12 |  | 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 13 |
| 4.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 13 |  | 4.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 13 |
| 4.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 15 |  | 4.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 15 |
| 4.2.1. Considerations for New Status Codes . . . . . . . . . 15 |  | 4.2.1. Considerations for New Status Codes . . . . . . . . . 15 |
| 5. Representation . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 5. Representation . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 5.1. Identifying the Resource Associated with a |  | 5.1. Identifying the Resource Associated with a |
| Representation . . . . . . . . . . . . . . . . . . . . . . 16 |  | Representation . . . . . . . . . . . . . . . . . . . . . . 16 |
| 6. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 17 |  | 6. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 17 |
| 6.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 17 |  | 6.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 17 |
| 6.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 17 |  | 6.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 17 |
| 6.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 17 |  | 6.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 17 |
| skipping to change at page 4, line 19 |  | skipping to change at page 4, line 19 |
| 7.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 33 |  | 7.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 33 |
| 7.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 33 |  | 7.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 33 |
| 7.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 34 |  | 7.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 34 |
| 7.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 34 |  | 7.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 34 |
| 7.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 34 |  | 7.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 34 |
| 7.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 34 |  | 7.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 34 |
| 7.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 34 |  | 7.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 34 |
| 7.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 35 |  | 7.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 35 |
| 7.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 35 |  | 7.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 35 |
| 7.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 35 |  | 7.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 35 |
| 7.4.8. 407 Proxy Authentication Required . . . . . . . . . . 35 |  | 7.4.8. 407 Proxy Authentication Required . . . . . . . . . . 36 |
| 7.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 36 |  | 7.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 36 |
| 7.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 36 |  | 7.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 36 |
| 7.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 36 |  | 7.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 36 |
| 7.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 37 |  | 7.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 37 |
| 7.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 37 |  | 7.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 37 |
| 7.4.14. 413 Request Representation Too Large . . . . . . . . . 37 |  | 7.4.14. 413 Request Representation Too Large . . . . . . . . . 37 |
| 7.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 37 |  | 7.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 37 |
| 7.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 37 |  | 7.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 37 |
| 7.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 38 |  | 7.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 38 |
| 7.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 38 |  | 7.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 38 |
| skipping to change at page 5, line 4 |  | skipping to change at page 5, line 4 |
| 9.3. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 44 |  | 9.3. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 44 |
| 9.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 |  | 9.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 |
| 9.5. Location . . . . . . . . . . . . . . . . . . . . . . . . . 45 |  | 9.5. Location . . . . . . . . . . . . . . . . . . . . . . . . . 45 |
| 9.6. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 46 |  | 9.6. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 46 |
| 9.7. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 47 |  | 9.7. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 47 |
| 9.8. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 47 |  | 9.8. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 47 |
| 9.9. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 48 |  | 9.9. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 48 |
| 9.10. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 48 |  | 9.10. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 48 |
| 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 |  | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 |
| 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 49 |  | 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 49 |
| 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 49 |  | 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 50 |
| 10.3. Header Field Registration . . . . . . . . . . . . . . . . 51 |  | 10.3. Header Field Registration . . . . . . . . . . . . . . . . 51 |
| 11. Security Considerations . . . . . . . . . . . . . . . . . . . 51 |  | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 52 |
| 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 51 |  | 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 52 |
| 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 52 |  | 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 53 |
| 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 53 |  | 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 54 |
| 11.4. Security Considerations for CONNECT . . . . . . . . . . . 53 |  | 11.4. Security Considerations for CONNECT . . . . . . . . . . . 54 |
| 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 |  | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 |
| 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 |  | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 |
| 13.1. Normative References . . . . . . . . . . . . . . . . . . . 53 |  | 13.1. Normative References . . . . . . . . . . . . . . . . . . . 54 |
| 13.2. Informative References . . . . . . . . . . . . . . . . . . 54 |  | 13.2. Informative References . . . . . . . . . . . . . . . . . . 55 |
| Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 55 |  | Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 56 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 56 |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 57 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 59 |  | publication) . . . . . . . . . . . . . . . . . . . . 60 |
| C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 59 |  | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 60 |
| C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 59 |  | C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 60 |
| C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 59 |  | C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 60 |
| C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 60 |  | C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 61 |
| C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 61 |  | C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 62 |
| C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 61 |  | C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 62 |
| C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 61 |  | C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 62 |
| C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 62 |  | C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 63 |
| C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 62 |  | C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 63 |
| C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 63 |  | C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 64 |
| C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 63 |  | C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 64 |
| C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 63 |  | C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 64 |
| C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 64 |  | C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 65 |
| C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 64 |  | C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 65 |
| C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 65 |  | C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 66 |
| C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . . 66 |  | C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . . 67 |
| C.17. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . . 66 |  | C.17. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . . 67 |
| C.18. Since draft-ietf-httpbis-p2-semantics-16 . . . . . . . . . 66 |  | C.18. Since draft-ietf-httpbis-p2-semantics-16 . . . . . . . . . 67 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 |  | C.19. Since draft-ietf-httpbis-p2-semantics-17 . . . . . . . . . 67 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 |
| 1. Introduction |  | 1. Introduction |
| This document defines HTTP/1.1 request and response semantics. Each |  | This document defines HTTP/1.1 request and response semantics. Each |
| HTTP message, as defined in [Part1], is in the form of either a |  | HTTP message, as defined in [Part1], is in the form of either a |
| request or a response. An HTTP server listens on a connection for |  | request or a response. An HTTP server listens on a connection for |
| HTTP requests and responds to each request, in the order received on |  | HTTP requests and responds to each request, in the order received on |
| that connection, with one or more HTTP response messages. This |  | that connection, with one or more HTTP response messages. This |
| document defines the commonly agreed upon semantics of the HTTP |  | document defines the commonly agreed upon semantics of the HTTP |
| uniform interface, the intentions defined by each request method, and |  | uniform interface, the intentions defined by each request method, and |
| skipping to change at page 7, line 26 |  | skipping to change at page 7, line 26 |
| [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |  | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |
| (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |  | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |
| HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line |  | HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line |
| feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any |  | feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any |
| visible US-ASCII character). |  | visible US-ASCII character). |
| 1.2.1. Core Rules |  | 1.2.1. Core Rules |
| The core rules below are defined in [Part1]: |  | The core rules below are defined in [Part1]: |
|  |  | BWS = <BWS, defined in [Part1], Section 1.2.2> |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| RWS = <RWS, defined in [Part1], Section 1.2.2> |  | RWS = <RWS, defined in [Part1], Section 1.2.2> |
| obs-text = <obs-text, defined in [Part1], Section 1.2.2> |  | obs-text = <obs-text, defined in [Part1], Section 1.2.2> |
| quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> |  | quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> |
| token = <token, defined in [Part1], Section 3.2.3> |  | token = <token, defined in [Part1], Section 3.2.3> |
| 1.2.2. ABNF Rules defined in other Parts of the Specification |  | 1.2.2. ABNF Rules defined in other Parts of the Specification |
| The ABNF rules below are defined in other parts: |  | The ABNF rules below are defined in other parts: |
| skipping to change at page 10, line 22 |  | skipping to change at page 10, line 24 |
| comma are protected with double-quotes using the quoted-string ABNF |  | comma are protected with double-quotes using the quoted-string ABNF |
| production (Section 3.2.3 of [Part1]). |  | production (Section 3.2.3 of [Part1]). |
| For example, a textual date and a URI (either of which might contain |  | For example, a textual date and a URI (either of which might contain |
| a comma) could be safely carried in field-values like these: |  | a comma) could be safely carried in field-values like these: |
| Example-URI-Field: "http://example.com/a.html,foo", |  | Example-URI-Field: "http://example.com/a.html,foo", |
| "http://without-a-comma.example.com/" |  | "http://without-a-comma.example.com/" |
| Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" |  | Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" |
|  |  | Note that double quote delimiters almost always are used with the |
|  |  | quoted-string production; using a different syntax inside double |
|  |  | quotes will likely cause unnecessary confusion. |
| Many header fields use a format including (case-insensitively) named |  | Many header fields use a format including (case-insensitively) named |
| parameters (for instance, Content-Type, defined in Section 6.8 of |  | parameters (for instance, Content-Type, defined in Section 6.8 of |
| [Part3]). Allowing both unquoted (token) and quoted (quoted-string) |  | [Part3]). Allowing both unquoted (token) and quoted (quoted-string) |
| syntax for the parameter value enables recipients to use existing |  | syntax for the parameter value enables recipients to use existing |
| parser components. When allowing both forms, the meaning of a |  | parser components. When allowing both forms, the meaning of a |
| parameter value ought to be independent of the syntax used for it |  | parameter value ought to be independent of the syntax used for it |
| (for an example, see the notes on parameter handling for media types |  | (for an example, see the notes on parameter handling for media types |
| in Section 2.3 of [Part3]). |  | in Section 2.3 of [Part3]). |
| Authors of specifications defining new header fields are advised to |  | Authors of specifications defining new header fields are advised to |
| skipping to change at page 30, line 36 |  | skipping to change at page 30, line 36 |
| type of redirect with the status code 303 (See Other) ([RFC2068], |  | type of redirect with the status code 303 (See Other) ([RFC2068], |
| Section 10.3.4). As user agents did not change their behavior to |  | Section 10.3.4). As user agents did not change their behavior to |
| maintain backwards compatibility, the first revision of HTTP/1.1 |  | maintain backwards compatibility, the first revision of HTTP/1.1 |
| added yet another status code, 307 (Temporary Redirect), for which |  | added yet another status code, 307 (Temporary Redirect), for which |
| the backwards compatibility problems did not apply ([RFC2616], |  | the backwards compatibility problems did not apply ([RFC2616], |
| Section 10.3.8). Over 10 years later, most user agents still do |  | Section 10.3.8). Over 10 years later, most user agents still do |
| method rewriting for status codes 301 and 302, therefore this |  | method rewriting for status codes 301 and 302, therefore this |
| specification makes that behavior compliant in case the original |  | specification makes that behavior compliant in case the original |
| request was POST. |  | request was POST. |
|  |  | A Location header field on a 3xx response indicates that a client MAY |
|  |  | automatically redirect to the URI provided; see Section 9.5. |
| Clients SHOULD detect and intervene in cyclical redirections (i.e., |  | Clients SHOULD detect and intervene in cyclical redirections (i.e., |
| "infinite" redirection loops). |  | "infinite" redirection loops). |
| 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. |
| 7.3.1. 300 Multiple Choices |  | 7.3.1. 300 Multiple Choices |
| skipping to change at page 34, line 5 |  | skipping to change at page 34, line 5 |
| 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 6.1.1, then the |  | that is known to be "safe", as defined in Section 6.1.1, then the |
| request MAY be automatically redirected by the user agent without |  | request MAY be automatically redirected by the user agent without |
| confirmation. Otherwise, the user agent MUST NOT automatically |  | confirmation. Otherwise, the user agent MUST NOT automatically |
| redirect the request unless it can be confirmed by the user, since |  | redirect the request unless it can be confirmed by the user, since |
| this might change the conditions under which the request was issued. |  | this might change the conditions under which the request was issued. |
|  |  | Note: This status code is similar to 302 Found, except that it |
|  |  | does not allow rewriting the request method from POST to GET. |
|  |  | This specification defines no equivalent counterpart for 301 Moved |
|  |  | Permanently. |
| 7.4. Client Error 4xx |  | 7.4. Client Error 4xx |
| The 4xx class of status code is intended for cases in which the |  | The 4xx class of status code is intended for cases in which the |
| client seems to have erred. Except when responding to a HEAD |  | client seems to have erred. Except when responding to a HEAD |
| request, the server SHOULD include a representation containing an |  | request, the server SHOULD include a representation containing an |
| explanation of the error situation, and whether it is a temporary or |  | explanation of the error situation, and whether it is a temporary or |
| permanent condition. These status codes are applicable to any |  | permanent condition. These status codes are applicable to any |
| request method. User agents SHOULD display any included |  | request method. User agents SHOULD display any included |
| representation to the user. |  | representation to the user. |
| skipping to change at page 39, line 20 |  | skipping to change at page 39, line 20 |
| any resource. |  | any resource. |
| 7.5.3. 502 Bad Gateway |  | 7.5.3. 502 Bad Gateway |
| The server, while acting as a gateway or proxy, received an invalid |  | The server, while acting as a gateway or proxy, received an invalid |
| response from the upstream server it accessed in attempting to |  | response from the upstream server it accessed in attempting to |
| fulfill the request. |  | fulfill the request. |
| 7.5.4. 503 Service Unavailable |  | 7.5.4. 503 Service Unavailable |
| The server is currently unable or unwilling to handle the request due |  | The server is currently unable to handle the request due to a |
| to reasons such as temporary overloading, maintenance of the server, |  | temporary overloading or maintenance of the server. |
| or rate limiting of the client. |  |  |
| The implication is that this is a temporary condition which will be |  | The implication is that this is a temporary condition which will be |
| alleviated after some delay. If known, the length of the delay MAY |  | alleviated after some delay. If known, the length of the delay MAY |
| be indicated in a Retry-After header field (Section 9.8). If no |  | be indicated in a Retry-After header field (Section 9.8). If no |
| Retry-After is given, the client SHOULD handle the response as it |  | Retry-After is given, the client SHOULD handle the response as it |
| would for a 500 response. |  | 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. |
| skipping to change at page 44, line 15 |  | skipping to change at page 44, line 15 |
| In practice, the date can be generated at any time during the message |  | In practice, the date can be generated at any time during the message |
| origination without affecting its semantic value. |  | origination without affecting its semantic value. |
| 9.3. Expect |  | 9.3. Expect |
| The "Expect" header field is used to indicate that particular server |  | The "Expect" header field is used to indicate that particular server |
| behaviors are required by the client. |  | behaviors are required by the client. |
| Expect = 1#expectation |  | Expect = 1#expectation |
| expectation = "100-continue" / expectation-extension |  | expectation = expect-name [ BWS "=" BWS expect-value ] |
| expectation-extension = token [ "=" ( token / quoted-string ) |  | *( OWS ";" [ OWS expect-param ] ) |
| *expect-params ] |  | expect-param = expect-name [ BWS "=" BWS expect-value ] |
| expect-params = ";" token [ "=" ( token / quoted-string ) ] |  |  |
| A server that does not understand or is unable to comply with any of |  | expect-name = token |
| the expectation values in the Expect field of a request MUST respond |  | expect-value = token / quoted-string |
| with appropriate error status code. The server MUST respond with a |  |  |
| 417 (Expectation Failed) status code if any of the expectations |  |  |
| cannot be met or, if there are other problems with the request, some |  |  |
| other 4xx status code. |  |  |
| This header field is defined with extensible syntax to allow for |  | If all received Expect header field(s) are syntactically valid but |
| future extensions. If a server receives a request containing an |  | contain an expectation that the recipient does not understand or |
| Expect field that includes an expectation-extension that it does not |  | cannot comply with, the recipient MUST respond with a 417 |
| support, it MUST respond with a 417 (Expectation Failed) status code. |  | (Expectation Failed) status code. A recipient of a syntactically |
|  |  | invalid Expectation header field MUST respond with a 4xx status code |
|  |  | other than 417. |
| Comparison of expectation values is case-insensitive for unquoted |  | The only expectation defined by this specification is: |
| tokens (including the 100-continue token), and is case-sensitive for |  |  |
| quoted-string expectation-extensions. |  |  |
| The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST |  | 100-continue |
| return a 417 (Expectation Failed) status code if it receives a |  |  |
| request with an expectation that it cannot meet. However, the Expect |  | The "100-continue" expectation is defined Section 6.2.3 of |
| header field itself is end-to-end; it MUST be forwarded if the |  | [Part1]. It does not support any expect-params. |
| request is forwarded. |  |  |
|  |  | Comparison is case-insensitive for names (expect-name), and case- |
|  |  | sensitive for values (expect-value). |
|  |  | The Expect mechanism is hop-by-hop: the above requirements apply to |
|  |  | any server, including proxies. However, the Expect header field |
|  |  | itself is end-to-end; it MUST be forwarded if 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 field. |  | Expect header field. |
| See Section 6.2.3 of [Part1] for the use of the 100 (Continue) status |  |  |
| code. |  |  |
| 9.4. From |  | 9.4. From |
| The "From" header field, if given, SHOULD contain an Internet e-mail |  | The "From" header field, if given, SHOULD contain an Internet e-mail |
| address for the human user who controls the requesting user agent. |  | address for the human user who controls the requesting user agent. |
| The address SHOULD be machine-usable, as defined by "mailbox" in |  | The address SHOULD be machine-usable, as defined by "mailbox" in |
| Section 3.4 of [RFC5322]: |  | Section 3.4 of [RFC5322]: |
| From = mailbox |  | From = mailbox |
| mailbox = <mailbox, defined in [RFC5322], Section 3.4> |  | mailbox = <mailbox, defined in [RFC5322], Section 3.4> |
| skipping to change at page 46, line 11 |  | skipping to change at page 46, line 11 |
| ([RFC3986], Section 5). |  | ([RFC3986], Section 5). |
| Location = URI-reference |  | Location = URI-reference |
| Examples are: |  | Examples are: |
| Location: http://www.example.org/pub/WWW/People.html#tim |  | Location: http://www.example.org/pub/WWW/People.html#tim |
| Location: /index.html |  | Location: /index.html |
|  |  | Note: Some recipients attempt to recover from Location fields that |
|  |  | are not valid URI references. This specification does not mandate |
|  |  | or define such processing, but does allow it (see Section 1.1). |
| 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. For instance, when it appears in a 201 |  | URI would not be appropriate. For instance, when it appears in a 201 |
| Created response, where the Location header field specifies the URI |  | Created response, where the Location header field specifies the URI |
| for the entire created resource. |  | for the entire created resource. |
| 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. Thus be aware that including fragment identifiers |  | identifiers. Thus be aware that including fragment identifiers |
| might inconvenience anyone relying on the semantics of the |  | might inconvenience anyone relying on the semantics of the |
| skipping to change at page 53, line 43 |  | skipping to change at page 54, line 37 |
| See Section 11 of [Part1]. |  | See Section 11 of [Part1]. |
| 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-17 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-18 |
| (work in progress), October 2011. |  | (work in progress), January 2012. |
| [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-17 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-18 |
| (work in progress), October 2011. |  | (work in progress), January 2012. |
| [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-17 (work in |  | Requests", draft-ietf-httpbis-p4-conditional-18 (work in |
| progress), October 2011. |  | progress), January 2012. |
| [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-17 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-18 (work |
| in progress), October 2011. |  | in progress), January 2012. |
| [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-17 (work in |  | 6: Caching", draft-ietf-httpbis-p6-cache-18 (work in |
| progress), October 2011. |  | progress), January 2012. |
| [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-17 (work in progress), |  | draft-ietf-httpbis-p7-auth-18 (work in progress), |
| October 2011. |  | January 2012. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |  | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |
| Resource Identifier (URI): Generic Syntax", STD 66, |  | Resource Identifier (URI): Generic Syntax", STD 66, |
| RFC 3986, January 2005. |  | RFC 3986, January 2005. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
| Specifications: ABNF", STD 68, RFC 5234, January 2008. |  | Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| skipping to change at page 56, line 4 |  | skipping to change at page 56, line 48 |
| able to make that determination based on the request method |  | able to make that determination based on the request method |
| semantics. Furthermore, allow user agents to rewrite the method from |  | semantics. Furthermore, allow user agents to rewrite the method from |
| POST to GET for status codes 301 and 302. (Sections 7.3.2, 7.3.3 and |  | POST to GET for status codes 301 and 302. (Sections 7.3.2, 7.3.3 and |
| 7.3.8) |  | 7.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 7.3.6) |  | repeat this single request via the proxy. (Section 7.3.6) |
| Define status 426 (Upgrade Required) (this was incorporated from |  | Define status 426 (Upgrade Required) (this was incorporated from |
| [RFC2817]). (Section 7.4.19) |  | [RFC2817]). (Section 7.4.19) |
| Change ABNF productions for header fields to only define the field |  | Change ABNF productions for header fields to only define the field |
| value. (Section 9) |  | value. (Section 9) |
| Reclassify "Allow" as response header field, removing the option to |  | Reclassify "Allow" as response header field, removing the option to |
| specify it in a PUT request. Relax the server requirement on the |  | specify it in a PUT request. Relax the server requirement on the |
| contents of the Allow header field and remove requirement on clients |  | contents of the Allow header field and remove requirement on clients |
| to always trust the header field value. (Section 9.1) |  | to always trust the header field value. (Section 9.1) |
|  |  | The ABNF for the Expect header field has been both fixed (allowing |
|  |  | parameters for value-less expectations as well) and simplified |
|  |  | (allowing trailing semicolons after "100-continue" when they were |
|  |  | invalid before). (Section 9.3) |
| Correct syntax of Location header field to allow URI references |  | Correct syntax of Location header field to allow URI references |
| (including relative references and fragments), as referred symbol |  | (including relative references and fragments), as referred symbol |
| "absoluteURI" wasn't what was expected, and add some clarifications |  | "absoluteURI" wasn't what was expected, and add some clarifications |
| as to when use of fragments would not be appropriate. (Section 9.5) |  | as to when use of fragments would not be appropriate. (Section 9.5) |
| Restrict Max-Forwards header field to OPTIONS and TRACE (previously, |  | Restrict Max-Forwards header field to OPTIONS and TRACE (previously, |
| extension methods could have used it as well). (Section 9.6) |  | extension methods could have used it as well). (Section 9.6) |
| Allow Referer field value of "about:blank" as alternative to not |  | Allow Referer field value of "about:blank" as alternative to not |
| specifying it. (Section 9.7) |  | specifying it. (Section 9.7) |
| In the description of the Server header field, the Via field was |  | In the description of the Server header field, the Via field was |
| described as a SHOULD. The requirement was and is stated correctly |  | described as a SHOULD. The requirement was and is stated correctly |
| in the description of the Via header field in Section 8.8 of [Part1]. |  | in the description of the Via header field in Section 8.8 of [Part1]. |
| (Section 9.9) |  | (Section 9.9) |
| Appendix B. Collected ABNF |  | Appendix B. Collected ABNF |
| Allow = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] |  | Allow = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] |
|  |  | BWS = <BWS, defined in [Part1], Section 1.2.2> |
| Date = HTTP-date |  | Date = HTTP-date |
| Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) |  | Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) |
| From = mailbox |  | From = mailbox |
| GMT = %x47.4D.54 ; GMT |  | GMT = %x47.4D.54 ; GMT |
| HTTP-date = rfc1123-date / obs-date |  | HTTP-date = rfc1123-date / obs-date |
| skipping to change at page 57, line 40 |  | skipping to change at page 58, line 44 |
| / %x53.75.6E ; Sun |  | / %x53.75.6E ; Sun |
| day-name-l = %x4D.6F.6E.64.61.79 ; Monday |  | day-name-l = %x4D.6F.6E.64.61.79 ; Monday |
| / %x54.75.65.73.64.61.79 ; Tuesday |  | / %x54.75.65.73.64.61.79 ; Tuesday |
| / %x57.65.64.6E.65.73.64.61.79 ; Wednesday |  | / %x57.65.64.6E.65.73.64.61.79 ; Wednesday |
| / %x54.68.75.72.73.64.61.79 ; Thursday |  | / %x54.68.75.72.73.64.61.79 ; Thursday |
| / %x46.72.69.64.61.79 ; Friday |  | / %x46.72.69.64.61.79 ; Friday |
| / %x53.61.74.75.72.64.61.79 ; Saturday |  | / %x53.61.74.75.72.64.61.79 ; Saturday |
| / %x53.75.6E.64.61.79 ; Sunday |  | / %x53.75.6E.64.61.79 ; Sunday |
| delta-seconds = 1*DIGIT |  | delta-seconds = 1*DIGIT |
| expect-params = ";" token [ "=" ( token / quoted-string ) ] |  | expect-name = token |
| expectation = "100-continue" / expectation-extension |  | expect-param = expect-name [ BWS "=" BWS expect-value ] |
| expectation-extension = token [ "=" ( token / quoted-string ) |  | expect-value = token / quoted-string |
| *expect-params ] |  | expectation = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [ |
|  |  | OWS expect-param ] ) |
| hour = 2DIGIT |  | hour = 2DIGIT |
| mailbox = <mailbox, defined in [RFC5322], Section 3.4> |  | mailbox = <mailbox, defined in [RFC5322], Section 3.4> |
| minute = 2DIGIT |  | minute = 2DIGIT |
| month = %x4A.61.6E ; Jan |  | month = %x4A.61.6E ; Jan |
| / %x46.65.62 ; Feb |  | / %x46.65.62 ; Feb |
| / %x4D.61.72 ; Mar |  | / %x4D.61.72 ; Mar |
| / %x41.70.72 ; Apr |  | / %x41.70.72 ; Apr |
| / %x4D.61.79 ; May |  | / %x4D.61.79 ; May |
| / %x4A.75.6E ; Jun |  | / %x4A.75.6E ; Jun |
| / %x4A.75.6C ; Jul |  | / %x4A.75.6C ; Jul |
| / %x41.75.67 ; Aug |  | / %x41.75.67 ; Aug |
| skipping to change at page 66, line 47 |  | skipping to change at page 67, line 47 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document |
| HTTP's error-handling philosophy" |  | HTTP's error-handling philosophy" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/231>: |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/231>: |
| "Considerations for new headers" |  | "Considerations for new headers" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/310>: "clarify 303 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/310>: "clarify 303 |
| redirect on HEAD" |  | redirect on HEAD" |
|  |  | C.19. Since draft-ietf-httpbis-p2-semantics-17 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location |
|  |  | header payload handling" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/255>: "Clarify |
|  |  | status code for rate limiting" (change backed out because a new |
|  |  | status code is being defined for this purpose) |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/312>: "should there |
|  |  | be a permanent variant of 307" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/325>: "When are |
|  |  | Location's semantics triggered?" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/327>: "'expect' |
|  |  | grammar missing OWS" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/329>: "header field |
|  |  | considerations: quoted-string vs use of double quotes" |
| Index |  | Index |
| 1 |  | 1 |
| 100 Continue (status code) 26 |  | 100 Continue (status code) 26 |
|  |  | 100-continue (expect value) 44 |
| 101 Switching Protocols (status code) 26 |  | 101 Switching Protocols (status code) 26 |
| 2 |  | 2 |
| 200 OK (status code) 27 |  | 200 OK (status code) 27 |
| 201 Created (status code) 27 |  | 201 Created (status code) 27 |
| 202 Accepted (status code) 28 |  | 202 Accepted (status code) 28 |
| 203 Non-Authoritative Information (status code) 28 |  | 203 Non-Authoritative Information (status code) 28 |
| 204 No Content (status code) 28 |  | 204 No Content (status code) 28 |
| 205 Reset Content (status code) 29 |  | 205 Reset Content (status code) 29 |
| 206 Partial Content (status code) 29 |  | 206 Partial Content (status code) 29 |
| skipping to change at page 67, line 32 |  | skipping to change at page 69, line 6 |
| 307 Temporary Redirect (status code) 33 |  | 307 Temporary Redirect (status code) 33 |
| 4 |  | 4 |
| 400 Bad Request (status code) 34 |  | 400 Bad Request (status code) 34 |
| 401 Unauthorized (status code) 34 |  | 401 Unauthorized (status code) 34 |
| 402 Payment Required (status code) 34 |  | 402 Payment Required (status code) 34 |
| 403 Forbidden (status code) 34 |  | 403 Forbidden (status code) 34 |
| 404 Not Found (status code) 35 |  | 404 Not Found (status code) 35 |
| 405 Method Not Allowed (status code) 35 |  | 405 Method Not Allowed (status code) 35 |
| 406 Not Acceptable (status code) 35 |  | 406 Not Acceptable (status code) 35 |
| 407 Proxy Authentication Required (status code) 35 |  | 407 Proxy Authentication Required (status code) 36 |
| 408 Request Timeout (status code) 36 |  | 408 Request Timeout (status code) 36 |
| 409 Conflict (status code) 36 |  | 409 Conflict (status code) 36 |
| 410 Gone (status code) 36 |  | 410 Gone (status code) 36 |
| 411 Length Required (status code) 37 |  | 411 Length Required (status code) 37 |
| 412 Precondition Failed (status code) 37 |  | 412 Precondition Failed (status code) 37 |
| 413 Request Representation Too Large (status code) 37 |  | 413 Request Representation Too Large (status code) 37 |
| 414 URI Too Long (status code) 37 |  | 414 URI Too Long (status code) 37 |
| 415 Unsupported Media Type (status code) 37 |  | 415 Unsupported Media Type (status code) 37 |
| 416 Requested Range Not Satisfiable (status code) 38 |  | 416 Requested Range Not Satisfiable (status code) 38 |
| 417 Expectation Failed (status code) 38 |  | 417 Expectation Failed (status code) 38 |
| skipping to change at page 68, line 17 |  | skipping to change at page 69, line 39 |
| C |  | C |
| CONNECT method 24 |  | CONNECT method 24 |
| D |  | D |
| Date header field 43 |  | Date header field 43 |
| DELETE method 23 |  | DELETE method 23 |
| E |  | E |
| Expect header field 44 |  | Expect header field 44 |
|  |  | Expect Values |
|  |  | 100-continue 44 |
| F |  | F |
| From header field 44 |  | From header field 44 |
| G |  | G |
| GET method 19 |  | GET method 19 |
| Grammar |  | Grammar |
| Allow 42 |  | Allow 42 |
| asctime-date 42 |  | asctime-date 42 |
| Date 43 |  | Date 43 |
| date1 41 |  | date1 41 |
| day 41 |  | day 41 |
| day-name 41 |  | day-name 41 |
| day-name-l 41 |  | day-name-l 41 |
| delta-seconds 47 |  | delta-seconds 47 |
| Expect 44 |  | Expect 44 |
| expect-params 44 |  | expect-name 44 |
|  |  | expect-param 44 |
|  |  | expect-value 44 |
| expectation 44 |  | expectation 44 |
| expectation-extension 44 |  | extension-code 13 |
| extension-code 12 |  |  |
| From 45 |  | From 45 |
| GMT 41 |  | GMT 41 |
| hour 41 |  | hour 41 |
| HTTP-date 40 |  | HTTP-date 40 |
| Location 45 |  | Location 45 |
| Max-Forwards 46 |  | Max-Forwards 46 |
| Method 7 |  | Method 7 |
| minute 41 |  | minute 41 |
| month 41 |  | month 41 |
| obs-date 41 |  | obs-date 41 |
| Reason-Phrase 12 |  | Reason-Phrase 13 |
| Referer 47 |  | Referer 47 |
| Retry-After 47 |  | Retry-After 47 |
| rfc850-date 42 |  | rfc850-date 42 |
| rfc1123-date 41 |  | rfc1123-date 41 |
| second 41 |  | second 41 |
| Server 48 |  | Server 48 |
| Status-Code 12 |  | Status-Code 13 |
| time-of-day 41 |  | time-of-day 41 |
| User-Agent 49 |  | User-Agent 49 |
| year 41 |  | year 41 |
| H |  | H |
| HEAD method 19 |  | HEAD method 19 |
| Header Fields |  | Header Fields |
| Allow 42 |  | Allow 42 |
| Date 43 |  | Date 43 |
| Expect 44 |  | Expect 44 |
| skipping to change at page 70, line 33 |  | skipping to change at page 72, line 10 |
| 305 Use Proxy 33 |  | 305 Use Proxy 33 |
| 306 (Unused) 33 |  | 306 (Unused) 33 |
| 307 Temporary Redirect 33 |  | 307 Temporary Redirect 33 |
| 400 Bad Request 34 |  | 400 Bad Request 34 |
| 401 Unauthorized 34 |  | 401 Unauthorized 34 |
| 402 Payment Required 34 |  | 402 Payment Required 34 |
| 403 Forbidden 34 |  | 403 Forbidden 34 |
| 404 Not Found 35 |  | 404 Not Found 35 |
| 405 Method Not Allowed 35 |  | 405 Method Not Allowed 35 |
| 406 Not Acceptable 35 |  | 406 Not Acceptable 35 |
| 407 Proxy Authentication Required 35 |  | 407 Proxy Authentication Required 36 |
| 408 Request Timeout 36 |  | 408 Request Timeout 36 |
| 409 Conflict 36 |  | 409 Conflict 36 |
| 410 Gone 36 |  | 410 Gone 36 |
| 411 Length Required 37 |  | 411 Length Required 37 |
| 412 Precondition Failed 37 |  | 412 Precondition Failed 37 |
| 413 Request Representation Too Large 37 |  | 413 Request Representation Too Large 37 |
| 414 URI Too Long 37 |  | 414 URI Too Long 37 |
| 415 Unsupported Media Type 37 |  | 415 Unsupported Media Type 37 |
| 416 Requested Range Not Satisfiable 38 |  | 416 Requested Range Not Satisfiable 38 |
| 417 Expectation Failed 38 |  | 417 Expectation Failed 38 |
End of changes. 44 change blocks.
| 93 lines changed or deleted |  | 143 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/