| draft-ietf-httpbis-p2-semantics-25.txt |  | draft-ietf-httpbis-p2-semantics-26.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2616 (if approved) J. Reschke, Ed. |  | Obsoletes: 2616 (if approved) J. Reschke, Ed. |
| Updates: 2817 (if approved) greenbytes |  | Updates: 2817 (if approved) greenbytes |
| Intended status: Standards Track November 17, 2013 |  | Intended status: Standards Track February 6, 2014 |
| Expires: May 21, 2014 |  | Expires: August 10, 2014 |
| Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |  | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
| draft-ietf-httpbis-p2-semantics-25 |  | draft-ietf-httpbis-p2-semantics-26 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is a stateless application- |
| protocol for distributed, collaborative, hypertext information |  | level protocol for distributed, collaborative, hypertext information |
| systems. This document defines the semantics of HTTP/1.1 messages, |  | systems. This document defines the semantics of HTTP/1.1 messages, |
| as expressed by request methods, request header fields, response |  | as expressed by request methods, request header fields, response |
| status codes, and response header fields, along with the payload of |  | status codes, and response header fields, along with the payload of |
| messages (metadata and body content) and mechanisms for content |  | messages (metadata and body content) and mechanisms for content |
| negotiation. |  | negotiation. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft takes place on the HTTPBIS working group |  | Discussion of this draft takes place on the HTTPBIS working group |
| mailing list (ietf-http-wg@w3.org), which is archived at |  | 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 E.2. |  | The changes in this draft are summarized in Appendix E.3. |
| 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 21, 2014. |  | This Internet-Draft will expire on August 10, 2014. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2013 IETF Trust and the persons identified as the |  | Copyright (c) 2014 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 19 |  | skipping to change at page 3, line 19 |
| 4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24 |  | 4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 4.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 4.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 4.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 26 |  | 4.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 26 |
| 4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 30 |  | 4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 30 |
| 4.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 4.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 31 |
| 4.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 4.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 5. Request Header Fields . . . . . . . . . . . . . . . . . . . . 33 |  | 5. Request Header Fields . . . . . . . . . . . . . . . . . . . . 33 |
| 5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 34 |  | 5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 5.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36 |  | 5.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36 |
| 5.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36 |  | 5.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36 |
| 5.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 37 |  | 5.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 37 |
| 5.3.1. Quality Values . . . . . . . . . . . . . . . . . . . . 37 |  | 5.3.1. Quality Values . . . . . . . . . . . . . . . . . . . . 37 |
| 5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38 |  | 5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38 |
| 5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40 |  | 5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40 |
| 5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41 |  | 5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41 |
| 5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42 |  | 5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42 |
| 5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43 |  | 5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43 |
| 5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 44 |  | 5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 44 |
| 5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44 |  | 5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44 |
| 5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 45 |  | 5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 44 |
| 5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 46 |  | 5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 46 |
| 6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47 |  | 6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47 |
| 6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 48 |  | 6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 47 |
| 6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 50 |  | 6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 49 |
| 6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 50 |  | 6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 49 |
| 6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50 |  | 6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 49 |
| 6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 50 |
| 6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 50 |
| 6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 52 |  | 6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 51 |
| 6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 52 |  | 6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 51 |
| 6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 52 |  | 6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 51 |
| 6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 53 |  | 6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 52 |
| 6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 53 |  | 6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 52 |
| 6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 54 |  | 6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 53 |
| 6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 55 |  | 6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 54 |
| 6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 56 |  | 6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 55 |
| 6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 56 |  | 6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 55 |
| 6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 57 |  | 6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 56 |
| 6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 57 |  | 6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 56 |
| 6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 58 |  | 6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 56 |
| 6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 58 |  | 6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 57 |
| 6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58 |  | 6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 57 |
| 6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 58 |  | 6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 57 |
| 6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 58 |  | 6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 57 |
| 6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 59 |  | 6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 57 |
| 6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 59 |  | 6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 58 |
| 6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 59 |  | 6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 58 |
| 6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 59 |  | 6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 58 |
| 6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 60 |  | 6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 59 |
| 6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 60 |  | 6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 59 |
| 6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60 |  | 6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 59 |
| 6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 61 |  | 6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 60 |
| 6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 61 |  | 6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 60 |
| 6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61 |  | 6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 60 |
| 6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 62 |  | 6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 60 |
| 6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62 |  | 6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 61 |
| 6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62 |  | 6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 61 |
| 6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62 |  | 6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 61 |
| 6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 63 |  | 6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 61 |
| 6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 63 |  | 6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 62 |
| 6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 63 |  | 6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 62 |
| 6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 63 |  | 6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 62 |
| 6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 63 |  | 6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 62 |
| 6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 63 |  | 6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 62 |
| 7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 64 |  | 7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 63 |
| 7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 64 |  | 7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 63 |
| 7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 64 |  | 7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 63 |
| 7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 68 |  | 7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 67 |
| 7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69 |  | 7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 68 |
| 7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70 |  | 7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 69 |
| 7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71 |  | 7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 70 |
| 7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72 |  | 7.3. Authentication Challenges . . . . . . . . . . . . . . . . 71 |
| 7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 72 |  | 7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 71 |
| 7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72 |  | 7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 71 |
| 7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 73 |  | 7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 72 |
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 |  | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 |
| 8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 74 |  | 8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 73 |
| 8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 74 |  | 8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 73 |
| 8.1.2. Considerations for New Methods . . . . . . . . . . . . 74 |  | 8.1.2. Considerations for New Methods . . . . . . . . . . . . 73 |
| 8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 75 |  | 8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 74 |
| 8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 75 |  | 8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 74 |
| 8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 75 |  | 8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 74 |
| 8.2.2. Considerations for New Status Codes . . . . . . . . . 76 |  | 8.2.2. Considerations for New Status Codes . . . . . . . . . 75 |
| 8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 76 |  | 8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 75 |
| 8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77 |  | 8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 76 |
| 8.3.1. Considerations for New Header Fields . . . . . . . . . 78 |  | 8.3.1. Considerations for New Header Fields . . . . . . . . . 77 |
| 8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80 |  | 8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 79 |
| 8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80 |  | 8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 79 |
| 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 80 |  | 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 80 |
| 8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81 |  | 8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 80 |
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 81 |  | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 80 |
| 9.1. Attacks Based On File and Path Names . . . . . . . . . . . 81 |  | 9.1. Attacks Based On File and Path Names . . . . . . . . . . . 81 |
| 9.2. Personal Information . . . . . . . . . . . . . . . . . . . 82 |  | 9.2. Attacks Based On Command, Code, or Query Injection . . . . 81 |
| 9.3. Sensitive Information in URIs . . . . . . . . . . . . . . 82 |  | 9.3. Disclosure of Personal Information . . . . . . . . . . . . 82 |
| 9.4. Product Information . . . . . . . . . . . . . . . . . . . 82 |  | 9.4. Disclosure of Sensitive Information in URIs . . . . . . . 82 |
| 9.5. Fragment after Redirects . . . . . . . . . . . . . . . . . 83 |  | 9.5. Disclosure of Fragment after Redirects . . . . . . . . . . 82 |
| 9.6. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 83 |  | 9.6. Disclosure of Product Information . . . . . . . . . . . . 83 |
|  |  | 9.7. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 83 |
| 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 |  | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 |
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84 |  | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84 |
| 11.1. Normative References . . . . . . . . . . . . . . . . . . . 84 |  | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 84 |
| 11.2. Informative References . . . . . . . . . . . . . . . . . . 85 |  | 11.2. Informative References . . . . . . . . . . . . . . . . . . 85 |
| Appendix A. Differences between HTTP and MIME . . . . . . . . . . 87 |  | Appendix A. Differences between HTTP and MIME . . . . . . . . . . 87 |
| A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88 |  | A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88 |
| A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 88 |  | A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 88 |
| A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 88 |  | A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 88 |
| A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 88 |  | A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 89 |
| A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 89 |  | A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 89 |
| A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 89 |  | A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 89 |
| Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 89 |  | Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 89 |
| Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 92 |  | Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 92 |
| Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 92 |  | Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 92 |
| Appendix E. Change Log (to be removed by RFC Editor before |  | Appendix E. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 95 |  | publication) . . . . . . . . . . . . . . . . . . . . 95 |
| E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 95 |  | E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 95 |
| E.2. Since draft-ietf-httpbis-p2-semantics-24 . . . . . . . . . 95 |  | E.2. Since draft-ietf-httpbis-p2-semantics-24 . . . . . . . . . 95 |
|  |  | E.3. Since draft-ietf-httpbis-p2-semantics-25 . . . . . . . . . 96 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 |
| 1. Introduction |  | 1. Introduction |
| Each Hypertext Transfer Protocol (HTTP) message is either a request |  | Each Hypertext Transfer Protocol (HTTP) message is either a request |
| or a response. A server listens on a connection for a request, |  | or a response. A server listens on a connection for a request, |
| parses each message received, interprets the message semantics in |  | parses each message received, interprets the message semantics in |
| relation to the identified request target, and responds to that |  | relation to the identified request target, and responds to that |
| request with one or more response messages. A client constructs |  | request with one or more response messages. A client constructs |
| request messages to communicate specific intentions, and examines |  | request messages to communicate specific intentions, and examines |
| skipping to change at page 6, line 47 |  | skipping to change at page 6, line 47 |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in [RFC2119]. |  | document are to be interpreted as described in [RFC2119]. |
| Conformance criteria and considerations regarding error handling are |  | Conformance criteria and considerations regarding error handling are |
| defined in Section 2.5 of [Part1]. |  | defined in Section 2.5 of [Part1]. |
| 1.2. Syntax Notation |  | 1.2. Syntax Notation |
| This specification uses the Augmented Backus-Naur Form (ABNF) |  | This specification uses the Augmented Backus-Naur Form (ABNF) |
| notation of [RFC5234] with the list rule extension defined in Section |  | notation of [RFC5234] with a list extension, defined in Section 7 of |
| 7 of [Part1]. Appendix C describes rules imported from other |  | [Part1], that allows for compact definition of comma-separated lists |
| documents. Appendix D shows the collected ABNF with the list rule |  | using a '#' operator (similar to how the '*' operator indicates |
| expanded. |  | repetition). Appendix C describes rules imported from other |
|  |  | documents. Appendix D shows the collected grammar with all list |
|  |  | operators expanded to standard ABNF notation. |
| This specification uses the terms "character", "character encoding |  | This specification uses the terms "character", "character encoding |
| scheme", "charset", and "protocol element" as they are defined in |  | scheme", "charset", and "protocol element" as they are defined in |
| [RFC6365]. |  | [RFC6365]. |
| 2. Resources |  | 2. Resources |
| The target of an HTTP request is called a resource. HTTP does not |  | The target of an HTTP request is called a resource. HTTP does not |
| limit the nature of a resource; it merely defines an interface that |  | limit the nature of a resource; it merely defines an interface that |
| might be used to interact with resources. Each resource is |  | might be used to interact with resources. Each resource is |
| skipping to change at page 7, line 24 |  | skipping to change at page 7, line 26 |
| When a client constructs an HTTP/1.1 request message, it sends the |  | When a client constructs an HTTP/1.1 request message, it sends the |
| target URI in one of various forms, as defined in (Section 5.3 of |  | target URI in one of various forms, as defined in (Section 5.3 of |
| [Part1]). When a request is received, the server reconstructs an |  | [Part1]). When a request is received, the server reconstructs an |
| effective request URI for the target resource (Section 5.5 of |  | effective request URI for the target resource (Section 5.5 of |
| [Part1]). |  | [Part1]). |
| One design goal of HTTP is to separate resource identification from |  | One design goal of HTTP is to separate resource identification from |
| request semantics, which is made possible by vesting the request |  | request semantics, which is made possible by vesting the request |
| semantics in the request method (Section 4) and a few request- |  | semantics in the request method (Section 4) and a few request- |
| modifying header fields (Section 5). Resource owners SHOULD NOT |  | modifying header fields (Section 5). If there is a conflict between |
| include request semantics within a URI, such as by specifying an |  | the method semantics and any semantic implied by the URI itself, as |
| action to invoke within the path or query components of the effective |  | described in Section 4.2.1, the method semantics take precedence. |
| request URI, unless those semantics are disabled when they are |  |  |
| inconsistent with the request method. |  |  |
| 3. Representations |  | 3. Representations |
| If we consider that a resource could be anything, and that the |  | Considering that a resource could be anything, and that the uniform |
| uniform interface provided by HTTP is similar to a window through |  | interface provided by HTTP is similar to a window through which one |
| which one can observe and act upon such a thing only through the |  | can observe and act upon such a thing only through the communication |
| communication of messages to some independent actor on the other |  | of messages to some independent actor on the other side, an |
| side, then we need an abstraction to represent ("take the place of") |  | abstraction is needed to represent ("take the place of") the current |
| the current or desired state of that thing in our communications. We |  | or desired state of that thing in our communications. That |
| call that abstraction a representation [REST]. |  | abstraction is called a representation [REST]. |
| For the purposes of HTTP, a "representation" is information that is |  | For the purposes of HTTP, a "representation" is information that is |
| intended to reflect a past, current, or desired state of a given |  | intended to reflect a past, current, or desired state of a given |
| resource, in a format that can be readily communicated via the |  | resource, in a format that can be readily communicated via the |
| protocol, and that consists of a set of representation metadata and a |  | protocol, and that consists of a set of representation metadata and a |
| potentially unbounded stream of representation data. |  | potentially unbounded stream of representation data. |
| An origin server might be provided with, or capable of generating, |  | An origin server might be provided with, or capable of generating, |
| multiple representations that are each intended to reflect the |  | multiple representations that are each intended to reflect the |
| current state of a target resource. In such cases, some algorithm is |  | current state of a target resource. In such cases, some algorithm is |
| used by the origin server to select one of those representations as |  | used by the origin server to select one of those representations as |
| most applicable to a given request, usually based on content |  | most applicable to a given request, usually based on content |
| negotiation. We refer to that one representation as the "selected |  | negotiation. This "selected representation" is used to provide the |
| representation" and use its particular data and metadata for |  | data and metadata for evaluating conditional requests [Part4] and |
| evaluating conditional requests [Part4] and constructing the payload |  | constructing the payload for 200 (OK) and 304 (Not Modified) |
| for 200 (OK) and 304 (Not Modified) responses to GET (Section 4.3.1). |  | responses to GET (Section 4.3.1). |
| 3.1. Representation Metadata |  | 3.1. Representation Metadata |
| Representation header fields provide metadata about the |  | Representation header fields provide metadata about the |
| representation. When a message includes a payload body, the |  | representation. When a message includes a payload body, the |
| representation header fields describe how to interpret the |  | representation header fields describe how to interpret the |
| representation data enclosed in the payload body. In a response to a |  | representation data enclosed in the payload body. In a response to a |
| HEAD request, the representation header fields describe the |  | HEAD request, the representation header fields describe the |
| representation data that would have been enclosed in the payload body |  | representation data that would have been enclosed in the payload body |
| if the same request had been a GET. |  | if the same request had been a GET. |
| skipping to change at page 8, line 45 |  | skipping to change at page 8, line 44 |
| to provide open and extensible data typing and type negotiation. |  | to provide open and extensible data typing and type negotiation. |
| Media types define both a data format and various processing models: |  | Media types define both a data format and various processing models: |
| how to process that data in accordance with each context in which it |  | how to process that data in accordance with each context in which it |
| is received. |  | is received. |
| media-type = type "/" subtype *( OWS ";" OWS parameter ) |  | media-type = type "/" subtype *( OWS ";" OWS parameter ) |
| type = token |  | type = token |
| subtype = token |  | subtype = token |
| The type/subtype MAY be followed by parameters in the form of |  | The type/subtype MAY be followed by parameters in the form of |
| attribute/value pairs. |  | name=value pairs. |
| parameter = attribute "=" value |  | parameter = token "=" ( token / quoted-string ) |
| attribute = token |  |  |
| value = word |  |  |
| The type, subtype, and parameter attribute names are case- |  | The type, subtype, and parameter name tokens are case-insensitive. |
| insensitive. Parameter values might or might not be case-sensitive, |  | Parameter values might or might not be case-sensitive, depending on |
| depending on the semantics of the parameter name. The presence or |  | the semantics of the parameter name. The presence or absence of a |
| absence of a parameter might be significant to the processing of a |  | parameter might be significant to the processing of a media-type, |
| media-type, depending on its definition within the media type |  | depending on its definition within the media type registry. |
| registry. |  |  |
| A parameter value that matches the token production can be |  | A parameter value that matches the token production can be |
| transmitted as either a token or within a quoted-string. The quoted |  | transmitted as either a token or within a quoted-string. The quoted |
| and unquoted values are equivalent. For example, the following |  | and unquoted values are equivalent. For example, the following |
| examples are all equivalent, but the first is preferred for |  | examples are all equivalent, but the first is preferred for |
| consistency: |  | consistency: |
| text/html;charset=utf-8 |  | text/html;charset=utf-8 |
| text/html;charset=UTF-8 |  | text/html;charset=UTF-8 |
| Text/HTML;Charset="utf-8" |  | Text/HTML;Charset="utf-8" |
| skipping to change at page 12, line 25 |  | skipping to change at page 12, line 25 |
| Content-Encoding = 1#content-coding |  | Content-Encoding = 1#content-coding |
| An example of its use is |  | An example of its use is |
| Content-Encoding: gzip |  | Content-Encoding: gzip |
| If one or more encodings have been applied to a representation, the |  | If one or more encodings have been applied to a representation, the |
| sender that applied the encodings MUST generate a Content-Encoding |  | sender that applied the encodings MUST generate a Content-Encoding |
| header field that lists the content codings in the order in which |  | header field that lists the content codings in the order in which |
| they were applied. Additional information about the encoding |  | they were applied. Additional information about the encoding |
| parameters MAY be provided by other header fields not defined by this |  | parameters can be provided by other header fields not defined by this |
| specification. |  | specification. |
| Unlike Transfer-Encoding (Section 3.3.1 of [Part1]), the codings |  | Unlike Transfer-Encoding (Section 3.3.1 of [Part1]), the codings |
| listed in Content-Encoding are a characteristic of the |  | listed in Content-Encoding are a characteristic of the |
| representation; the representation is defined in terms of the coded |  | representation; the representation is defined in terms of the coded |
| form, and all other metadata about the representation is about the |  | form, and all other metadata about the representation is about the |
| coded form unless otherwise noted in the metadata definition. |  | coded form unless otherwise noted in the metadata definition. |
| Typically, the representation is only decoded just prior to rendering |  | Typically, the representation is only decoded just prior to rendering |
| or analogous usage. |  | or analogous usage. |
| skipping to change at page 14, line 47 |  | skipping to change at page 14, line 47 |
| resource identified by the Content-Location field-value. However, |  | resource identified by the Content-Location field-value. However, |
| such an assertion cannot be trusted unless it can be verified by |  | such an assertion cannot be trusted unless it can be verified by |
| other means (not defined by this specification). The information |  | other means (not defined by this specification). The information |
| might still be useful for revision history links. |  | might still be useful for revision history links. |
| o Otherwise, the payload is unidentified. |  | o Otherwise, the payload is unidentified. |
| For a response message, the following rules are applied in order |  | For a response message, the following rules are applied in order |
| until a match is found: |  | until a match is found: |
| 1. If the request is GET or HEAD and the response status code is 200 |  | 1. If the request method is GET or HEAD and the response status code |
| (OK), 204 (No Content), 206 (Partial Content), or 304 (Not |  | is 200 (OK), 204 (No Content), 206 (Partial Content), or 304 (Not |
| Modified), the payload is a representation of the resource |  | Modified), the payload is a representation of the resource |
| identified by the effective request URI (Section 5.5 of [Part1]). |  | identified by the effective request URI (Section 5.5 of [Part1]). |
| 2. If the request is GET or HEAD and the response status code is 203 |  | 2. If the request method is GET or HEAD and the response status code |
| (Non-Authoritative Information), the payload is a potentially |  | is 203 (Non-Authoritative Information), the payload is a |
| modified or enhanced representation of the target resource as |  | potentially modified or enhanced representation of the target |
| provided by an intermediary. |  | resource as provided by an intermediary. |
| 3. If the response has a Content-Location header field and its |  | 3. If the response has a Content-Location header field and its |
| field-value is a reference to the same URI as the effective |  | field-value is a reference to the same URI as the effective |
| request URI, the payload is a representation of the resource |  | request URI, the payload is a representation of the resource |
| identified by the effective request URI. |  | identified by the effective request URI. |
| 4. If the response has a Content-Location header field and its |  | 4. If the response has a Content-Location header field and its |
| field-value is a reference to a URI different from the effective |  | field-value is a reference to a URI different from the effective |
| request URI, then the sender asserts that the payload is a |  | request URI, then the sender asserts that the payload is a |
| representation of the resource identified by the Content-Location |  | representation of the resource identified by the Content-Location |
| skipping to change at page 15, line 48 |  | skipping to change at page 15, line 48 |
| It has the same syntax and semantics as the header field of the same |  | It has the same syntax and semantics as the header field of the same |
| name defined for MIME body parts in Section 4 of [RFC2557]. However, |  | name defined for MIME body parts in Section 4 of [RFC2557]. However, |
| its appearance in an HTTP message has some special implications for |  | its appearance in an HTTP message has some special implications for |
| HTTP recipients. |  | HTTP recipients. |
| If Content-Location is included in a 2xx (Successful) response |  | If Content-Location is included in a 2xx (Successful) response |
| message and its value refers (after conversion to absolute form) to a |  | message and its value refers (after conversion to absolute form) to a |
| URI that is the same as the effective request URI, then the recipient |  | URI that is the same as the effective request URI, then the recipient |
| MAY consider the payload to be a current representation of that |  | MAY consider the payload to be a current representation of that |
| resource at the time indicated by the message origination date. For |  | resource at the time indicated by the message origination date. For |
| a GET or HEAD request, this is the same as the default semantics when |  | a GET (Section 4.3.1) or HEAD (Section 4.3.2) request, this is the |
| no Content-Location is provided by the server. For a state-changing |  | same as the default semantics when no Content-Location is provided by |
| request like PUT or POST, it implies that the server's response |  | the server. For a state-changing request like PUT (Section 4.3.4) or |
| contains the new representation of that resource, thereby |  | POST (Section 4.3.3), it implies that the server's response contains |
| distinguishing it from representations that might only report about |  | the new representation of that resource, thereby distinguishing it |
| the action (e.g., "It worked!"). This allows authoring applications |  | from representations that might only report about the action (e.g., |
| to update their local copies without the need for a subsequent GET |  | "It worked!"). This allows authoring applications to update their |
| request. |  | local copies without the need for a subsequent GET request. |
| If Content-Location is included in a 2xx (Successful) response |  | If Content-Location is included in a 2xx (Successful) response |
| message and its field-value refers to a URI that differs from the |  | message and its field-value refers to a URI that differs from the |
| effective request URI, then the origin server claims that the URI is |  | effective request URI, then the origin server claims that the URI is |
| an identifier for a different resource corresponding to the enclosed |  | an identifier for a different resource corresponding to the enclosed |
| representation. Such a claim can only be trusted if both identifiers |  | representation. Such a claim can only be trusted if both identifiers |
| share the same resource owner, which cannot be programmatically |  | share the same resource owner, which cannot be programmatically |
| determined via HTTP. |  | determined via HTTP. |
| o For a response to a GET or HEAD request, this is an indication |  | o For a response to a GET or HEAD request, this is an indication |
| skipping to change at page 17, line 39 |  | skipping to change at page 17, line 39 |
| the message "payload". In some cases, a payload might contain only |  | the message "payload". In some cases, a payload might contain only |
| the associated representation's header fields (e.g., responses to |  | the associated representation's header fields (e.g., responses to |
| HEAD) or only some part(s) of the representation data (e.g., the 206 |  | HEAD) or only some part(s) of the representation data (e.g., the 206 |
| (Partial Content) status code). |  | (Partial Content) status code). |
| The purpose of a payload in a request is defined by the method |  | The purpose of a payload in a request is defined by the method |
| semantics. For example, a representation in the payload of a PUT |  | semantics. For example, a representation in the payload of a PUT |
| request (Section 4.3.4) represents the desired state of the target |  | request (Section 4.3.4) represents the desired state of the target |
| resource if the request is successfully applied, whereas a |  | resource if the request is successfully applied, whereas a |
| representation in the payload of a POST request (Section 4.3.3) |  | representation in the payload of a POST request (Section 4.3.3) |
| represents an anonymous resource for providing data to be processed, |  | represents information to be processed by the target resource. |
| such as the information that a user entered within an HTML form. |  |  |
| In a response, the payload's purpose is defined by both the request |  | In a response, the payload's purpose is defined by both the request |
| method and the response status code. For example, the payload of a |  | method and the response status code. For example, the payload of a |
| 200 (OK) response to GET (Section 4.3.1) represents the current state |  | 200 (OK) response to GET (Section 4.3.1) represents the current state |
| of the target resource, as observed at the time of the message |  | of the target resource, as observed at the time of the message |
| origination date (Section 7.1.1.2), whereas the payload of the same |  | origination date (Section 7.1.1.2), whereas the payload of the same |
| status code in a response to POST might represent either the |  | status code in a response to POST might represent either the |
| processing result or the new state of the target resource after |  | processing result or the new state of the target resource after |
| applying the processing. Response messages with an error status code |  | applying the processing. Response messages with an error status code |
| usually contain a payload that represents the error condition, such |  | usually contain a payload that represents the error condition, such |
| skipping to change at page 18, line 16 |  | skipping to change at page 18, line 15 |
| Header fields that specifically describe the payload, rather than the |  | Header fields that specifically describe the payload, rather than the |
| associated representation, are referred to as "payload header |  | associated representation, are referred to as "payload header |
| fields". Payload header fields are defined in other parts of this |  | fields". Payload header fields are defined in other parts of this |
| specification, due to their impact on message parsing. |  | specification, due to their impact on message parsing. |
| +-------------------+--------------------------+ |  | +-------------------+--------------------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +-------------------+--------------------------+ |  | +-------------------+--------------------------+ |
| | Content-Length | Section 3.3.2 of [Part1] | |  | | Content-Length | Section 3.3.2 of [Part1] | |
| | Content-Range | Section 4.2 of [Part5] | |  | | Content-Range | Section 4.2 of [Part5] | |
|  |  | | Trailer | Section 4.4 of [Part1] | |
| | Transfer-Encoding | Section 3.3.1 of [Part1] | |  | | Transfer-Encoding | Section 3.3.1 of [Part1] | |
| +-------------------+--------------------------+ |  | +-------------------+--------------------------+ |
| 3.4. Content Negotiation |  | 3.4. Content Negotiation |
| When responses convey payload information, whether indicating a |  | When responses convey payload information, whether indicating a |
| success or an error, the origin server often has different ways of |  | success or an error, the origin server often has different ways of |
| representing that information; for example, in different formats, |  | representing that information; for example, in different formats, |
| languages, or encodings. Likewise, different users or user agents |  | languages, or encodings. Likewise, different users or user agents |
| might have differing capabilities, characteristics, or preferences |  | might have differing capabilities, characteristics, or preferences |
| skipping to change at page 19, line 50 |  | skipping to change at page 19, line 50 |
| algorithms for generating responses to a request; and, |  | algorithms for generating responses to a request; and, |
| o It limits the reusability of responses for shared caching. |  | o It limits the reusability of responses for shared caching. |
| A user agent cannot rely on proactive negotiation preferences being |  | A user agent cannot rely on proactive negotiation preferences being |
| consistently honored, since the origin server might not implement |  | consistently honored, since the origin server might not implement |
| proactive negotiation for the requested resource or might decide that |  | proactive negotiation for the requested resource or might decide that |
| sending a response that doesn't conform to the user agent's |  | sending a response that doesn't conform to the user agent's |
| preferences is better than sending a 406 (Not Acceptable) response. |  | preferences is better than sending a 406 (Not Acceptable) response. |
| An origin server MAY generate a Vary header field (Section 7.1.4) in |  | A Vary header field (Section 7.1.4) is often sent in a response |
| responses that are subject to proactive negotiation to indicate what |  | subject to proactive negotiation to indicate what parts of the |
| parameters of request information might be used in its selection |  | request information were used in the selection algorithm. |
| algorithm, thereby providing a means for recipients to determine the |  |  |
| reusability of that same response for user agents with differing |  |  |
| request information. |  |  |
| 3.4.2. Reactive Negotiation |  | 3.4.2. Reactive Negotiation |
| With reactive negotiation (a.k.a., agent-driven negotiation), |  | With reactive negotiation (a.k.a., agent-driven negotiation), |
| selection of the best response representation (regardless of the |  | selection of the best response representation (regardless of the |
| status code) is performed by the user agent after receiving an |  | status code) is performed by the user agent after receiving an |
| initial response from the origin server that contains a list of |  | initial response from the origin server that contains a list of |
| resources for alternative representations. If the user agent is not |  | resources for alternative representations. If the user agent is not |
| satisfied by the initial response representation, it can perform a |  | satisfied by the initial response representation, it can perform a |
| GET request on one or more of the alternative resources, selected |  | GET request on one or more of the alternative resources, selected |
| skipping to change at page 22, line 27 |  | skipping to change at page 22, line 27 |
| | | target resource. | | |  | | | target resource. | | |
| | CONNECT | Establish a tunnel to the server identified by | 4.3.6 | |  | | CONNECT | Establish a tunnel to the server identified by | 4.3.6 | |
| | | the target resource. | | |  | | | the target resource. | | |
| | OPTIONS | Describe the communication options for the | 4.3.7 | |  | | OPTIONS | Describe the communication options for the | 4.3.7 | |
| | | target resource. | | |  | | | target resource. | | |
| | TRACE | Perform a message loop-back test along the path | 4.3.8 | |  | | TRACE | Perform a message loop-back test along the path | 4.3.8 | |
| | | to the target resource. | | |  | | | to the target resource. | | |
| +---------+-------------------------------------------------+-------+ |  | +---------+-------------------------------------------------+-------+ |
| All general-purpose servers MUST support the methods GET and HEAD. |  | All general-purpose servers MUST support the methods GET and HEAD. |
| All other methods are OPTIONAL; when implemented, a server MUST |  | All other methods are OPTIONAL. |
| implement the above methods according to the semantics defined for |  |  |
| them in Section 4.3. |  |  |
| Additional methods, outside the scope of this specification, have |  | Additional methods, outside the scope of this specification, have |
| been standardized for use in HTTP. All such methods ought to be |  | been standardized for use in HTTP. All such methods ought to be |
| registered within the HTTP Method Registry maintained by IANA, as |  | registered within the HTTP Method Registry maintained by IANA, as |
| defined in Section 8.1. |  | defined in Section 8.1. |
| The set of methods allowed by a target resource can be listed in an |  | The set of methods allowed by a target resource can be listed in an |
| Allow header field (Section 7.4.1). However, the set of allowed |  | Allow header field (Section 7.4.1). However, the set of allowed |
| methods can change dynamically. When a request method is received |  | methods can change dynamically. When a request method is received |
| that is unrecognized or not implemented by an origin server, the |  | that is unrecognized or not implemented by an origin server, the |
| skipping to change at page 24, line 16 |  | skipping to change at page 24, line 13 |
| Like the definition of safe, the idempotent property only applies to |  | Like the definition of safe, the idempotent property only applies to |
| what has been requested by the user; a server is free to log each |  | what has been requested by the user; a server is free to log each |
| request separately, retain a revision control history, or implement |  | request separately, retain a revision control history, or implement |
| other non-idempotent side-effects for each idempotent request. |  | other non-idempotent side-effects for each idempotent request. |
| Idempotent methods are distinguished because the request can be |  | Idempotent methods are distinguished because the request can be |
| repeated automatically if a communication failure occurs before the |  | repeated automatically if a communication failure occurs before the |
| client is able to read the server's response. For example, if a |  | client is able to read the server's response. For example, if a |
| client sends a PUT request and the underlying connection is closed |  | client sends a PUT request and the underlying connection is closed |
| before any response is received, then the client can establish a new |  | before any response is received, then the client can establish a new |
| connection and retry the idempotent request because it knows that |  | connection and retry the idempotent request. It knows that repeating |
| repeating the request will have the same effect (even if the original |  | the request will have the same intended effect, even if the original |
| request succeeded, though the status codes might differ in response). |  | request succeeded, though the response might differ. |
| Note, however, that repeated communication failures might indicate |  |  |
| that the server has failed in general, or that something in the |  |  |
| request is triggering a connection drop. |  |  |
| 4.2.3. Cacheable Methods |  | 4.2.3. Cacheable Methods |
| Request methods can be defined as "cacheable" to indicate that |  | Request methods can be defined as "cacheable" to indicate that |
| responses to them are allowed to be stored for future reuse; for |  | responses to them are allowed to be stored for future reuse; for |
| specific requirements see [Part6]. In general, safe methods that do |  | specific requirements see [Part6]. In general, safe methods that do |
| not depend on a current or authoritative response are defined as |  | not depend on a current or authoritative response are defined as |
| cacheable; this specification defines GET, HEAD and POST as |  | cacheable; this specification defines GET, HEAD and POST as |
| cacheable, although the overwhelming majority of cache |  | cacheable, although the overwhelming majority of cache |
| implementations only support GET and HEAD. |  | implementations only support GET and HEAD. |
| skipping to change at page 24, line 43 |  | skipping to change at page 24, line 37 |
| 4.3. Method Definitions |  | 4.3. Method Definitions |
| 4.3.1. GET |  | 4.3.1. GET |
| The GET method requests transfer of a current selected representation |  | The GET method requests transfer of a current selected representation |
| for the target resource. GET is the primary mechanism of information |  | for the target resource. GET is the primary mechanism of information |
| retrieval and the focus of almost all performance optimizations. |  | retrieval and the focus of almost all performance optimizations. |
| Hence, when people speak of retrieving some identifiable information |  | Hence, when people speak of retrieving some identifiable information |
| via HTTP, they are generally referring to making a GET request. |  | via HTTP, they are generally referring to making a GET request. |
| It is tempting to think of resource identifiers as remote filesystem |  | It is tempting to think of resource identifiers as remote file system |
| pathnames, and of representations as being a copy of the contents of |  | pathnames, and of representations as being a copy of the contents of |
| such files. In fact, that is how many resources are implemented (see |  | such files. In fact, that is how many resources are implemented (see |
| Section 9.1 for related security considerations). However, there are |  | Section 9.1 for related security considerations). However, there are |
| no such limitations in practice. The HTTP interface for a resource |  | no such limitations in practice. The HTTP interface for a resource |
| is just as likely to be implemented as a tree of content objects, a |  | is just as likely to be implemented as a tree of content objects, a |
| programmatic view on various database records, or a gateway to other |  | programmatic view on various database records, or a gateway to other |
| information systems. Even when the URI mapping mechanism is tied to |  | information systems. Even when the URI mapping mechanism is tied to |
| a filesystem, an origin server might be configured to execute the |  | a file system, an origin server might be configured to execute the |
| files with the request as input and send the output as the |  | files with the request as input and send the output as the |
| representation, rather than transfer the files directly. Regardless, |  | representation, rather than transfer the files directly. Regardless, |
| only the origin server needs to know how each of its resource |  | only the origin server needs to know how each of its resource |
| identifiers corresponds to an implementation, and how each |  | identifiers corresponds to an implementation, and how each |
| implementation manages to select and send a current representation of |  | implementation manages to select and send a current representation of |
| the target resource in a response to GET. |  | the target resource in a response to GET. |
| A client can alter the semantics of GET to be a "range request", |  | A client can alter the semantics of GET to be a "range request", |
| requesting transfer of only some part(s) of the selected |  | requesting transfer of only some part(s) of the selected |
| representation, by sending a Range header field in the request |  | representation, by sending a Range header field in the request |
| skipping to change at page 30, line 30 |  | skipping to change at page 30, line 24 |
| Responses to the DELETE method are not cacheable. If a DELETE |  | Responses to the DELETE method are not cacheable. If a DELETE |
| request passes through a cache that has one or more stored responses |  | request passes through a cache that has one or more stored responses |
| for the effective request URI, those stored responses will be |  | for the effective request URI, those stored responses will be |
| invalidated (see Section 4.4 of [Part6]). |  | invalidated (see Section 4.4 of [Part6]). |
| 4.3.6. CONNECT |  | 4.3.6. CONNECT |
| The CONNECT method requests that the recipient establish a tunnel to |  | The CONNECT method requests that the recipient establish a tunnel to |
| the destination origin server identified by the request-target and, |  | the destination origin server identified by the request-target and, |
| if successful, thereafter restrict its behavior to blind forwarding |  | if successful, thereafter restrict its behavior to blind forwarding |
| of packets, in both directions, until the tunnel is closed. |  | of packets, in both directions, until the tunnel is closed. Tunnels |
|  |  | are commonly used to create an end-to-end virtual connection, through |
|  |  | one or more proxies, which can then be secured using TLS (Transport |
|  |  | Layer Security, [RFC5246]). |
| CONNECT is intended only for use in requests to a proxy. An origin |  | CONNECT is intended only for use in requests to a proxy. An origin |
| server that receives a CONNECT request for itself MAY respond with a |  | server that receives a CONNECT request for itself MAY respond with a |
| 2xx status code to indicate that a connection is established. |  | 2xx status code to indicate that a connection is established. |
| However, most origin servers do not implement CONNECT. |  | However, most origin servers do not implement CONNECT. |
| A client sending a CONNECT request MUST send the authority form of |  | A client sending a CONNECT request MUST send the authority form of |
| request-target (Section 5.3 of [Part1]); i.e., the request-target |  | request-target (Section 5.3 of [Part1]); i.e., the request-target |
| consists of only the host name and port number of the tunnel |  | consists of only the host name and port number of the tunnel |
| destination, separated by a colon. For example, |  | destination, separated by a colon. For example, |
| skipping to change at page 38, line 33 |  | skipping to change at page 38, line 28 |
| small set of desired types, as in the case of a request for an in- |  | small set of desired types, as in the case of a request for an in- |
| line image. |  | line image. |
| Accept = #( media-range [ accept-params ] ) |  | Accept = #( media-range [ accept-params ] ) |
| media-range = ( "*/*" |  | media-range = ( "*/*" |
| / ( type "/" "*" ) |  | / ( type "/" "*" ) |
| / ( type "/" subtype ) |  | / ( type "/" subtype ) |
| ) *( OWS ";" OWS parameter ) |  | ) *( OWS ";" OWS parameter ) |
| accept-params = weight *( accept-ext ) |  | accept-params = weight *( accept-ext ) |
| accept-ext = OWS ";" OWS token [ "=" word ] |  | accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] |
| The asterisk "*" character is used to group media types into ranges, |  | The asterisk "*" character is used to group media types into ranges, |
| with "*/*" indicating all media types and "type/*" indicating all |  | with "*/*" indicating all media types and "type/*" indicating all |
| subtypes of that type. The media-range can include media type |  | subtypes of that type. The media-range can include media type |
| parameters that are applicable to that range. |  | parameters that are applicable to that range. |
| Each media-range might be followed by zero or more applicable media |  | Each media-range might be followed by zero or more applicable media |
| type parameters (e.g., charset), an optional "q" parameter for |  | type parameters (e.g., charset), an optional "q" parameter for |
| indicating a relative weight (Section 5.3.1), and then zero or more |  | indicating a relative weight (Section 5.3.1), and then zero or more |
| extension parameters. The "q" parameter is necessary if any |  | extension parameters. The "q" parameter is necessary if any |
| skipping to change at page 41, line 6 |  | skipping to change at page 40, line 50 |
| matches every charset that is not mentioned elsewhere in the Accept- |  | matches every charset that is not mentioned elsewhere in the Accept- |
| Charset field. If no "*" is present in an Accept-Charset field, then |  | Charset field. If no "*" is present in an Accept-Charset field, then |
| any charsets not explicitly mentioned in the field are considered |  | any charsets not explicitly mentioned in the field are considered |
| "not acceptable" to the client. |  | "not acceptable" to the client. |
| A request without any Accept-Charset header field implies that the |  | A request without any Accept-Charset header field implies that the |
| user agent will accept any charset in response. Most general-purpose |  | user agent will accept any charset in response. Most general-purpose |
| user agents do not send Accept-Charset, unless specifically |  | user agents do not send Accept-Charset, unless specifically |
| configured to do so, because a detailed list of supported charsets |  | configured to do so, because a detailed list of supported charsets |
| makes it easier for a server to identify an individual by virtue of |  | makes it easier for a server to identify an individual by virtue of |
| the user agent's request characteristics (Section 9.6). |  | the user agent's request characteristics (Section 9.7). |
| If an Accept-Charset header field is present in a request and none of |  | If an Accept-Charset header field is present in a request and none of |
| the available representations for the response has a charset that is |  | the available representations for the response has a charset that is |
| listed as acceptable, the origin server can either honor the header |  | listed as acceptable, the origin server can either honor the header |
| field, by sending a 406 (Not Acceptable) response, or disregard the |  | field, by sending a 406 (Not Acceptable) response, or disregard the |
| header field by treating the resource as if it is not subject to |  | header field by treating the resource as if it is not subject to |
| content negotiation. |  | content negotiation. |
| 5.3.4. Accept-Encoding |  | 5.3.4. Accept-Encoding |
| skipping to change at page 43, line 26 |  | skipping to change at page 43, line 22 |
| found in Section 2.3 of [RFC4647]. |  | found in Section 2.3 of [RFC4647]. |
| For matching, Section 3 of [RFC4647] defines several matching |  | For matching, Section 3 of [RFC4647] defines several matching |
| schemes. Implementations can offer the most appropriate matching |  | schemes. Implementations can offer the most appropriate matching |
| scheme for their requirements. The "Basic Filtering" scheme |  | scheme for their requirements. The "Basic Filtering" scheme |
| ([RFC4647], Section 3.3.1) is identical to the matching scheme that |  | ([RFC4647], Section 3.3.1) is identical to the matching scheme that |
| was previously defined for HTTP in Section 14.4 of [RFC2616]. |  | was previously defined for HTTP in Section 14.4 of [RFC2616]. |
| It might be contrary to the privacy expectations of the user to send |  | It might be contrary to the privacy expectations of the user to send |
| an Accept-Language header field with the complete linguistic |  | an Accept-Language header field with the complete linguistic |
| preferences of the user in every request (Section 9.6). |  | preferences of the user in every request (Section 9.7). |
| Since intelligibility is highly dependent on the individual user, |  | Since intelligibility is highly dependent on the individual user, |
| user agents need to allow user control over the linguistic |  | user agents need to allow user control over the linguistic preference |
| preference. A user agent that does not provide such control to the |  | (either through configuration of the user agent itself, or by |
| user MUST NOT send an Accept-Language header field. |  | defaulting to a user controllable system setting). A user agent that |
|  |  | does not provide such control to the user MUST NOT send an Accept- |
|  |  | Language header field. |
| Note: User agents ought to provide guidance to users when setting |  | Note: User agents ought to provide guidance to users when setting |
| a preference, since users are rarely familiar with the details of |  | a preference, since users are rarely familiar with the details of |
| language matching as described above. For example, users might |  | language matching as described above. For example, users might |
| assume that on selecting "en-gb", they will be served any kind of |  | assume that on selecting "en-gb", they will be served any kind of |
| English document if British English is not available. A user |  | English document if British English is not available. A user |
| agent might suggest, in such a case, to add "en" to the list for |  | agent might suggest, in such a case, to add "en" to the list for |
| better matching behavior. |  | better matching behavior. |
| 5.4. Authentication Credentials |  | 5.4. Authentication Credentials |
| Two header fields are used for carrying authentication credentials, |  | Two header fields are used for carrying authentication credentials, |
| as defined in [Part7]. Note that various custom mechanisms for user |  | as defined in [Part7]. Note that various custom mechanisms for user |
| authentication use the Cookie header field for this purpose, as |  | authentication use the Cookie header field for this purpose, as |
| defined in [RFC6265]. |  | defined in [RFC6265]. |
| +---------------------+------------------------+ |  | +---------------------+------------------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +---------------------+------------------------+ |  | +---------------------+------------------------+ |
| | Authorization | Section 4.1 of [Part7] | |  | | Authorization | Section 4.2 of [Part7] | |
| | Proxy-Authorization | Section 4.3 of [Part7] | |  | | Proxy-Authorization | Section 4.4 of [Part7] | |
| +---------------------+------------------------+ |  | +---------------------+------------------------+ |
| 5.5. Request Context |  | 5.5. Request Context |
| The following request header fields provide additional information |  | The following request header fields provide additional information |
| about the request context, including information about the user, user |  | about the request context, including information about the user, user |
| agent, and resource behind the request. |  | agent, and resource behind the request. |
| +-------------------+---------------+ |  | +-------------------+---------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| skipping to change at page 45, line 43 |  | skipping to change at page 45, line 36 |
| The Referer field has the potential to reveal information about the |  | The Referer field has the potential to reveal information about the |
| request context or browsing history of the user, which is a privacy |  | request context or browsing history of the user, which is a privacy |
| concern if the referring resource's identifier reveals personal |  | concern if the referring resource's identifier reveals personal |
| information (such as an account name) or a resource that is supposed |  | information (such as an account name) or a resource that is supposed |
| to be confidential (such as behind a firewall or internal to a |  | to be confidential (such as behind a firewall or internal to a |
| secured service). Most general-purpose user agents do not send the |  | secured service). Most general-purpose user agents do not send the |
| Referer header field when the referring resource is a local "file" or |  | Referer header field when the referring resource is a local "file" or |
| "data" URI. A user agent MUST NOT send a Referer header field in an |  | "data" URI. A user agent MUST NOT send a Referer header field in an |
| unsecured HTTP request if the referring page was received with a |  | unsecured HTTP request if the referring page was received with a |
| secure protocol. See Section 9.3 for additional security |  | secure protocol. See Section 9.4 for additional security |
| considerations. |  | considerations. |
| Some intermediaries have been known to indiscriminately remove |  | Some intermediaries have been known to indiscriminately remove |
| Referer header fields from outgoing requests. This has the |  | Referer header fields from outgoing requests. This has the |
| unfortunate side-effect of interfering with protection against CSRF |  | unfortunate side-effect of interfering with protection against CSRF |
| attacks, which can be far more harmful to their users. |  | attacks, which can be far more harmful to their users. |
| Intermediaries and user agent extensions that wish to limit |  | Intermediaries and user agent extensions that wish to limit |
| information disclosure in Referer ought to restrict their changes to |  | information disclosure in Referer ought to restrict their changes to |
| specific edits, such as replacing internal domain names with |  | specific edits, such as replacing internal domain names with |
| pseudonyms or truncating the query and/or path components. An |  | pseudonyms or truncating the query and/or path components. An |
| skipping to change at page 51, line 19 |  | skipping to change at page 50, line 21 |
| switching to a real-time, synchronous protocol might be advantageous |  | switching to a real-time, synchronous protocol might be advantageous |
| when delivering resources that use such features. |  | when delivering resources that use such features. |
| 6.3. Successful 2xx |  | 6.3. Successful 2xx |
| The 2xx (Successful) class of status code indicates that the client's |  | The 2xx (Successful) class of status code indicates that the client's |
| request was successfully received, understood, and accepted. |  | request was successfully received, understood, and accepted. |
| 6.3.1. 200 OK |  | 6.3.1. 200 OK |
| The |  | The 200 (OK) status code indicates that the request has succeeded. |
| 200 (OK) status code indicates that the request has succeeded. The |  | The payload sent in a 200 response depends on the request method. |
| payload sent in a 200 response depends on the request method. For |  | For the methods defined by this specification, the intended meaning |
| the methods defined by this specification, the intended meaning of |  | of the payload can be summarized as: |
| the payload can be summarized as: |  |  |
| GET a representation of the target resource; |  | GET a representation of the target resource; |
| HEAD the same representation as GET, but without the representation |  | HEAD the same representation as GET, but without the representation |
| data; |  | data; |
| POST a representation of the status of, or results obtained from, |  | POST a representation of the status of, or results obtained from, |
| the action; |  | the action; |
| PUT, DELETE a representation of the status of the action; |  | PUT, DELETE a representation of the status of the action; |
| skipping to change at page 55, line 42 |  | skipping to change at page 54, line 42 |
| If the server has a preferred choice, the server SHOULD generate a |  | If the server has a preferred choice, the server SHOULD generate a |
| Location header field containing a preferred choice's URI reference. |  | Location header field containing a preferred choice's URI reference. |
| The user agent MAY use the Location field value for automatic |  | The user agent MAY use the Location field value for automatic |
| redirection. |  | redirection. |
| For request methods other than HEAD, the server SHOULD generate a |  | For request methods other than HEAD, the server SHOULD generate a |
| payload in the 300 response containing a list of representation |  | payload in the 300 response containing a list of representation |
| metadata and URI reference(s) from which the user or user agent can |  | metadata and URI reference(s) from which the user or user agent can |
| choose the one most preferred. The user agent MAY make a selection |  | choose the one most preferred. The user agent MAY make a selection |
| from that list automatically, depending upon the list format, but |  | from that list automatically if it understands the provided media |
| this specification does not define a standard for such automatic |  | type. A specific format for automatic selection is not defined by |
| selection. |  | this specification because HTTP tries to remain orthogonal to the |
|  |  | definition of its payloads. In practice, the representation is |
|  |  | provided in some easily parsed format believed to be acceptable to |
|  |  | the user agent, as determined by shared design or content |
|  |  | negotiation, or in some commonly accepted hypertext format. |
| A 300 response is cacheable by default; i.e., unless otherwise |  | A 300 response is cacheable by default; i.e., unless otherwise |
| indicated by the method definition or explicit cache controls (see |  | indicated by the method definition or explicit cache controls (see |
| Section 4.2.2 of [Part6]). |  | Section 4.2.2 of [Part6]). |
| Note: The original proposal for 300 defined the URI header field |  | Note: The original proposal for 300 defined the URI header field |
| as providing a list of alternative representations, such that it |  | as providing a list of alternative representations, such that it |
| would be usable for 200, 300, and 406 responses and be transferred |  | would be usable for 200, 300, and 406 responses and be transferred |
| in responses to the HEAD method. However, lack of deployment and |  | in responses to the HEAD method. However, lack of deployment and |
| disagreement over syntax led to both URI and Alternates (a |  | disagreement over syntax led to both URI and Alternates (a |
| skipping to change at page 56, line 30 |  | skipping to change at page 55, line 31 |
| Clients with link editing capabilities ought to automatically re-link |  | Clients with link editing capabilities ought to automatically re-link |
| references to the effective request URI to one or more of the new |  | references to the effective request URI to one or more of the new |
| references sent by the server, where possible. |  | references sent by the server, where possible. |
| The server SHOULD generate a Location header field in the response |  | The server SHOULD generate a Location header field in the response |
| containing a preferred URI reference for the new permanent URI. The |  | containing a preferred URI reference for the new permanent URI. The |
| user agent MAY use the Location field value for automatic |  | user agent MAY use the Location field value for automatic |
| redirection. The server's response payload usually contains a short |  | redirection. The server's response payload usually contains a short |
| hypertext note with a hyperlink to the new URI(s). |  | hypertext note with a hyperlink to the new URI(s). |
| Note: For historic reasons, a user agent MAY change the request |  | Note: For historical reasons, a user agent MAY change the request |
| method from POST to GET for the subsequent request. If this |  | method from POST to GET for the subsequent request. If this |
| behavior is undesired, the 307 (Temporary Redirect) status code |  | behavior is undesired, the 307 (Temporary Redirect) status code |
| can be used instead. |  | can be used instead. |
| A 301 response is cacheable by default; i.e., unless otherwise |  | A 301 response is cacheable by default; i.e., unless otherwise |
| indicated by the method definition or explicit cache controls (see |  | indicated by the method definition or explicit cache controls (see |
| Section 4.2.2 of [Part6]). |  | Section 4.2.2 of [Part6]). |
| 6.4.3. 302 Found |  | 6.4.3. 302 Found |
| skipping to change at page 57, line 5 |  | skipping to change at page 56, line 5 |
| resides temporarily under a different URI. Since the redirection |  | resides temporarily under a different URI. Since the redirection |
| might be altered on occasion, the client ought to continue to use the |  | might be altered on occasion, the client ought to continue to use the |
| effective request URI for future requests. |  | effective request URI for future requests. |
| The server SHOULD generate a Location header field in the response |  | The server SHOULD generate a Location header field in the response |
| containing a URI reference for the different URI. The user agent MAY |  | containing a URI reference for the different URI. The user agent MAY |
| use the Location field value for automatic redirection. The server's |  | use the Location field value for automatic redirection. The server's |
| response payload usually contains a short hypertext note with a |  | response payload usually contains a short hypertext note with a |
| hyperlink to the different URI(s). |  | hyperlink to the different URI(s). |
| Note: For historic reasons, a user agent MAY change the request |  | Note: For historical reasons, a user agent MAY change the request |
| method from POST to GET for the subsequent request. If this |  | method from POST to GET for the subsequent request. If this |
| behavior is undesired, the 307 (Temporary Redirect) status code |  | behavior is undesired, the 307 (Temporary Redirect) status code |
| can be used instead. |  | can be used instead. |
| 6.4.4. 303 See Other |  | 6.4.4. 303 See Other |
| The 303 (See Other) status code indicates that the server is |  | The 303 (See Other) status code indicates that the server is |
| redirecting the user agent to a different resource, as indicated by a |  | redirecting the user agent to a different resource, as indicated by a |
| URI in the Location header field, that is intended to provide an |  | URI in the Location header field, which is intended to provide an |
| indirect response to the original request. In order to satisfy the |  | indirect response to the original request. A user agent can perform |
| original request, a user agent ought to perform a retrieval request |  | a retrieval request targeting that URI (a GET or HEAD request if |
| using the Location URI (a GET or HEAD request if using HTTP), which |  | using HTTP), which might also be redirected, and present the eventual |
| can itself be redirected further, and present the eventual result as |  | result as an answer to the original request. Note that the new URI |
| an answer to the original request. Note that the new URI in the |  | in the Location header field is not considered equivalent to the |
| Location header field is not considered equivalent to the effective |  | effective request URI. |
| request URI. |  |  |
| This status code is applicable to any HTTP method. It is primarily |  | This status code is applicable to any HTTP method. It is primarily |
| used to allow the output of a POST action to redirect the user agent |  | used to allow the output of a POST action to redirect the user agent |
| to a selected resource, since doing so provides the information |  | to a selected resource, since doing so provides the information |
| corresponding to the POST response in a form that can be separately |  | corresponding to the POST response in a form that can be separately |
| identified, bookmarked, and cached independent of the original |  | identified, bookmarked, and cached independent of the original |
| request. |  | request. |
| A 303 response to a GET request indicates that the origin server does |  | A 303 response to a GET request indicates that the origin server does |
| not have a representation of the target resource that can be |  | not have a representation of the target resource that can be |
| skipping to change at page 66, line 6 |  | skipping to change at page 65, line 6 |
| Universal Time (UTC). The first two formats indicate UTC by the |  | Universal Time (UTC). The first two formats indicate UTC by the |
| three-letter abbreviation for Greenwich Mean Time, "GMT", a |  | three-letter abbreviation for Greenwich Mean Time, "GMT", a |
| predecessor of the UTC name; values in the asctime format are assumed |  | predecessor of the UTC name; values in the asctime format are assumed |
| to be in UTC. A sender that generates HTTP-date values from a local |  | to be in UTC. A sender that generates HTTP-date values from a local |
| clock ought to use NTP ([RFC5905]) or some similar protocol to |  | clock ought to use NTP ([RFC5905]) or some similar protocol to |
| synchronize its clock to UTC. |  | synchronize its clock to UTC. |
| Preferred format: |  | Preferred format: |
| IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT |  | IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT |
| ; fixed length/zone subset of the format defined in |  | ; fixed length/zone/capitalization subset of the format |
| ; Section 3.3 of [RFC5322] |  | ; defined in Section 3.3 of [RFC5322] |
| day-name = %x4D.6F.6E ; "Mon", case-sensitive |  | day-name = %x4D.6F.6E ; "Mon", case-sensitive |
| / %x54.75.65 ; "Tue", case-sensitive |  | / %x54.75.65 ; "Tue", case-sensitive |
| / %x57.65.64 ; "Wed", case-sensitive |  | / %x57.65.64 ; "Wed", case-sensitive |
| / %x54.68.75 ; "Thu", case-sensitive |  | / %x54.68.75 ; "Thu", case-sensitive |
| / %x46.72.69 ; "Fri", case-sensitive |  | / %x46.72.69 ; "Fri", case-sensitive |
| / %x53.61.74 ; "Sat", case-sensitive |  | / %x53.61.74 ; "Sat", case-sensitive |
| / %x53.75.6E ; "Sun", case-sensitive |  | / %x53.75.6E ; "Sun", case-sensitive |
| date1 = day SP month SP year |  | date1 = day SP month SP year |
| skipping to change at page 70, line 38 |  | skipping to change at page 69, line 38 |
| request target, might influence the origin server's process for |  | request target, might influence the origin server's process for |
| selecting and representing this response. The value consists of |  | selecting and representing this response. The value consists of |
| either a single asterisk ("*") or a list of header field names (case- |  | either a single asterisk ("*") or a list of header field names (case- |
| insensitive). |  | insensitive). |
| Vary = "*" / 1#field-name |  | Vary = "*" / 1#field-name |
| A Vary field value of "*" signals that anything about the request |  | A Vary field value of "*" signals that anything about the request |
| might play a role in selecting the response representation, possibly |  | might play a role in selecting the response representation, possibly |
| including elements outside the message syntax (e.g., the client's |  | including elements outside the message syntax (e.g., the client's |
| network address), and thus a recipient will not be able to determine |  | network address). A recipient will not be able to determine whether |
| whether this response is appropriate for a later request without |  | this response is appropriate for a later request without forwarding |
| forwarding the request to the origin server. A proxy MUST NOT |  | the request to the origin server. A proxy MUST NOT generate a Vary |
| generate a Vary field with a "*" value. |  | field with a "*" value. |
| A Vary field value consisting of a comma-separated list of names |  | A Vary field value consisting of a comma-separated list of names |
| indicates that the named request header fields, known as the |  | indicates that the named request header fields, known as the |
| selecting header fields, might have a role in selecting the |  | selecting header fields, might have a role in selecting the |
| representation. The potential selecting header fields are not |  | representation. The potential selecting header fields are not |
| limited to those defined by this specification. |  | limited to those defined by this specification. |
| For example, a response that contains |  | For example, a response that contains |
| Vary: accept-encoding, accept-language |  | Vary: accept-encoding, accept-language |
| skipping to change at page 71, line 34 |  | skipping to change at page 70, line 34 |
| representation might be sent in a subsequent request if |  | representation might be sent in a subsequent request if |
| additional parameters are provided in the listed header fields |  | additional parameters are provided in the listed header fields |
| (proactive negotiation). |  | (proactive negotiation). |
| An origin server SHOULD send a Vary header field when its algorithm |  | An origin server SHOULD send a Vary header field when its algorithm |
| for selecting a representation varies based on aspects of the request |  | for selecting a representation varies based on aspects of the request |
| message other than the method and request target, unless the variance |  | message other than the method and request target, unless the variance |
| cannot be crossed or the origin server has been deliberately |  | cannot be crossed or the origin server has been deliberately |
| configured to prevent cache transparency. For example, there is no |  | configured to prevent cache transparency. For example, there is no |
| need to send the Authorization field name in Vary because reuse |  | need to send the Authorization field name in Vary because reuse |
| across users is constrained by the field definition (Section 4.1 of |  | across users is constrained by the field definition (Section 4.2 of |
| [Part7]). Likewise, an origin server might use Cache-Control |  | [Part7]). Likewise, an origin server might use Cache-Control |
| directives (Section 5.2 of [Part6]) to supplant Vary if it considers |  | directives (Section 5.2 of [Part6]) to supplant Vary if it considers |
| the variance less significant than the performance cost of Vary's |  | the variance less significant than the performance cost of Vary's |
| impact on caching. |  | impact on caching. |
| 7.2. Validator Header Fields |  | 7.2. Validator Header Fields |
| Validator header fields convey metadata about the selected |  | Validator header fields convey metadata about the selected |
| representation (Section 3). In responses to safe requests, validator |  | representation (Section 3). In responses to safe requests, validator |
| fields describe the selected representation chosen by the origin |  | fields describe the selected representation chosen by the origin |
| skipping to change at page 72, line 25 |  | skipping to change at page 71, line 25 |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| 7.3. Authentication Challenges |  | 7.3. Authentication Challenges |
| Authentication challenges indicate what mechanisms are available for |  | Authentication challenges indicate what mechanisms are available for |
| the client to provide authentication credentials in future requests. |  | the client to provide authentication credentials in future requests. |
| +--------------------+------------------------+ |  | +--------------------+------------------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +--------------------+------------------------+ |  | +--------------------+------------------------+ |
| | WWW-Authenticate | Section 4.4 of [Part7] | |  | | WWW-Authenticate | Section 4.1 of [Part7] | |
| | Proxy-Authenticate | Section 4.2 of [Part7] | |  | | Proxy-Authenticate | Section 4.3 of [Part7] | |
| +--------------------+------------------------+ |  | +--------------------+------------------------+ |
| 7.4. Response Context |  | 7.4. Response Context |
| The remaining response header fields provide more information about |  | The remaining response header fields provide more information about |
| the target resource for potential use in later requests. |  | the target resource for potential use in later requests. |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| skipping to change at page 78, line 32 |  | skipping to change at page 77, line 32 |
| New header field values typically have their syntax defined using |  | New header field values typically have their syntax defined using |
| ABNF ([RFC5234]), using the extension defined in Section 7 of [Part1] |  | ABNF ([RFC5234]), using the extension defined in Section 7 of [Part1] |
| as necessary, and are usually constrained to the range of ASCII |  | as necessary, and are usually constrained to the range of ASCII |
| characters. Header fields needing a greater range of characters can |  | characters. Header fields needing a greater range of characters can |
| use an encoding such as the one defined in [RFC5987]. |  | use an encoding such as the one defined in [RFC5987]. |
| Leading and trailing whitespace in raw field values is removed upon |  | Leading and trailing whitespace in raw field values is removed upon |
| field parsing (Section 3.2.4 of [Part1]). Field definitions where |  | field parsing (Section 3.2.4 of [Part1]). Field definitions where |
| leading or trailing whitespace in values is significant will have to |  | leading or trailing whitespace in values is significant will have to |
| use a container syntax such as quoted-string. |  | use a container syntax such as quoted-string (Section 3.2.6 of |
|  |  | [Part1]). |
| Because commas (",") are used as a generic delimiter between field- |  | Because commas (",") are used as a generic delimiter between field- |
| values, they need to be treated with care if they are allowed in the |  | values, they need to be treated with care if they are allowed in the |
| field-value. Typically, components that might contain a comma are |  | field-value. Typically, components that might contain a comma are |
| protected with double-quotes using the quoted-string ABNF production |  | protected with double-quotes using the quoted-string ABNF production. |
| (Section 3.2.6 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 |  | Note that double-quote delimiters almost always are used with the |
| quoted-string production; using a different syntax inside double- |  | quoted-string production; using a different syntax inside double- |
| skipping to change at page 80, line 10 |  | skipping to change at page 79, line 10 |
| o Whether it is appropriate to list the field-name in a Vary |  | o Whether it is appropriate to list the field-name in a Vary |
| response header field (e.g., when the request header field is used |  | response header field (e.g., when the request header field is used |
| by an origin server's content selection algorithm; see |  | by an origin server's content selection algorithm; see |
| Section 7.1.4). |  | Section 7.1.4). |
| o Whether the header field is useful or allowable in trailers (see |  | o Whether the header field is useful or allowable in trailers (see |
| Section 4.1 of [Part1]). |  | Section 4.1 of [Part1]). |
| o Whether the header field ought to be preserved across redirects. |  | o Whether the header field ought to be preserved across redirects. |
|  |  | o Whether it introduces any additional security considerations, such |
|  |  | as disclosure of privacy-related data. |
| 8.3.2. Registrations |  | 8.3.2. Registrations |
| The Message Header Field Registry shall be updated with the following |  | The Message Header Field Registry shall be updated with the following |
| permanent registrations: |  | permanent registrations: |
| +-------------------+----------+----------+-----------------+ |  | +-------------------+----------+----------+-----------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +-------------------+----------+----------+-----------------+ |  | +-------------------+----------+----------+-----------------+ |
| | Accept | http | standard | Section 5.3.2 | |  | | Accept | http | standard | Section 5.3.2 | |
| | Accept-Charset | http | standard | Section 5.3.3 | |  | | Accept-Charset | http | standard | Section 5.3.3 | |
| skipping to change at page 81, line 35 |  | skipping to change at page 80, line 39 |
| +----------+----------------------------------------+---------------+ |  | +----------+----------------------------------------+---------------+ |
| | Name | Description | Reference | |  | | Name | Description | Reference | |
| +----------+----------------------------------------+---------------+ |  | +----------+----------------------------------------+---------------+ |
| | identity | Reserved (synonym for "no encoding" in | Section 5.3.4 | |  | | identity | Reserved (synonym for "no encoding" in | Section 5.3.4 | |
| | | Accept-Encoding) | | |  | | | Accept-Encoding) | | |
| +----------+----------------------------------------+---------------+ |  | +----------+----------------------------------------+---------------+ |
| 9. Security Considerations |  | 9. Security Considerations |
| This section is meant to inform developers, information providers, |  | This section is meant to inform developers, information providers, |
| and users of known security concerns relevant to HTTP/1.1 semantics |  | and users of known security concerns relevant to HTTP semantics and |
| and its use for transferring information over the Internet. |  | its use for transferring information over the Internet. |
|  |  | Considerations related to message syntax, parsing, and routing are |
|  |  | discussed in Section 9 of [Part1]. |
|  |  | The list of considerations below is not exhaustive. Most security |
|  |  | concerns related to HTTP semantics are about securing server-side |
|  |  | applications (code behind the HTTP interface), securing user agent |
|  |  | processing of payloads received via HTTP, or secure use of the |
|  |  | Internet in general, rather than security of the protocol. Various |
|  |  | organizations maintain topical information and links to current |
|  |  | research on Web application security (e.g., [OWASP]). |
| 9.1. Attacks Based On File and Path Names |  | 9.1. Attacks Based On File and Path Names |
| Origin servers frequently make use of their local file system to |  | Origin servers frequently make use of their local file system to |
| manage the mapping from effective request URI to resource |  | manage the mapping from effective request URI to resource |
| representations. Implementers need to be aware that most file |  | representations. Implementers need to be aware that most file |
| systems are not designed to protect against malicious file or path |  | systems are not designed to protect against malicious file or path |
| names, and thus depend on the origin server to avoid mapping to file |  | names, and thus depend on the origin server to avoid mapping to file |
| names, folders, or directories that have special significance to the |  | names, folders, or directories that have special significance to the |
| system. |  | system. |
| skipping to change at page 82, line 14 |  | skipping to change at page 81, line 30 |
| an annoying tendency to prefer user-friendliness over security when |  | an annoying tendency to prefer user-friendliness over security when |
| handling invalid or unexpected characters, recomposition of |  | handling invalid or unexpected characters, recomposition of |
| decomposed characters, and case-normalization of case-insensitive |  | decomposed characters, and case-normalization of case-insensitive |
| names. |  | names. |
| Attacks based on such special names tend to focus on either denial of |  | Attacks based on such special names tend to focus on either denial of |
| service (e.g., telling the server to read from a COM port) or |  | service (e.g., telling the server to read from a COM port) or |
| disclosure of configuration and source files that are not meant to be |  | disclosure of configuration and source files that are not meant to be |
| served. |  | served. |
| 9.2. Personal Information |  | 9.2. Attacks Based On Command, Code, or Query Injection |
|  |  | Origin servers often use parameters within the URI as a means of |
|  |  | identifying system services, selecting database entries, or choosing |
|  |  | a data source. However, data received in a request cannot be |
|  |  | trusted. An attacker could construct any of the request data |
|  |  | elements (method, request-target, header fields, or body) to contain |
|  |  | data that might be misinterpreted as a command, code, or query when |
|  |  | passed through a command invocation, language interpreter, or |
|  |  | database interface. |
|  |  | For example, SQL injection is a common attack wherein additional |
|  |  | query language is inserted within some part of the request-target or |
|  |  | header fields (e.g., Host, Referer, etc.). If the received data is |
|  |  | used directly within a SELECT statement, the query language might be |
|  |  | interpreted as a database command instead of a simple string value. |
|  |  | This type of implementation vulnerability is extremely common, in |
|  |  | spite of being easy to prevent. |
|  |  | In general, resource implementations ought to avoid use of request |
|  |  | data in contexts that are processed or interpreted as instructions. |
|  |  | Parameters ought to be compared to fixed strings and acted upon as a |
|  |  | result of that comparison, rather than passed through an interface |
|  |  | that is not prepared for untrusted data. Received data that isn't |
|  |  | based on fixed parameters ought to be carefully filtered or encoded |
|  |  | to avoid being misinterpreted. |
|  |  | Similar considerations apply to request data when it is stored and |
|  |  | later processed, such as within log files, monitoring tools, or when |
|  |  | included within a data format that allows embedded scripts. |
|  |  | 9.3. Disclosure of Personal Information |
| Clients are often privy to large amounts of personal information, |  | Clients are often privy to large amounts of personal information, |
| including both information provided by the user to interact with |  | including both information provided by the user to interact with |
| resources (e.g., the user's name, location, mail address, passwords, |  | resources (e.g., the user's name, location, mail address, passwords, |
| encryption keys, etc.) and information about the user's browsing |  | encryption keys, etc.) and information about the user's browsing |
| activity over time (e.g., history, bookmarks, etc.). Implementations |  | activity over time (e.g., history, bookmarks, etc.). Implementations |
| need to prevent unintentional leakage of personal information. |  | need to prevent unintentional disclosure of personal information. |
| 9.3. Sensitive Information in URIs |  | 9.4. Disclosure of Sensitive Information in URIs |
| URIs are intended to be shared, not secured, even when they identify |  | URIs are intended to be shared, not secured, even when they identify |
| secure resources. URIs are often shown on displays, added to |  | secure resources. URIs are often shown on displays, added to |
| templates when a page is printed, and stored in a variety of |  | templates when a page is printed, and stored in a variety of |
| unprotected bookmark lists. It is therefore unwise to include |  | unprotected bookmark lists. It is therefore unwise to include |
| information within a URI that is sensitive, personally identifiable, |  | information within a URI that is sensitive, personally identifiable, |
| or a risk to disclose. |  | or a risk to disclose. |
| Authors of services ought to avoid GET-based forms for the submission |  | Authors of services ought to avoid GET-based forms for the submission |
| of sensitive data because that data will be placed in the request- |  | of sensitive data because that data will be placed in the request- |
| skipping to change at page 82, line 46 |  | skipping to change at page 82, line 44 |
| third parties. Such services ought to use POST-based form submission |  | third parties. Such services ought to use POST-based form submission |
| instead. |  | instead. |
| Since the Referer header field tells a target site about the context |  | Since the Referer header field tells a target site about the context |
| that resulted in a request, it has the potential to reveal |  | that resulted in a request, it has the potential to reveal |
| information about the user's immediate browsing history and any |  | information about the user's immediate browsing history and any |
| personal information that might be found in the referring resource's |  | personal information that might be found in the referring resource's |
| URI. Limitations on Referer are described in Section 5.5.2 to |  | URI. Limitations on Referer are described in Section 5.5.2 to |
| address some of its security considerations. |  | address some of its security considerations. |
| 9.4. Product Information |  | 9.5. Disclosure of Fragment after Redirects |
|  |  | Although fragment identifiers used within URI references are not sent |
|  |  | in requests, implementers ought to be aware that they will be visible |
|  |  | to the user agent and any extensions or scripts running as a result |
|  |  | of the response. In particular, when a redirect occurs and the |
|  |  | original request's fragment identifier is inherited by the new |
|  |  | reference in Location (Section 7.1.2), this might have the effect of |
|  |  | disclosing one site's fragment to another site. If the first site |
|  |  | uses personal information in fragments, it ought to ensure that |
|  |  | redirects to other sites include a (possibly empty) fragment |
|  |  | component in order to block that inheritance. |
|  |  | 9.6. Disclosure of Product Information |
| The User-Agent (Section 5.5.3), Via (Section 5.7.1 of [Part1]), and |  | The User-Agent (Section 5.5.3), Via (Section 5.7.1 of [Part1]), and |
| Server (Section 7.4.2) header fields often reveal information about |  | Server (Section 7.4.2) header fields often reveal information about |
| the respective sender's software systems. In theory, this can make |  | the respective sender's software systems. In theory, this can make |
| it easier for an attacker to exploit known security holes; in |  | it easier for an attacker to exploit known security holes; in |
| practice, attackers tend to try all potential holes regardless of the |  | practice, attackers tend to try all potential holes regardless of the |
| apparent software versions being used. |  | apparent software versions being used. |
| Proxies that serve as a portal through a network firewall ought to |  | Proxies that serve as a portal through a network firewall ought to |
| take special precautions regarding the transfer of header information |  | take special precautions regarding the transfer of header information |
| that might identify hosts behind the firewall. The Via header field |  | that might identify hosts behind the firewall. The Via header field |
| allows intermediaries to replace sensitive machine names with |  | allows intermediaries to replace sensitive machine names with |
| pseudonyms. |  | pseudonyms. |
| 9.5. Fragment after Redirects |  | 9.7. Browser Fingerprinting |
| Although fragment identifiers used within URI references are not sent |  |  |
| in requests, implementers ought to be aware that they will be visible |  |  |
| to the user agent and any extensions or scripts running as a result |  |  |
| of the response. In particular, when a redirect occurs and the |  |  |
| original request's fragment identifier is inherited by the new |  |  |
| reference in Location (Section 7.1.2), this might have the effect of |  |  |
| leaking one site's fragment to another site. If the first site uses |  |  |
| personal information in fragments, it ought to ensure that redirects |  |  |
| to other sites include a (possibly empty) fragment component in order |  |  |
| to block that inheritance. |  |  |
| 9.6. Browser Fingerprinting |  |  |
| Browser fingerprinting is a set of techniques for identifying a |  | Browser fingerprinting is a set of techniques for identifying a |
| specific user agent over time through its unique set of |  | specific user agent over time through its unique set of |
| characteristics. These characteristics might include information |  | characteristics. These characteristics might include information |
| related to its TCP behavior, feature capabilities, and scripting |  | related to its TCP behavior, feature capabilities, and scripting |
| environment, though of particular interest here is the set of unique |  | environment, though of particular interest here is the set of unique |
| characteristics that might be communicated via HTTP. Fingerprinting |  | characteristics that might be communicated via HTTP. Fingerprinting |
| is considered a privacy concern because it enables tracking of a user |  | is considered a privacy concern because it enables tracking of a user |
| agent's behavior over time without the corresponding controls that |  | agent's behavior over time without the corresponding controls that |
| the user might have over other forms of data collection (e.g., |  | the user might have over other forms of data collection (e.g., |
| cookies). Many general-purpose user agents (i.e., Web browsers) have |  | cookies). Many general-purpose user agents (i.e., Web browsers) have |
| taken steps to reduce their fingerprints. |  | taken steps to reduce their fingerprints. |
| There are a number of request header fields that might reveal |  | There are a number of request header fields that might reveal |
| information to servers that is sufficiently unique to enable |  | information to servers that is sufficiently unique to enable |
| fingerprinting. The From header field is the most obvious, though it |  | fingerprinting. The From header field is the most obvious, though it |
| is expected that From will only be sent when self-identification is |  | is expected that From will only be sent when self-identification is |
| desired by the user. Likewise, Cookie header fields are deliberately |  | desired by the user. Likewise, Cookie header fields are deliberately |
| designed to enable re-identification, so we can assume that |  | designed to enable re-identification, so fingerprinting concerns only |
| fingerprinting concerns only apply to situations where cookies are |  | apply to situations where cookies are disabled or restricted by the |
| disabled or restricted by the user agent's configuration. |  | user agent's configuration. |
| The User-Agent header field might contain enough information to |  | The User-Agent header field might contain enough information to |
| uniquely identify a specific device, usually when combined with other |  | uniquely identify a specific device, usually when combined with other |
| characteristics, particularly if the user agent sends excessive |  | characteristics, particularly if the user agent sends excessive |
| details about the user's system or extensions. However, the source |  | details about the user's system or extensions. However, the source |
| of unique information that is least expected by users is proactive |  | of unique information that is least expected by users is proactive |
| negotiation (Section 5.3), including the Accept, Accept-Charset, |  | negotiation (Section 5.3), including the Accept, Accept-Charset, |
| Accept-Encoding, and Accept-Language header fields. |  | Accept-Encoding, and Accept-Language header fields. |
| In addition to the fingerprinting concern, detailed use of the |  | In addition to the fingerprinting concern, detailed use of the |
| Accept-Language header field can reveal information the user might |  | Accept-Language header field can reveal information the user might |
| consider to be of a private nature, because the understanding of |  | consider to be of a private nature. For example, understanding a |
| particular languages is often strongly correlated to membership in a |  | given language set might be strongly correlated to membership in a |
| particular ethnic group. An approach that limits such loss of |  | particular ethnic group. An approach that limits such loss of |
| privacy would be for a user agent to omit the sending of Accept- |  | privacy would be for a user agent to omit the sending of Accept- |
| Language except for sites that have been whitelisted, perhaps via |  | Language except for sites that have been whitelisted, perhaps via |
| interaction after detecting a Vary header field that would indicate |  | interaction after detecting a Vary header field that indicates |
| language negotiation might be useful. |  | language negotiation might be useful. |
| In environments where proxies are used to enhance privacy, user |  | In environments where proxies are used to enhance privacy, user |
| agents ought to be conservative in sending proactive negotiation |  | agents ought to be conservative in sending proactive negotiation |
| header fields. General-purpose user agents that provide a high |  | header fields. General-purpose user agents that provide a high |
| degree of header field configurability ought to inform users about |  | degree of header field configurability ought to inform users about |
| the loss of privacy that might result if too much detail is provided. |  | the loss of privacy that might result if too much detail is provided. |
| As an extreme privacy measure, proxies could filter the proactive |  | As an extreme privacy measure, proxies could filter the proactive |
| negotiation header fields in relayed requests. |  | negotiation header fields in relayed requests. |
| 10. Acknowledgments |  | 10. Acknowledgments |
| See Section 10 of [Part1]. |  | See Section 10 of [Part1]. |
| 11. References |  | 11. References |
| 11.1. Normative References |  | 11.1. Normative References |
| [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
| Transfer Protocol (HTTP/1.1): Message Syntax and |  | Transfer Protocol (HTTP/1.1): Message Syntax and |
| Routing", draft-ietf-httpbis-p1-messaging-25 (work in |  | Routing", draft-ietf-httpbis-p1-messaging-26 (work in |
| progress), November 2013. |  | progress), February 2014. |
| [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
| Transfer Protocol (HTTP/1.1): Conditional Requests", |  | Transfer Protocol (HTTP/1.1): Conditional Requests", |
| draft-ietf-httpbis-p4-conditional-25 (work in |  | draft-ietf-httpbis-p4-conditional-26 (work in |
| progress), November 2013. |  | progress), February 2014. |
| [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| "Hypertext Transfer Protocol (HTTP/1.1): Range |  | "Hypertext Transfer Protocol (HTTP/1.1): Range |
| Requests", draft-ietf-httpbis-p5-range-25 (work in |  | Requests", draft-ietf-httpbis-p5-range-26 (work in |
| progress), November 2013. |  | progress), February 2014. |
| [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |  | [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
| Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |  | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
| draft-ietf-httpbis-p6-cache-25 (work in progress), |  | draft-ietf-httpbis-p6-cache-26 (work in progress), |
| November 2013. |  | February 2014. |
| [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |  | [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
| Transfer Protocol (HTTP/1.1): Authentication", |  | Transfer Protocol (HTTP/1.1): Authentication", |
| draft-ietf-httpbis-p7-auth-25 (work in progress), |  | draft-ietf-httpbis-p7-auth-26 (work in progress), |
| November 2013. |  | February 2014. |
| [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |  | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |
| Mail Extensions (MIME) Part One: Format of Internet |  | Mail Extensions (MIME) Part One: Format of Internet |
| Message Bodies", RFC 2045, November 1996. |  | Message Bodies", RFC 2045, November 1996. |
| [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet |  | [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet |
| Mail Extensions (MIME) Part Two: Media Types", |  | Mail Extensions (MIME) Part Two: Media Types", |
| RFC 2046, November 1996. |  | RFC 2046, November 1996. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| skipping to change at page 86, line 9 |  | skipping to change at page 86, line 5 |
| RFC 6838, January 2013. |  | RFC 6838, January 2013. |
| [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, |  | [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, |
| "Deprecating the "X-" Prefix and Similar Constructs in |  | "Deprecating the "X-" Prefix and Similar Constructs in |
| Application Protocols", BCP 178, RFC 6648, June 2012. |  | Application Protocols", BCP 178, RFC 6648, June 2012. |
| [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Procedures for Message Header Fields", BCP 90, |  | Procedures for Message Header Fields", BCP 90, |
| RFC 3864, September 2004. |  | RFC 3864, September 2004. |
|  |  | [OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web |
|  |  | Applications and Web Services", The Open Web |
|  |  | Application Security Project (OWASP) 2.0.1, July 2005, |
|  |  | <https://www.owasp.org/>. |
| [REST] Fielding, R., "Architectural Styles and the Design of |  | [REST] Fielding, R., "Architectural Styles and the Design of |
| Network-based Software Architectures", Doctoral |  | Network-based Software Architectures", |
| Dissertation, University of California, Irvine , |  | Doctoral Dissertation, University of California, |
| September 2000, |  | Irvine, September 2000, |
| <http://roy.gbiv.com/pubs/dissertation/top.htm>. |  | <http://roy.gbiv.com/pubs/dissertation/top.htm>. |
| [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |  | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |
| "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |  | "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |
| May 1996. |  | May 1996. |
| [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet |  | [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet |
| Mail Extensions (MIME) Part Five: Conformance Criteria |  | Mail Extensions (MIME) Part Five: Conformance Criteria |
| and Examples", RFC 2049, November 1996. |  | and Examples", RFC 2049, November 1996. |
| skipping to change at page 87, line 5 |  | skipping to change at page 87, line 6 |
| [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within |  | [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within |
| HTTP/1.1", RFC 2817, May 2000. |  | HTTP/1.1", RFC 2817, May 2000. |
| [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration |  | [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration |
| Procedures", BCP 19, RFC 2978, October 2000. |  | Procedures", BCP 19, RFC 2978, October 2000. |
| [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing |  | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing |
| an IANA Considerations Section in RFCs", BCP 26, |  | an IANA Considerations Section in RFCs", BCP 26, |
| RFC 5226, May 2008. |  | RFC 5226, May 2008. |
|  |  | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer |
|  |  | Security (TLS) Protocol Version 1.2", RFC 5246, |
|  |  | August 2008. |
| [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |  | [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |
| October 2008. |  | October 2008. |
| [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", |  | [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", |
| RFC 5789, March 2010. |  | RFC 5789, March 2010. |
| [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, |  | [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, |
| "Network Time Protocol Version 4: Protocol and |  | "Network Time Protocol Version 4: Protocol and |
| Algorithms Specification", RFC 5905, June 2010. |  | Algorithms Specification", RFC 5905, June 2010. |
| skipping to change at page 92, line 33 |  | skipping to change at page 92, line 38 |
| BWS = <BWS, defined in [Part1], Section 3.2.3> |  | BWS = <BWS, defined in [Part1], Section 3.2.3> |
| OWS = <OWS, defined in [Part1], Section 3.2.3> |  | OWS = <OWS, defined in [Part1], Section 3.2.3> |
| RWS = <RWS, defined in [Part1], Section 3.2.3> |  | RWS = <RWS, defined in [Part1], Section 3.2.3> |
| URI-reference = <URI-reference, defined in [Part1], Section 2.7> |  | URI-reference = <URI-reference, defined in [Part1], Section 2.7> |
| absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> |
| comment = <comment, defined in [Part1], Section 3.2.6> |  | comment = <comment, defined in [Part1], Section 3.2.6> |
| field-name = <comment, defined in [Part1], Section 3.2> |  | field-name = <comment, defined in [Part1], Section 3.2> |
| partial-URI = <partial-URI, defined in [Part1], Section 2.7> |  | partial-URI = <partial-URI, defined in [Part1], Section 2.7> |
| quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> |  | quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> |
| token = <token, defined in [Part1], Section 3.2.6> |  | token = <token, defined in [Part1], Section 3.2.6> |
| word = <word, defined in [Part1], Section 3.2.6> |  |  |
| Appendix D. Collected ABNF |  | Appendix D. Collected ABNF |
| In the collected ABNF below, list rules are expanded as per Section |  | In the collected ABNF below, list rules are expanded as per Section |
| 1.2 of [Part1]. |  | 1.2 of [Part1]. |
| Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ |  | Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ |
| OWS ( media-range [ accept-params ] ) ] ) ] |  | OWS ( media-range [ accept-params ] ) ] ) ] |
| Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS |  | Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS |
| "," [ OWS ( ( charset / "*" ) [ weight ] ) ] ) |  | "," [ OWS ( ( charset / "*" ) [ weight ] ) ] ) |
| skipping to change at page 93, line 42 |  | skipping to change at page 93, line 47 |
| Server = product *( RWS ( product / comment ) ) |  | Server = product *( RWS ( product / comment ) ) |
| URI-reference = <URI-reference, defined in [Part1], Section 2.7> |  | URI-reference = <URI-reference, defined in [Part1], Section 2.7> |
| User-Agent = product *( RWS ( product / comment ) ) |  | User-Agent = product *( RWS ( product / comment ) ) |
| Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] |  | Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] |
| ) ) |  | ) ) |
| absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> |
| accept-ext = OWS ";" OWS token [ "=" word ] |  | accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] |
| accept-params = weight *accept-ext |  | accept-params = weight *accept-ext |
| asctime-date = day-name SP date3 SP time-of-day SP year |  | asctime-date = day-name SP date3 SP time-of-day SP year |
| attribute = token |  |  |
| charset = token |  | charset = token |
| codings = content-coding / "identity" / "*" |  | codings = content-coding / "identity" / "*" |
| comment = <comment, defined in [Part1], Section 3.2.6> |  | comment = <comment, defined in [Part1], Section 3.2.6> |
| content-coding = token |  | content-coding = token |
| date1 = day SP month SP year |  | date1 = day SP month SP year |
| date2 = day "-" month "-" 2DIGIT |  | date2 = day "-" month "-" 2DIGIT |
| date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) |  | date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) |
| day = 2DIGIT |  | day = 2DIGIT |
| day-name = %x4D.6F.6E ; Mon |  | day-name = %x4D.6F.6E ; Mon |
| / %x54.75.65 ; Tue |  | / %x54.75.65 ; Tue |
| / %x57.65.64 ; Wed |  | / %x57.65.64 ; Wed |
| / %x54.68.75 ; Thu |  | / %x54.68.75 ; Thu |
| / %x46.72.69 ; Fri |  | / %x46.72.69 ; Fri |
| / %x53.61.74 ; Sat |  | / %x53.61.74 ; Sat |
| skipping to change at page 95, line 4 |  | skipping to change at page 95, line 6 |
| / %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 |
| / %x53.65.70 ; Sep |  | / %x53.65.70 ; Sep |
| / %x4F.63.74 ; Oct |  | / %x4F.63.74 ; Oct |
| / %x4E.6F.76 ; Nov |  | / %x4E.6F.76 ; Nov |
| / %x44.65.63 ; Dec |  | / %x44.65.63 ; Dec |
| obs-date = rfc850-date / asctime-date |  | obs-date = rfc850-date / asctime-date |
| parameter = attribute "=" value |  |  |
|  |  | parameter = token "=" ( token / quoted-string ) |
| partial-URI = <partial-URI, defined in [Part1], Section 2.7> |  | partial-URI = <partial-URI, defined in [Part1], Section 2.7> |
| product = token [ "/" product-version ] |  | product = token [ "/" product-version ] |
| product-version = token |  | product-version = token |
| quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> |  | quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> |
| qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) |  | qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) |
| rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT |  | rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT |
| second = 2DIGIT |  | second = 2DIGIT |
| subtype = token |  | subtype = token |
| time-of-day = hour ":" minute ":" second |  | time-of-day = hour ":" minute ":" second |
| token = <token, defined in [Part1], Section 3.2.6> |  | token = <token, defined in [Part1], Section 3.2.6> |
| type = token |  | type = token |
| value = word |  |  |
| weight = OWS ";" OWS "q=" qvalue |  | weight = OWS ";" OWS "q=" qvalue |
| word = <word, defined in [Part1], Section 3.2.6> |  |  |
| year = 4DIGIT |  | year = 4DIGIT |
| Appendix E. Change Log (to be removed by RFC Editor before publication) |  | Appendix E. Change Log (to be removed by RFC Editor before publication) |
| E.1. Since RFC 2616 |  | E.1. Since RFC 2616 |
| Changes up to the IETF Last Call draft are summarized in <http:// |  | Changes up to the IETF Last Call draft are summarized in <http:// |
| trac.tools.ietf.org/html/ |  | trac.tools.ietf.org/html/ |
| draft-ietf-httpbis-p2-semantics-24#appendix-E>. |  | draft-ietf-httpbis-p2-semantics-24#appendix-E>. |
| skipping to change at page 96, line 8 |  | skipping to change at page 96, line 8 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/501>: "idempotency: |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/501>: "idempotency: |
| clarify 'effect'" |  | clarify 'effect'" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/503>: "APPSDIR |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/503>: "APPSDIR |
| review of draft-ietf-httpbis-p2-semantics-24" |  | review of draft-ietf-httpbis-p2-semantics-24" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/517>: "move IANA |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/517>: "move IANA |
| registrations to correct draft" |  | registrations to correct draft" |
|  |  | E.3. Since draft-ietf-httpbis-p2-semantics-25 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/520>: "Gen-Art |
|  |  | review of draft-ietf-httpbis-p2-semantics-24 with security |
|  |  | considerations" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/532>: "IESG ballot |
|  |  | on draft-ietf-httpbis-p2-semantics-25" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/538>: "add |
|  |  | 'stateless' to Abstract" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/542>: "improve |
|  |  | introduction of list rule" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/545>: "requirement |
|  |  | on implementing methods according to their semantics" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/546>: |
|  |  | "considerations for new headers: privacy" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/549>: "augment |
|  |  | security considerations with pointers to current research" |
| Index |  | Index |
| 1 |  | 1 |
| 1xx Informational (status code class) 50 |  | 1xx Informational (status code class) 49 |
| 2 |  | 2 |
| 2xx Successful (status code class) 51 |  | 2xx Successful (status code class) 50 |
| 3 |  | 3 |
| 3xx Redirection (status code class) 54 |  | 3xx Redirection (status code class) 53 |
| 4 |  | 4 |
| 4xx Client Error (status code class) 58 |  | 4xx Client Error (status code class) 57 |
| 5 |  | 5 |
| 5xx Server Error (status code class) 62 |  | 5xx Server Error (status code class) 61 |
| 1 |  | 1 |
| 100 Continue (status code) 50 |  | 100 Continue (status code) 49 |
| 100-continue (expect value) 34 |  | 100-continue (expect value) 33 |
| 101 Switching Protocols (status code) 50 |  | 101 Switching Protocols (status code) 49 |
| 2 |  | 2 |
| 200 OK (status code) 51 |  | 200 OK (status code) 50 |
| 201 Created (status code) 52 |  | 201 Created (status code) 51 |
| 202 Accepted (status code) 52 |  | 202 Accepted (status code) 51 |
| 203 Non-Authoritative Information (status code) 52 |  | 203 Non-Authoritative Information (status code) 51 |
| 204 No Content (status code) 53 |  | 204 No Content (status code) 52 |
| 205 Reset Content (status code) 53 |  | 205 Reset Content (status code) 52 |
| 3 |  | 3 |
| 300 Multiple Choices (status code) 55 |  | 300 Multiple Choices (status code) 54 |
| 301 Moved Permanently (status code) 56 |  | 301 Moved Permanently (status code) 55 |
| 302 Found (status code) 56 |  | 302 Found (status code) 55 |
| 303 See Other (status code) 57 |  | 303 See Other (status code) 56 |
| 305 Use Proxy (status code) 57 |  | 305 Use Proxy (status code) 56 |
| 306 (Unused) (status code) 58 |  | 306 (Unused) (status code) 56 |
| 307 Temporary Redirect (status code) 58 |  | 307 Temporary Redirect (status code) 57 |
| 4 |  | 4 |
| 400 Bad Request (status code) 58 |  | 400 Bad Request (status code) 57 |
| 402 Payment Required (status code) 58 |  | 402 Payment Required (status code) 57 |
| 403 Forbidden (status code) 59 |  | 403 Forbidden (status code) 57 |
| 404 Not Found (status code) 59 |  | 404 Not Found (status code) 58 |
| 405 Method Not Allowed (status code) 59 |  | 405 Method Not Allowed (status code) 58 |
| 406 Not Acceptable (status code) 59 |  | 406 Not Acceptable (status code) 58 |
| 408 Request Timeout (status code) 60 |  | 408 Request Timeout (status code) 59 |
| 409 Conflict (status code) 60 |  | 409 Conflict (status code) 59 |
| 410 Gone (status code) 60 |  | 410 Gone (status code) 59 |
| 411 Length Required (status code) 61 |  | 411 Length Required (status code) 60 |
| 413 Payload Too Large (status code) 61 |  | 413 Payload Too Large (status code) 60 |
| 414 URI Too Long (status code) 61 |  | 414 URI Too Long (status code) 60 |
| 415 Unsupported Media Type (status code) 62 |  | 415 Unsupported Media Type (status code) 60 |
| 417 Expectation Failed (status code) 62 |  | 417 Expectation Failed (status code) 61 |
| 426 Upgrade Required (status code) 62 |  | 426 Upgrade Required (status code) 61 |
| 5 |  | 5 |
| 500 Internal Server Error (status code) 63 |  | 500 Internal Server Error (status code) 61 |
| 501 Not Implemented (status code) 63 |  | 501 Not Implemented (status code) 62 |
| 502 Bad Gateway (status code) 63 |  | 502 Bad Gateway (status code) 62 |
| 503 Service Unavailable (status code) 63 |  | 503 Service Unavailable (status code) 62 |
| 504 Gateway Timeout (status code) 63 |  | 504 Gateway Timeout (status code) 62 |
| 505 HTTP Version Not Supported (status code) 63 |  | 505 HTTP Version Not Supported (status code) 62 |
| A |  | A |
| Accept header field 38 |  | Accept header field 38 |
| Accept-Charset header field 40 |  | Accept-Charset header field 40 |
| Accept-Encoding header field 41 |  | Accept-Encoding header field 41 |
| Accept-Language header field 42 |  | Accept-Language header field 42 |
| Allow header field 72 |  | Allow header field 71 |
| C |  | C |
| cacheable 24 |  | cacheable 24 |
| compress (content coding) 11 |  | compress (content coding) 11 |
| conditional request 36 |  | conditional request 36 |
| CONNECT method 30 |  | CONNECT method 30 |
| content coding 11 |  | content coding 11 |
| content negotiation 6 |  | content negotiation 6 |
| Content-Encoding header field 12 |  | Content-Encoding header field 12 |
| Content-Language header field 13 |  | Content-Language header field 13 |
| Content-Location header field 15 |  | Content-Location header field 15 |
| Content-Transfer-Encoding header field 89 |  | Content-Transfer-Encoding header field 89 |
| Content-Type header field 10 |  | Content-Type header field 10 |
| D |  | D |
| Date header field 67 |  | Date header field 66 |
| deflate (content coding) 11 |  | deflate (content coding) 11 |
| DELETE method 29 |  | DELETE method 29 |
| E |  | E |
| Expect header field 34 |  | Expect header field 33 |
| F |  | F |
| From header field 44 |  | From header field 44 |
| G |  | G |
| GET method 24 |  | GET method 24 |
| Grammar |  | Grammar |
| Accept 38 |  | Accept 38 |
| Accept-Charset 40 |  | Accept-Charset 40 |
| Accept-Encoding 41 |  | Accept-Encoding 41 |
| accept-ext 38 |  | accept-ext 38 |
| Accept-Language 42 |  | Accept-Language 42 |
| accept-params 38 |  | accept-params 38 |
| Allow 72 |  | Allow 71 |
| asctime-date 67 |  | asctime-date 66 |
| attribute 8 |  |  |
| charset 9 |  | charset 9 |
| codings 41 |  | codings 41 |
| content-coding 11 |  | content-coding 11 |
| Content-Encoding 12 |  | Content-Encoding 12 |
| Content-Language 13 |  | Content-Language 13 |
| Content-Location 15 |  | Content-Location 15 |
| Content-Type 10 |  | Content-Type 10 |
| Date 67 |  | Date 66 |
| date1 66 |  | date1 65 |
| day 66 |  | day 65 |
| day-name 66 |  | day-name 65 |
| day-name-l 66 |  | day-name-l 65 |
| delay-seconds 70 |  | delay-seconds 69 |
| Expect 34 |  | Expect 34 |
| From 44 |  | From 44 |
| GMT 66 |  | GMT 65 |
| hour 66 |  | hour 65 |
| HTTP-date 64 |  | HTTP-date 63 |
| IMF-fixdate 66 |  | IMF-fixdate 65 |
| language-range 42 |  | language-range 42 |
| language-tag 13 |  | language-tag 13 |
| Location 68 |  | Location 67 |
| Max-Forwards 36 |  | Max-Forwards 36 |
| media-range 38 |  | media-range 38 |
| media-type 8 |  | media-type 8 |
| method 21 |  | method 21 |
| minute 66 |  | minute 65 |
| month 66 |  | month 65 |
| obs-date 66 |  | obs-date 65 |
| parameter 8 |  | parameter 8 |
| product 46 |  | product 46 |
| product-version 46 |  | product-version 46 |
| qvalue 38 |  | qvalue 38 |
| Referer 45 |  | Referer 45 |
| Retry-After 70 |  | Retry-After 69 |
| rfc850-date 67 |  | rfc850-date 66 |
| second 66 |  | second 65 |
| Server 73 |  | Server 72 |
| subtype 8 |  | subtype 8 |
| time-of-day 66 |  | time-of-day 65 |
| type 8 |  | type 8 |
| User-Agent 46 |  | User-Agent 46 |
| value 8 |  | Vary 69 |
| Vary 70 |  |  |
| weight 38 |  | weight 38 |
| year 66 |  | year 65 |
| gzip (content coding) 11 |  | gzip (content coding) 11 |
| H |  | H |
| HEAD method 25 |  | HEAD method 25 |
| I |  | I |
| idempotent 23 |  | idempotent 23 |
| L |  | L |
| Location header field 68 |  | Location header field 67 |
| M |  | M |
| Max-Forwards header field 36 |  | Max-Forwards header field 36 |
| MIME-Version header field 88 |  | MIME-Version header field 88 |
| O |  | O |
| OPTIONS method 31 |  | OPTIONS method 31 |
| P |  | P |
| payload 17 |  | payload 17 |
| POST method 25 |  | POST method 25 |
| PUT method 26 |  | PUT method 26 |
| R |  | R |
| Referer header field 45 |  | Referer header field 44 |
| representation 7 |  | representation 7 |
| Retry-After header field 69 |  | Retry-After header field 68 |
| S |  | S |
| safe 22 |  | safe 22 |
| selected representation 7, 71 |  | selected representation 7, 70 |
| Server header field 73 |  | Server header field 72 |
| Status Codes Classes |  | Status Codes Classes |
| 1xx Informational 50 |  | 1xx Informational 49 |
| 2xx Successful 51 |  | 2xx Successful 50 |
| 3xx Redirection 54 |  | 3xx Redirection 53 |
| 4xx Client Error 58 |  | 4xx Client Error 57 |
| 5xx Server Error 62 |  | 5xx Server Error 61 |
| T |  | T |
| TRACE method 32 |  | TRACE method 32 |
| U |  | U |
| User-Agent header field 46 |  | User-Agent header field 46 |
| V |  | V |
| Vary header field 70 |  | Vary header field 69 |
| X |  | X |
| x-compress (content coding) 11 |  | x-compress (content coding) 11 |
| x-gzip (content coding) 11 |  | x-gzip (content coding) 11 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Adobe Systems Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
End of changes. 103 change blocks.
| 315 lines changed or deleted |  | 387 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/