| draft-ietf-httpbis-p2-semantics-21.txt |  | draft-ietf-httpbis-p2-semantics-22.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 October 4, 2012 |  | Intended status: Standards Track February 23, 2013 |
| Expires: April 7, 2013 |  | Expires: August 27, 2013 |
| Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |  | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
| draft-ietf-httpbis-p2-semantics-21 |  | draft-ietf-httpbis-p2-semantics-22 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypertext information |  | protocol for distributed, collaborative, hypertext information |
| systems. 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. |
| skipping to change at page 1, line 34 |  | skipping to change at page 1, line 34 |
| 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 F.41. |  | The changes in this draft are summarized in Appendix E.2. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| This Internet-Draft will expire on April 7, 2013. |  | This Internet-Draft will expire on August 27, 2013. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2012 IETF Trust and the persons identified as the |  | Copyright (c) 2013 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 2, line 35 |  | skipping to change at page 2, line 35 |
| modifications of such material outside the IETF Standards Process. |  | modifications of such material outside the IETF Standards Process. |
| Without obtaining an adequate license from the person(s) controlling |  | Without obtaining an adequate license from the person(s) controlling |
| the copyright in such materials, this document may not be modified |  | the copyright in such materials, this document may not be modified |
| outside the IETF Standards Process, and derivative works of it may |  | outside the IETF Standards Process, and derivative works of it may |
| not be created outside the IETF Standards Process, except to format |  | not be created outside the IETF Standards Process, except to format |
| it for publication as an RFC or to translate it into languages other |  | it for publication as an RFC or to translate it into languages other |
| than English. |  | than English. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.1. Conformance and Error Handling . . . . . . . . . . . . . 7 |  | 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 6 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |
| 2. Resource . . . . . . . . . . . . . . . . . . . . . . . . . . 8 |  | 2. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 3. Representation . . . . . . . . . . . . . . . . . . . . . . . 8 |  | 3. Representations . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 3.1. Representation Metadata . . . . . . . . . . . . . . . . . 8 |  | 3.1. Representation Metadata . . . . . . . . . . . . . . . . . 8 |
| 3.1.1. Data Type . . . . . . . . . . . . . . . . . . . . . . 9 |  | 3.1.1. Processing the Data . . . . . . . . . . . . . . . . . 8 |
| 3.1.2. Data Encoding . . . . . . . . . . . . . . . . . . . . 12 |  | 3.1.2. Encoding for Compression or Integrity . . . . . . . . 11 |
| 3.1.3. Audience Language . . . . . . . . . . . . . . . . . . 14 |  | 3.1.3. Audience Language . . . . . . . . . . . . . . . . . . 13 |
| 3.1.4. Identification . . . . . . . . . . . . . . . . . . . 15 |  | 3.1.4. Identification . . . . . . . . . . . . . . . . . . . . 14 |
| 3.2. Representation Data . . . . . . . . . . . . . . . . . . . 18 |  | 3.2. Representation Data . . . . . . . . . . . . . . . . . . . 17 |
| 3.3. Payload Semantics . . . . . . . . . . . . . . . . . . . . 18 |  | 3.3. Payload Semantics . . . . . . . . . . . . . . . . . . . . 17 |
| 3.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 19 |  | 3.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 18 |
| 3.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 20 |  | 3.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 18 |
| 3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 21 |  | 3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . . 19 |
| 4. Product Tokens . . . . . . . . . . . . . . . . . . . . . . . 22 |  | 4. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 5. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 22 |  | 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 22 |  | 4.2. Common Method Properties . . . . . . . . . . . . . . . . . 22 |
| 5.2. Common Method Properties . . . . . . . . . . . . . . . . 24 |  | 4.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 22 |
| 5.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 24 |  | 4.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 23 |
| 5.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 25 |  | 4.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 23 |
| 5.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 25 |  | 4.3. Method Definitions . . . . . . . . . . . . . . . . . . . . 23 |
| 5.3. Method Definitions . . . . . . . . . . . . . . . . . . . 25 |  | 4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 5.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 5.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 26 |  | 4.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . . 25 |
| 5.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 4.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 26 |
| 5.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 28 |  | 4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 28 |
| 5.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 30 |  | 4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 29 |
| 5.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 30 |  | 4.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 31 |
| 5.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 4.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 5.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 5. Request Header Fields . . . . . . . . . . . . . . . . . . . . 32 |
| 6. Request Header Fields . . . . . . . . . . . . . . . . . . . . 33 |  | 5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 6.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 6.1.1. Max-Forwards . . . . . . . . . . . . . . . . . . . . 34 |  | 5.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36 |
| 6.1.2. Expect . . . . . . . . . . . . . . . . . . . . . . . 34 |  | 5.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36 |
| 6.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . 37 |  | 5.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 37 |
| 6.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 38 |  | 5.3.1. Quality Values . . . . . . . . . . . . . . . . . . . . 37 |
| 6.3.1. Quality Values . . . . . . . . . . . . . . . . . . . 38 |  | 5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38 |
| 6.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 38 |  | 5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40 |
| 6.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 41 |  | 5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41 |
| 6.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41 |  | 5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42 |
| 6.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42 |  | 5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43 |
| 6.4. Authentication Credentials . . . . . . . . . . . . . . . 44 |  | 5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 43 |
| 6.5. Context . . . . . . . . . . . . . . . . . . . . . . . . . 44 |  | 5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44 |
| 6.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . 44 |  | 5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 44 |
| 6.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 45 |  | 5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 45 |
| 6.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 45 |  | 6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 46 |
| 7. Response Status Codes . . . . . . . . . . . . . . . . . . . . 46 |  | 6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 47 |
| 7.1. Overview of Status Codes . . . . . . . . . . . . . . . . 47 |  | 6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 49 |
| 7.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 49 |  | 6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 49 |
| 7.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 49 |  | 6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50 |
| 7.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 49 |  | 6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 50 |
| 7.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 50 |  | 6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 50 |
| 7.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 50 |  | 6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 51 |
| 7.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 50 |  | 6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 51 |
| 7.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 51 |  | 6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 51 |
| 7.3.4. 203 Non-Authoritative Information . . . . . . . . . . 51 |  | 6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 52 |
| 7.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 51 |  | 6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 52 |
| 7.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 52 |  | 6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 53 |
| 7.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 52 |  | 6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 54 |
| 7.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 54 |  | 6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 55 |
| 7.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 54 |  | 6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 55 |
| 7.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 55 |  | 6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 56 |
| 7.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 55 |  | 6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 56 |
| 7.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 56 |  | 6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 56 |
| 7.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 56 |  | 6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 57 |
| 7.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . 56 |  | 6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 57 |
| 7.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 56 |  | 6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 57 |
| 7.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 56 |  | 6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 57 |
| 7.5.2. 402 Payment Required . . . . . . . . . . . . . . . . 56 |  | 6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 57 |
| 7.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 57 |  | 6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 58 |
| 7.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 57 |  | 6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 58 |
| 7.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . 57 |  | 6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 58 |
| 7.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . 57 |  | 6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 59 |
| 7.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 58 |  | 6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 59 |
| 7.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . 58 |  | 6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 59 |
| 7.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 58 |  | 6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 60 |
| 7.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 59 |  | 6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 60 |
| 7.5.11. 413 Request Representation Too Large . . . . . . . . 59 |  | 6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 60 |
| 7.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . 59 |  | 6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 60 |
| 7.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . 59 |  | 6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 61 |
| 7.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . 60 |  | 6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 61 |
| 7.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . 60 |  | 6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 61 |
| 7.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 60 |  | 6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 61 |
| 7.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 60 |  | 6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 61 |
| 7.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 60 |  | 6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 62 |
| 7.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 61 |  | 6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 62 |
| 7.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 61 |  | 6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 62 |
| 7.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 61 |  | 6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 62 |
| 7.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 61 |  | 7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 62 |
| 8. Response Header Fields . . . . . . . . . . . . . . . . . . . 61 |  | 7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 63 |
| 8.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 62 |  | 7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 63 |
| 8.1.1. Origination Date . . . . . . . . . . . . . . . . . . 62 |  | 7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 66 |
| 8.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 65 |  | 7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 68 |
| 8.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 66 |  | 7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 68 |
| 8.2. Selected Representation Header Fields . . . . . . . . . . 67 |  | 7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 69 |
| 8.2.1. Vary . . . . . . . . . . . . . . . . . . . . . . . . 67 |  | 7.3. Authentication Challenges . . . . . . . . . . . . . . . . 70 |
| 8.3. Authentication Challenges . . . . . . . . . . . . . . . . 68 |  | 7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 70 |
| 8.4. Informative . . . . . . . . . . . . . . . . . . . . . . . 68 |  | 7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 71 |
| 8.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 69 |  | 7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 71 |
| 8.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . 69 |  | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 |
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 |  | 8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 72 |
| 9.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 70 |  | 8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 72 |
| 9.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 70 |  | 8.1.2. Considerations for New Methods . . . . . . . . . . . . 72 |
| 9.1.2. Considerations for New Methods . . . . . . . . . . . 70 |  | 8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 73 |
| 9.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 71 |  | 8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 73 |
| 9.2. Status Code Registry . . . . . . . . . . . . . . . . . . 71 |  | 8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 73 |
| 9.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 71 |  | 8.2.2. Considerations for New Status Codes . . . . . . . . . 73 |
| 9.2.2. Considerations for New Status Codes . . . . . . . . . 71 |  | 8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 74 |
| 9.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 72 |  | 8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 75 |
| 9.3. Header Field Registry . . . . . . . . . . . . . . . . . . 73 |  | 8.3.1. Considerations for New Header Fields . . . . . . . . . 76 |
| 9.3.1. Considerations for New Header Fields . . . . . . . . 74 |  | 8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 78 |
| 9.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 75 |  | 8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 78 |
|  |  | 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 78 |
| 9.4. Content Coding Registry . . . . . . . . . . . . . . . . . 76 |  | 8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 79 |
| 9.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 76 |  | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 79 |
| 9.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 77 |  | 9.1. Attacks Based On File and Path Names . . . . . . . . . . . 79 |
| 10. Security Considerations . . . . . . . . . . . . . . . . . . . 77 |  | 9.2. Personal Information . . . . . . . . . . . . . . . . . . . 80 |
| 10.1. Transfer of Sensitive Information . . . . . . . . . . . . 77 |  | 9.3. Sensitive Information in URIs . . . . . . . . . . . . . . 80 |
| 10.2. Encoding Sensitive Information in URIs . . . . . . . . . 78 |  | 9.4. Product Information . . . . . . . . . . . . . . . . . . . 81 |
| 10.3. Location Header Fields: Spoofing and Information |  | 9.5. Fragment after Redirects . . . . . . . . . . . . . . . . . 81 |
| Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 79 |  | 9.6. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 81 |
| 10.4. Security Considerations for CONNECT . . . . . . . . . . . 79 |  | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 82 |
| 10.5. Privacy Issues Connected to Accept Header Fields . . . . 79 |  | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 82 |
| 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80 |  | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 82 |
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 |  | 11.2. Informative References . . . . . . . . . . . . . . . . . . 84 |
| 12.1. Normative References . . . . . . . . . . . . . . . . . . 80 |  | Appendix A. Differences between HTTP and MIME . . . . . . . . . . 85 |
| 12.2. Informative References . . . . . . . . . . . . . . . . . 81 |  | A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 86 |
| Appendix A. Differences between HTTP and MIME . . . . . . . . . 83 |  | A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 86 |
| A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 84 |  | A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 86 |
| A.2. Conversion to Canonical Form . . . . . . . . . . . . . . 84 |  | A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 87 |
| A.3. Conversion of Date Formats . . . . . . . . . . . . . . . 84 |  | A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 87 |
| A.4. Introduction of Content-Encoding . . . . . . . . . . . . 85 |  | A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 87 |
| A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . 85 |  | Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 87 |
| A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 85 |  | Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 90 |
| Appendix B. Additional Features . . . . . . . . . . . . . . . . 85 |  | Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 90 |
| Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . 86 |  | Appendix E. Change Log (to be removed by RFC Editor before |
| Appendix D. Imported ABNF . . . . . . . . . . . . . . . . . . . 88 |  | publication) . . . . . . . . . . . . . . . . . . . . 93 |
| Appendix E. Collected ABNF . . . . . . . . . . . . . . . . . . . 88 |  | E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 93 |
| Appendix F. Change Log (to be removed by RFC Editor before |  | E.2. Since draft-ietf-httpbis-p2-semantics-21 . . . . . . . . . 94 |
| publication) . . . . . . . . . . . . . . . . . . . . 91 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 |
| F.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . 91 |  |  |
| F.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . 91 |  |  |
| F.3. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . 92 |  |  |
| F.4. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . 93 |  |  |
| F.5. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . 93 |  |  |
| F.6. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . 93 |  |  |
| F.7. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . 94 |  |  |
| F.8. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . 95 |  |  |
| F.9. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . 95 |  |  |
| F.10. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . 95 |  |  |
| F.11. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . 96 |  |  |
| F.12. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . 96 |  |  |
| F.13. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . 96 |  |  |
| F.14. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . 97 |  |  |
| F.15. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . 97 |  |  |
| F.16. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . 97 |  |  |
| F.17. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . 98 |  |  |
| F.18. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . 99 |  |  |
| F.19. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . 99 |  |  |
| F.20. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . 99 |  |  |
| F.21. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . 99 |  |  |
| F.22. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . 100 |  |  |
| F.23. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . 100 |  |  |
| F.24. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . 101 |  |  |
| F.25. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . 101 |  |  |
| F.26. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . 101 |  |  |
| F.27. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . 103 |  |  |
| F.28. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . 103 |  |  |
| F.29. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . 103 |  |  |
| F.30. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . 103 |  |  |
| F.31. Since draft-ietf-httpbis-p3-payload-14 . . . . . . . . . 104 |  |  |
| F.32. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . 104 |  |  |
| F.33. Since draft-ietf-httpbis-p3-payload-15 . . . . . . . . . 104 |  |  |
| F.34. Since draft-ietf-httpbis-p2-semantics-16 . . . . . . . . 104 |  |  |
| F.35. Since draft-ietf-httpbis-p3-payload-16 . . . . . . . . . 104 |  |  |
| F.36. Since draft-ietf-httpbis-p2-semantics-17 . . . . . . . . 105 |  |  |
| F.37. Since draft-ietf-httpbis-p3-payload-17 . . . . . . . . . 105 |  |  |
| F.38. Since draft-ietf-httpbis-p2-semantics-18 . . . . . . . . 105 |  |  |
| F.39. Since draft-ietf-httpbis-p3-payload-18 . . . . . . . . . 106 |  |  |
| F.40. Since draft-ietf-httpbis-p2-semantics-19 and |  |  |
| draft-ietf-httpbis-p3-payload-19 . . . . . . . . . . . . 106 |  |  |
| F.41. Since draft-ietf-httpbis-p2-semantics-20 . . . . . . . . 107 |  |  |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 |  |  |
| 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 |
| received responses to see if the intentions were carried out and |  | received responses to see if the intentions were carried out and |
| determine how to interpret the results. This document defines |  | determine how to interpret the results. This document defines |
| HTTP/1.1 request and response semantics in terms of the architecture |  | HTTP/1.1 request and response semantics in terms of the architecture |
| defined in [Part1]. |  | defined in [Part1]. |
| HTTP provides a uniform interface for interacting with a resource |  | HTTP provides a uniform interface for interacting with a resource |
| (Section 2), regardless of its type, nature, or implementation, and |  | (Section 2), regardless of its type, nature, or implementation, via |
| for transferring content in message payloads in the form of a |  | the manipulation and transfer of representations (Section 3). |
| representation (Section 3). |  |  |
| HTTP semantics include the intentions defined by each request method |  | HTTP semantics include the intentions defined by each request method |
| (Section 5), extensions to those semantics that might be described in |  | (Section 4), extensions to those semantics that might be described in |
| request header fields (Section 6), the meaning of status codes to |  | request header fields (Section 5), the meaning of status codes to |
| indicate a machine-readable response (Section 7), and the meaning of |  | indicate a machine-readable response (Section 6), and the meaning of |
| other control data and resource metadata that might be given in |  | other control data and resource metadata that might be given in |
| response header fields (Section 8). |  | response header fields (Section 7). |
| This document also defines representation metadata that describe how |  | This document also defines representation metadata that describe how |
| a payload is intended to be interpreted by a recipient, the request |  | a payload is intended to be interpreted by a recipient, the request |
| header fields that might influence content selection, and the various |  | header fields that might influence content selection, and the various |
| selection algorithms that are collectively referred to as "content |  | selection algorithms that are collectively referred to as "content |
| negotiation" (Section 3.4). |  | negotiation" (Section 3.4). |
| 1.1. Conformance and Error Handling |  | 1.1. Conformance and Error Handling |
| 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 the list rule extension defined in Section |
| 1.2 of [Part1]. Appendix D describes rules imported from other |  | 1.2 of [Part1]. Appendix C describes rules imported from other |
| documents. Appendix E shows the collected ABNF with the list rule |  | documents. Appendix D shows the collected ABNF with the list rule |
| expanded. |  | expanded. |
| 2. Resource |  | This specification uses the terms "character", "character encoding |
|  |  | scheme", "charset", and "protocol element" as they are defined in |
|  |  | [RFC6365]. |
|  |  | 2. Resources |
| The target of each HTTP request is called a resource. HTTP does not |  | The target of each 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 |
| identified by a Uniform Resource Identifier (URI), as described in |  | identified by a Uniform Resource Identifier (URI), as described in |
| Section 2.7 of [Part1]. |  | Section 2.7 of [Part1]. |
| 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 5) and a few request- |  | semantics in the request method (Section 4) and a few request- |
| modifying header fields (Section 6). Resource owners SHOULD NOT |  | modifying header fields (Section 5). Resource owners SHOULD NOT |
| include request semantics within a URI, such as by specifying an |  | include request semantics within a URI, such as by specifying an |
| action to invoke within the path or query components of the effective |  | action to invoke within the path or query components of the effective |
| request URI, unless those semantics are disabled when they are |  | request URI, unless those semantics are disabled when they are |
| inconsistent with the request method. |  | inconsistent with the request method. |
| 3. Representation |  | 3. Representations |
| If we consider that a resource could be anything, and that the |  | If we consider that a resource could be anything, and that the |
| uniform interface provided by HTTP is similar to a window through |  | uniform interface provided by HTTP is similar to a window through |
| which one can observe and act upon such a thing only through the |  | which one can observe and act upon such a thing only through the |
| communication of messages to some independent actor on the other |  | communication of messages to some independent actor on the other |
| side, then we need an abstraction to represent ("take the place of") |  | side, then we need an abstraction to represent ("take the place of") |
| the current or desired state of that thing in our communications. We |  | the current or desired state of that thing in our communications. We |
| call that abstraction a "representation" [REST]. |  | call that abstraction a representation [REST]. |
| For the purposes of HTTP, a representation is information that |  | For the purposes of HTTP, a "representation" is information that is |
| reflects the current or desired state of a given resource, in a |  | intended to reflect a past, current, or desired state of a given |
| format that can be readily communicated via the protocol, consisting |  | resource, in a format that can be readily communicated via the |
| of a set of representation metadata and a potentially unbounded |  | protocol, and that consists of a set of representation metadata and a |
| stream of representation data. |  | potentially unbounded stream of representation data. |
|  |  | An origin server might be provided with, or capable of generating, |
|  |  | multiple representations that are each intended to reflect the |
|  |  | current state of a target resource. In such cases, some algorithm is |
|  |  | used by the origin server to select one of those representations as |
|  |  | most applicable to a given request, usually based on content |
|  |  | negotiation. We refer to that one representation as the "selected |
|  |  | representation" and use its particular data and metadata for |
|  |  | evaluating conditional requests [Part4] and constructing the payload |
|  |  | for 200 (OK) and 304 (Not Modified) 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. |
| The following header fields are defined to convey representation |  | The following header fields are defined to convey representation |
| metadata: |  | metadata: |
| +-------------------+------------------------+ |  | +-------------------+-----------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +-------------------+------------------------+ |  | +-------------------+-----------------+ |
| | Content-Type | Section 3.1.1.5 | |  | | Content-Type | Section 3.1.1.5 | |
| | Content-Encoding | Section 3.1.2.2 | |  | | Content-Encoding | Section 3.1.2.2 | |
| | Content-Language | Section 3.1.3.2 | |  | | Content-Language | Section 3.1.3.2 | |
| | Content-Location | Section 3.1.4.2 | |  | | Content-Location | Section 3.1.4.2 | |
| | Expires | Section 7.3 of [Part6] | |  | +-------------------+-----------------+ |
| +-------------------+------------------------+ |  |  |
| 3.1.1. Data Type |  | 3.1.1. Processing the Data |
| 3.1.1.1. Media Types |  | 3.1.1.1. Media Type |
| HTTP uses Internet Media Types [RFC2046] in the Content-Type |  | HTTP uses Internet Media Types [RFC2046] in the Content-Type |
| (Section 3.1.1.5) and Accept (Section 6.3.2) header fields in order |  | (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order |
| 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: |
|  |  | how to process that data in accordance with each context in which it |
|  |  | 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. |  | attribute/value pairs. |
| parameter = attribute "=" value |  | parameter = attribute "=" value |
| attribute = token |  | attribute = token |
| skipping to change at page 9, line 46 |  | skipping to change at page 9, line 14 |
| The type, subtype, and parameter attribute names are case- |  | The type, subtype, and parameter attribute names are case- |
| insensitive. Parameter values might or might not be case-sensitive, |  | insensitive. Parameter values might or might not be case-sensitive, |
| depending on the semantics of the parameter name. The presence or |  | depending on the semantics of the parameter name. The presence or |
| absence of a parameter might be significant to the processing of a |  | absence of a parameter might be significant to the processing of a |
| media-type, depending on its definition within the media type |  | 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. |  | and unquoted values are equivalent. For example, the following |
|  |  | examples are all equivalent, but the first is preferred for |
|  |  | consistency: |
| Media-type values are registered with the Internet Assigned Number |  | text/html;charset=utf-8 |
| Authority (IANA). The media type registration process is outlined in |  | text/html;charset=UTF-8 |
| [RFC4288]. Use of non-registered media types is discouraged. |  | Text/HTML;Charset="utf-8" |
|  |  | text/html; charset="utf-8" |
| 3.1.1.2. Character Encodings (charset) |  | Internet media types ought to be registered with IANA according to |
|  |  | the procedures defined in [BCP13]. |
| HTTP uses charset names to indicate the character encoding of a |  | 3.1.1.2. Charset |
| textual representation. |  |  |
| A character encoding is identified by a case-insensitive token. The |  | HTTP uses charset names to indicate or negotiate the character |
| complete set of tokens is defined by the IANA Character Set registry |  | encoding scheme of a textual representation [RFC6365]. A charset is |
| (<http://www.iana.org/assignments/character-sets>). |  | identified by a case-insensitive token. |
| charset = token |  | charset = token |
| Although HTTP allows an arbitrary token to be used as a charset |  | Charset names ought to be registered in IANA Character Set registry |
| value, any token that has a predefined value within the IANA |  | (<http://www.iana.org/assignments/character-sets>) according to the |
| Character Set registry MUST represent the character encoding defined |  | procedures defined in [RFC2978]. |
| by that registry. Applications SHOULD limit their use of character |  |  |
| encodings to those defined within the IANA registry. |  |  |
| HTTP uses charset in two contexts: within an Accept-Charset request |  |  |
| header field (in which the charset value is an unquoted token) and as |  |  |
| the value of a parameter in a Content-Type header field (within a |  |  |
| request or response), in which case the parameter value of the |  |  |
| charset parameter can be quoted. |  |  |
| Implementers need to be aware of IETF character set requirements |  |  |
| [RFC3629] [RFC2277]. |  |  |
| 3.1.1.3. Canonicalization and Text Defaults |  | 3.1.1.3. Canonicalization and Text Defaults |
| Internet media types are registered with a canonical form. A |  | Internet media types are registered with a canonical form in order to |
| representation transferred via HTTP messages MUST be in the |  | be interoperable among systems with varying native encoding formats. |
| appropriate canonical form prior to its transmission except for |  | Representations selected or transferred via HTTP ought to be in |
| "text" types, as defined in the next paragraph. |  | canonical form, for many of the same reasons described by the |
|  |  | Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the |
|  |  | performance characteristics of email deployments (i.e., store and |
|  |  | forward messages to peers) are significantly different from those |
|  |  | common to HTTP and the Web (server-based information services). |
|  |  | Furthermore, MIME's constraints for the sake of compatibility with |
|  |  | older mail transfer protocols do not apply to HTTP (see Appendix A). |
| When in canonical form, media subtypes of the "text" type use CRLF as |  | MIME's canonical form requires that media subtypes of the "text" type |
| the text line break. HTTP relaxes this requirement and allows the |  | use CRLF as the text line break. HTTP allows the transfer of text |
| transport of text media with plain CR or LF alone representing a line |  | media with plain CR or LF alone representing a line break, when such |
| break when it is done consistently for an entire representation. |  | line breaks are consistent for an entire representation. HTTP |
| HTTP applications MUST accept CRLF, bare CR, and bare LF as |  | senders MAY generate, and recipients MUST be able to parse, line |
| indicating a line break in text media received via HTTP. In |  | breaks in text media that consist of CRLF, bare CR, or bare LF. In |
| addition, if the text is in a character encoding that does not use |  | addition, text media in HTTP is not limited to charsets that use |
| octets 13 and 10 for CR and LF respectively, as is the case for some |  | octets 13 and 10 for CR and LF, respectively. This flexibility |
| multi-byte character encodings, HTTP allows the use of whatever octet |  | regarding line breaks applies only to text within a representation |
| sequences are defined by that character encoding to represent the |  | that has been assigned a "text" media type; it does not apply to |
| equivalent of CR and LF for line breaks. This flexibility regarding |  | "multipart" types or HTTP elements outside the payload body (e.g., |
| line breaks applies only to text media in the payload body; a bare CR |  | header fields). |
| or LF MUST NOT be substituted for CRLF within any of the HTTP control |  |  |
| structures (such as header fields and multipart boundaries). |  |  |
| If a representation is encoded with a content-coding, the underlying |  | If a representation is encoded with a content-coding, the underlying |
| data MUST be in a form defined above prior to being encoded. |  | data ought to be in a form defined above prior to being encoded. |
| 3.1.1.4. Multipart Types |  | 3.1.1.4. Multipart Types |
| MIME provides for a number of "multipart" types -- encapsulations of |  | MIME provides for a number of "multipart" types -- encapsulations of |
| one or more representations within a single message body. All |  | one or more representations within a single message body. All |
| multipart types share a common syntax, as defined in Section 5.1.1 of |  | multipart types share a common syntax, as defined in Section 5.1.1 of |
| [RFC2046], and include a boundary parameter as part of the media type |  | [RFC2046], and include a boundary parameter as part of the media type |
| value. The message body is itself a protocol element; a sender MUST |  | value. The message body is itself a protocol element; a sender MUST |
| generate only CRLF to represent line breaks between body-parts. |  | generate only CRLF to represent line breaks between body parts. |
| In general, HTTP treats a multipart message body no differently than |  |  |
| any other media type: strictly as payload. HTTP does not use the |  |  |
| multipart boundary as an indicator of message body length. In all |  |  |
| other respects, an HTTP user agent SHOULD follow the same or similar |  |  |
| behavior as a MIME user agent would upon receipt of a multipart type. |  |  |
| The MIME header fields within each body-part of a multipart message |  |  |
| body do not have any significance to HTTP beyond that defined by |  |  |
| their MIME semantics. |  |  |
| A recipient MUST treat an unrecognized multipart subtype as being |  |  |
| equivalent to "multipart/mixed". |  |  |
| Note: The "multipart/form-data" type has been specifically defined |  | HTTP message framing does not use the multipart boundary as an |
| for carrying form data suitable for processing via the POST |  | indicator of message body length, though it might be used by |
| request method, as described in [RFC2388]. |  | implementations that generate or process the payload. For example, |
|  |  | the "multipart/form-data" type is often used for carrying form data |
|  |  | in a request, as described in [RFC2388], and the "multipart/ |
|  |  | byteranges" type is defined by this specification for use in some 206 |
|  |  | (Partial Content) responses [Part5]. |
| 3.1.1.5. Content-Type |  | 3.1.1.5. Content-Type |
| The "Content-Type" header field indicates the media type of the |  | The "Content-Type" header field indicates the media type of the |
| representation, which defines both the data format and how that data |  | associated representation: either the representation enclosed in the |
| SHOULD be processed by the recipient (within the scope of the request |  | message payload or the selected representation, as determined by the |
| method semantics) after any Content-Encoding is decoded. For |  | message semantics. The indicated media type defines both the data |
| responses to the HEAD method, the media type is that which would have |  | format and how that data is intended to be processed by a recipient, |
| been sent had the request been a GET. |  | within the scope of the received message semantics, after any content |
|  |  | codings indicated by Content-Encoding are decoded. |
| Content-Type = media-type |  | Content-Type = media-type |
| Media types are defined in Section 3.1.1.1. An example of the field |  | Media types are defined in Section 3.1.1.1. An example of the field |
| is |  | is |
| Content-Type: text/html; charset=ISO-8859-4 |  | Content-Type: text/html; charset=ISO-8859-4 |
| A sender SHOULD include a Content-Type header field in a message |  | A sender that generates a message containing a payload body SHOULD |
| containing a payload body, defining the media type of the enclosed |  | generate a Content-Type header field in that message unless the |
| representation, unless the intended media type is unknown to the |  | intended media type of the enclosed representation is unknown to the |
| sender. If a Content-Type header field is not present, recipients |  | sender. If a Content-Type header field is not present, recipients |
| MAY either assume a media type of "application/octet-stream" |  | MAY either assume a media type of "application/octet-stream" |
| ([RFC2046], Section 4.5.1) or examine the representation data to |  | ([RFC2046], Section 4.5.1) or examine the data to determine its type. |
| determine its type. |  |  |
| In practice, resource owners do not always properly configure their |  | In practice, resource owners do not always properly configure their |
| origin server to provide the correct Content-Type for a given |  | origin server to provide the correct Content-Type for a given |
| representation, with the result that some clients will examine a |  | representation, with the result that some clients will examine a |
| payload's content and override the specified type. Clients that do |  | payload's content and override the specified type. Clients that do |
| so risk drawing incorrect conclusions, which might expose additional |  | so risk drawing incorrect conclusions, which might expose additional |
| security risks (e.g., "privilege escalation"). Furthermore, it is |  | security risks (e.g., "privilege escalation"). Furthermore, it is |
| impossible to determine the sender's intent by examining the data |  | impossible to determine the sender's intent by examining the data |
| format: many data formats match multiple media types that differ only |  | format: many data formats match multiple media types that differ only |
| in processing semantics. Implementers are encouraged to provide a |  | in processing semantics. Implementers are encouraged to provide a |
| means of disabling such "content sniffing" when it is used. |  | means of disabling such "content sniffing" when it is used. |
| 3.1.2. Data Encoding |  | 3.1.2. Encoding for Compression or Integrity |
| 3.1.2.1. Content Codings |  | 3.1.2.1. Content Codings |
| Content coding values indicate an encoding transformation that has |  | Content coding values indicate an encoding transformation that has |
| been or can be applied to a representation. Content codings are |  | been or can be applied to a representation. Content codings are |
| primarily used to allow a representation to be compressed or |  | primarily used to allow a representation to be compressed or |
| otherwise usefully transformed without losing the identity of its |  | otherwise usefully transformed without losing the identity of its |
| underlying media type and without loss of information. Frequently, |  | underlying media type and without loss of information. Frequently, |
| the representation is stored in coded form, transmitted directly, and |  | the representation is stored in coded form, transmitted directly, and |
| only decoded by the recipient. |  | only decoded by the recipient. |
| content-coding = token |  | content-coding = token |
| All content-coding values are case-insensitive and SHOULD be |  | All content-coding values are case-insensitive and ought to be |
| registered within the HTTP Content Coding registry, as defined in |  | registered within the HTTP Content Coding registry, as defined in |
| Section 9.4. They are used in the Accept-Encoding (Section 6.3.4) |  | Section 8.4. They are used in the Accept-Encoding (Section 5.3.4) |
| and Content-Encoding (Section 3.1.2.2) header fields. |  | and Content-Encoding (Section 3.1.2.2) header fields. |
| The following content-coding values are defined by this |  | The following content-coding values are defined by this |
| specification: |  | specification: |
| compress (and x-compress): See Section 4.2.1 of [Part1]. |  | compress (and x-compress): See Section 4.2.1 of [Part1]. |
| deflate: See Section 4.2.2 of [Part1]. |  | deflate: See Section 4.2.2 of [Part1]. |
| gzip (and x-gzip): See Section 4.2.3 of [Part1]. |  | gzip (and x-gzip): See Section 4.2.3 of [Part1]. |
| skipping to change at page 13, line 28 |  | skipping to change at page 12, line 34 |
| provided by other header fields not defined by this specification. |  | provided by other header fields not defined by this 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. |
| A transforming proxy MAY modify the content coding if the new coding |  |  |
| is known to be acceptable to the recipient, unless the "no-transform" |  |  |
| cache-control directive is present in the message. |  |  |
| If the media type includes an inherent encoding, such as a data |  | If the media type includes an inherent encoding, such as a data |
| format that is always compressed, then that encoding would not be |  | format that is always compressed, then that encoding would not be |
| restated as a Content-Encoding even if it happens to be the same |  | restated in Content-Encoding even if it happens to be the same |
| algorithm as one of the content codings. Such a content coding would |  | algorithm as one of the content codings. Such a content coding would |
| only be listed if, for some bizarre reason, it is applied a second |  | only be listed if, for some bizarre reason, it is applied a second |
| time to form the representation. Likewise, an origin server might |  | time to form the representation. Likewise, an origin server might |
| choose to publish the same payload data as multiple representations |  | choose to publish the same data as multiple representations that |
| that differ only in whether the coding is defined as part of Content- |  | differ only in whether the coding is defined as part of Content-Type |
| Type or Content-Encoding, since some user agents will behave |  | or Content-Encoding, since some user agents will behave differently |
| differently in their handling of each response (e.g., open a "Save as |  | in their handling of each response (e.g., open a "Save as ..." dialog |
| ..." dialog instead of automatic decompression and rendering of |  | instead of automatic decompression and rendering of content). |
| content). |  |  |
| If the content-coding of a representation in a request message is not |  | An origin server MAY respond with a status code of 415 (Unsupported |
| acceptable to the origin server, the server SHOULD respond with a |  | Media Type) if a representation in the request message has a content |
| status code of 415 (Unsupported Media Type). |  | coding that is not acceptable. |
| 3.1.3. Audience Language |  | 3.1.3. Audience Language |
| 3.1.3.1. Language Tags |  | 3.1.3.1. Language Tags |
| A language tag, as defined in [RFC5646], identifies a natural |  | A language tag, as defined in [RFC5646], identifies a natural |
| language spoken, written, or otherwise conveyed by human beings for |  | language spoken, written, or otherwise conveyed by human beings for |
| communication of information to other human beings. Computer |  | communication of information to other human beings. Computer |
| languages are explicitly excluded. HTTP uses language tags within |  | languages are explicitly excluded. HTTP uses language tags within |
| the Accept-Language and Content-Language fields. |  | the Accept-Language and Content-Language fields. |
| In summary, a language tag is composed of one or more parts: A |  |  |
| primary language subtag followed by a possibly empty series of |  |  |
| subtags: |  |  |
| language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> |  | language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> |
| White space is not allowed within the tag and all tags are case- |  | A language tag is composed of one or more parts: a primary language |
| insensitive. The name space of language subtags is administered by |  | subtag followed by a possibly empty series of subtags. White space |
| the IANA (see |  | is not allowed within the tag and all tags are case-insensitive. |
| <http://www.iana.org/assignments/language-subtag-registry>). |  |  |
| Example tags include: |  | Example tags include: |
| en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN |  | en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN |
| See [RFC5646] for further information. |  | See [RFC5646] for further information. |
| 3.1.3.2. Content-Language |  | 3.1.3.2. Content-Language |
| The "Content-Language" header field describes the natural language(s) |  | The "Content-Language" header field describes the natural language(s) |
| of the intended audience for the representation. Note that this |  | of the intended audience for the representation. Note that this |
| might not be equivalent to all the languages used within the |  | might not be equivalent to all the languages used within the |
| representation. |  | representation. |
| Content-Language = 1#language-tag |  | Content-Language = 1#language-tag |
| Language tags are defined in Section 3.1.3.1. The primary purpose of |  | Language tags are defined in Section 3.1.3.1. The primary purpose of |
| Content-Language is to allow a user to identify and differentiate |  | Content-Language is to allow a user to identify and differentiate |
| representations according to the user's own preferred language. |  | representations according to the users' own preferred language. |
| Thus, if the content is intended only for a Danish-literate audience, |  | Thus, if the content is intended only for a Danish-literate audience, |
| the appropriate field is |  | the appropriate field is |
| Content-Language: da |  | Content-Language: da |
| If no Content-Language is specified, the default is that the content |  | If no Content-Language is specified, the default is that the content |
| is intended for all language audiences. This might mean that the |  | is intended for all language audiences. This might mean that the |
| sender does not consider it to be specific to any natural language, |  | sender does not consider it to be specific to any natural language, |
| or that the sender does not know for which language it is intended. |  | or that the sender does not know for which language it is intended. |
| skipping to change at page 15, line 31 |  | skipping to change at page 14, line 25 |
| 3.1.4. Identification |  | 3.1.4. Identification |
| 3.1.4.1. Identifying a Representation |  | 3.1.4.1. Identifying a Representation |
| When a complete or partial representation is transferred in a message |  | When a complete or partial representation is transferred in a message |
| payload, it is often desirable for the sender to supply, or the |  | payload, it is often desirable for the sender to supply, or the |
| recipient to determine, an identifier for a resource corresponding to |  | recipient to determine, an identifier for a resource corresponding to |
| that representation. |  | that representation. |
| The following rules are used to determine such a URI for the payload |  | For a request message: |
| of a request message: |  |  |
| o If the request has a Content-Location header field, then the |  | o If the request has a Content-Location header field, then the |
| sender asserts that the payload is a representation of the |  | sender asserts that the payload is a representation of the |
| 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 HTTP). The information might still be |  | other means (not defined by HTTP). The information might still be |
| useful for revision history links. |  | useful for revision history links. |
| o Otherwise, the payload is unidentified. |  | o Otherwise, the payload is unidentified. |
| The following rules, to be applied in order until a match is found, |  | For a response message, the following rules are applied in order |
| are used to determine such a URI for the payload of a response |  | until a match is found: |
| message: |  |  |
| 1. If the request is GET or HEAD and the response status code is 200 |  | 1. If the request is GET or HEAD and the response status code is 200 |
| (OK), 204 (No Content), 206 (Partial Content), or 304 (Not |  | (OK), 204 (No Content), 206 (Partial Content), or 304 (Not |
| Modified), the payload's identifier is the effective request URI |  | Modified), the payload is a representation of the resource |
| (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 is GET or HEAD and the response status code is 203 |
| (Non-Authoritative Information), the payload is a potentially |  | (Non-Authoritative Information), the payload is a potentially |
| modified representation of the target resource; as such, the |  | modified or enhanced representation of the target resource as |
| effective request URI might only act as an identifier for the |  | provided by an intermediary. |
| payload's representation when a request is made via the same |  |  |
| chain of intermediaries. |  |  |
| 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's identifier is the effective request |  | request URI, the payload is a representation of the resource |
| 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 |
| field-value. However, such an assertion cannot be trusted unless |  | field-value. However, such an assertion cannot be trusted unless |
| it can be verified by other means (not defined by HTTP). |  | it can be verified by other means (not defined by HTTP). |
| 5. Otherwise, the payload is unidentified. |  | 5. Otherwise, the payload is unidentified. |
| 3.1.4.2. Content-Location |  | 3.1.4.2. Content-Location |
| The "Content-Location" header field references a URI that can be used |  | The "Content-Location" header field references a URI that can be used |
| as a specific identifier for the representation in this message |  | as an identifier for a specific resource corresponding to the |
| payload. In other words, if one were to perform a GET on this URI at |  | representation in this message's payload. In other words, if one |
| the time of this message's generation, then a 200 (OK) response would |  | were to perform a GET request on this URI at the time of this |
| contain the same representation that is enclosed as payload in this |  | message's generation, then a 200 (OK) response would contain the same |
| message. |  | representation that is enclosed as payload in this message. |
| Content-Location = absolute-URI / partial-URI |  | Content-Location = absolute-URI / partial-URI |
| The Content-Location value is not a replacement for the effective |  | The Content-Location value is not a replacement for the effective |
| Request URI (Section 5.5 of [Part1]). It is representation metadata. |  | Request URI (Section 5.5 of [Part1]). It is representation metadata. |
| 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 response |  | URI that is the same as the effective request URI, then the recipient |
| payload SHOULD be considered a current representation of that |  | MAY consider the payload to be a current representation of that |
| resource. For a GET or HEAD request, this is the same as the default |  | resource at the time indicated by the message origination date. For |
| semantics when no Content-Location is provided by the server. For a |  | a GET or HEAD request, this is the same as the default semantics when |
| state-changing request like PUT or POST, it implies that the server's |  | no Content-Location is provided by the server. For a state-changing |
| response contains the new representation of that resource, thereby |  | request like PUT or POST, it implies that the server's response |
|  |  | contains the new representation of that resource, thereby |
| distinguishing it from representations that might only report about |  | distinguishing it from representations that might only report about |
| the action (e.g., "It worked!"). This allows authoring applications |  | the action (e.g., "It worked!"). This allows authoring applications |
| to update their local copies without the need for a subsequent GET |  | to update their local copies without the need for a subsequent GET |
| request. |  | 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 field- |  | effective request URI, then the origin server claims that the URI is |
| value is an identifier for the payload's representation. Such a |  | an identifier for a different resource corresponding to the enclosed |
| claim can only be trusted if both identifiers share the same resource |  | representation. Such a claim can only be trusted if both identifiers |
| owner, which cannot be programmatically determined via HTTP. |  | share the same resource owner, which cannot be programmatically |
|  |  | 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 |
| that the effective request URI identifies a resource that is |  | that the effective request URI refers to a resource that is |
| subject to content negotiation and the Content-Location field- |  | subject to content negotiation and the Content-Location field- |
| value is a more specific identifier for the selected |  | value is a more specific identifier for the selected |
| representation. |  | representation. |
| o For a 201 (Created) response to a state-changing method, a |  | o For a 201 (Created) response to a state-changing method, a |
| Content-Location field-value that is identical to the Location |  | Content-Location field-value that is identical to the Location |
| field-value indicates that this payload is a current |  | field-value indicates that this payload is a current |
| representation of the newly created resource. |  | representation of the newly created resource. |
| o Otherwise, such a Content-Location indicates that this payload is |  | o Otherwise, such a Content-Location indicates that this payload is |
| a representation reporting on the requested action's status and |  | a representation reporting on the requested action's status and |
| that the same report is available (for future access with GET) at |  | that the same report is available (for future access with GET) at |
| the given URI. For example, a purchase transaction made via a |  | the given URI. For example, a purchase transaction made via a |
| POST request might include a receipt document as the payload of |  | POST request might include a receipt document as the payload of |
| the 200 (OK) response; the Content-Location field-value provides |  | the 200 (OK) response; the Content-Location field-value provides |
| an identifier for retrieving a copy of that same receipt in the |  | an identifier for retrieving a copy of that same receipt in the |
| future. |  | future. |
| If Content-Location is included in a request message, then it MAY be |  | A user agent that sends Content-Location in a request message is |
| interpreted by the origin server as an indication of where the user |  | stating that its value refers to where the user agent originally |
| agent originally obtained the content of the enclosed representation |  | obtained the content of the enclosed representation (prior to any |
| (prior to any subsequent modification of the content by that user |  | modifications made by that user agent). In other words, the user |
| agent). In other words, the user agent is providing the same |  | agent is providing a back link to the source of the original |
| representation metadata that it received with the original |  | representation. |
| representation. However, such interpretation MUST NOT be used to |  |  |
| alter the semantics of the method requested by the client. For |  |  |
| example, if a client makes a PUT request on a negotiated resource and |  |  |
| the origin server accepts that PUT (without redirection), then the |  |  |
| new set of values for that resource is expected to be consistent with |  |  |
| the one representation supplied in that PUT; the Content-Location |  |  |
| cannot be used as a form of reverse content selection that identifies |  |  |
| only one of the negotiated representations to be updated. If the |  |  |
| user agent had wanted the latter semantics, it would have applied the |  |  |
| PUT directly to the Content-Location URI. |  |  |
| A Content-Location field received in a request message is transitory |  | An origin server that receives a Content-Location field in a request |
| information that SHOULD NOT be saved with other representation |  | message MUST treat the information as transitory request context |
| metadata for use in later responses. The Content-Location's value |  | rather than as metadata to be saved verbatim as part of the |
| might be saved for use in other contexts, such as within source links |  | representation. An origin server MAY use that context to guide in |
| or other metadata. |  | processing the request or to save it for other uses, such as within |
|  |  | source links or versioning metadata. However, an origin server MUST |
|  |  | NOT use such context information to alter the request semantics. |
| A cache cannot assume that a representation with a Content-Location |  | For example, if a client makes a PUT request on a negotiated resource |
| different from the URI used to retrieve it can be used to respond to |  | and the origin server accepts that PUT (without redirection), then |
| later requests on that Content-Location URI. |  | the new state of that resource is expected to be consistent with the |
|  |  | one representation supplied in that PUT; the Content-Location cannot |
|  |  | be used as a form of reverse content selection identifier to update |
|  |  | only one of the negotiated representations. If the user agent had |
|  |  | wanted the latter semantics, it would have applied the PUT directly |
|  |  | to the Content-Location URI. |
| 3.2. Representation Data |  | 3.2. Representation Data |
| The representation data associated with an HTTP message is either |  | The representation data associated with an HTTP message is either |
| provided as the payload body of the message or referred to by the |  | provided as the payload body of the message or referred to by the |
| message semantics and the effective request URI. The representation |  | message semantics and the effective request URI. The representation |
| data is in a format and encoding defined by the representation |  | data is in a format and encoding defined by the representation |
| metadata header fields. |  | metadata header fields. |
| The data type of the representation data is determined via the header |  | The data type of the representation data is determined via the header |
| fields Content-Type and Content-Encoding. These define a two-layer, |  | fields Content-Type and Content-Encoding. These define a two-layer, |
| ordered encoding model: |  | ordered encoding model: |
| representation-data := Content-Encoding( Content-Type( bits ) ) |  | representation-data := Content-Encoding( Content-Type( bits ) ) |
| 3.3. Payload Semantics |  | 3.3. Payload Semantics |
| Some HTTP messages transfer a complete or partial representation as |  | Some HTTP messages transfer a complete or partial representation as |
| the message "payload". In some cases, a payload might only contain |  | 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. In a response, the payload's purpose is defined by both |  | semantics. For example, a representation in the payload of a PUT |
| the request method and the response status code. |  | request (Section 4.3.4) represents the desired state of the target |
|  |  | resource if the request is successfully applied, whereas a |
| For example, a representation in the payload of a PUT request |  | representation in the payload of a POST request (Section 4.3.3) |
| (Section 5.3.4) represents the desired state of the target resource |  | represents an anonymous resource for providing data to be processed, |
| if the request is successfully applied, whereas a representation in |  | such as the information that a user entered within an HTML form. |
| the payload of a POST request (Section 5.3.3) represents an anonymous |  |  |
| resource for providing data to be processed, such as the information |  |  |
| that a user entered within an HTML form. |  |  |
| Likewise, the payload of a 200 (OK) response to GET (Section 5.3.1) |  | In a response, the payload's purpose is defined by both the request |
| contains a representation of the target resource, as observed at the |  | method and the response status code. For example, the payload of a |
| time of the message origination date (Section 8.1.1.2), whereas the |  | 200 (OK) response to GET (Section 4.3.1) represents the current state |
| same status code in a response to POST might contain either a |  | of the target resource, as observed at the time of the message |
| representation of the processing result or a current representation |  | origination date (Section 7.1.1.2), whereas the payload of the same |
| of the target resource after applying the processing. Response |  | status code in a response to POST might represent either the |
| messages with an error status code usually contain a representation |  | processing result or the new state of the target resource after |
| that describes the error and what next steps are suggested for |  | applying the processing. Response messages with an error status code |
| resolving it. |  | usually contain a payload that represents the error condition, such |
|  |  | that it describes the error state and what next steps are suggested |
|  |  | for resolving it. |
| 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 5.2 of [Part5] | |  | | Content-Range | Section 4.2 of [Part5] | |
| | Transfer-Encoding | Section 3.3.1 of [Part1] | |  | | Transfer-Encoding | Section 3.3.1 of [Part1] | |
| +-------------------+--------------------------+ |  | +-------------------+--------------------------+ |
| 3.4. Content Negotiation |  | 3.4. Content Negotiation |
| HTTP responses include a representation which contains information |  | When responses convey payload information, whether indicating a |
| for interpretation, whether by a human user or for further |  | success or an error, the origin server often has different ways of |
| processing. Often, the server has different ways of representing the |  | representing that information; for example, in different formats, |
| same information; for example, in different formats, languages, or |  | languages, or encodings. Likewise, different users or user agents |
| using different character encodings. |  | might have differing capabilities, characteristics, or preferences |
|  |  | that could influence which representation, among those available, |
| HTTP clients and their users might have different or variable |  | would be best to deliver. For this reason, HTTP provides mechanisms |
| capabilities, characteristics or preferences which would influence |  | for content negotiation. |
| which representation, among those available from the server, would be |  |  |
| best for the server to deliver. For this reason, HTTP provides |  |  |
| mechanisms for "content negotiation" -- a process of allowing |  |  |
| selection of a representation of a given resource, when more than one |  |  |
| is available. |  |  |
| This specification defines two patterns of content negotiation; |  |  |
| "proactive", where the server selects the representation based upon |  |  |
| the client's stated preferences, and "reactive" negotiation, where |  |  |
| the server provides a list of representations for the client to |  |  |
| choose from, based upon their metadata. In addition, there are other |  |  |
| patterns: some applications use an "active content" pattern, where |  |  |
| the server returns active content which runs on the client and, based |  |  |
| on client available parameters, selects additional resources to |  |  |
| invoke. "Transparent Content Negotiation" ([RFC2295]) has also been |  |  |
| proposed. |  |  |
| These patterns are all widely used, and have trade-offs in |  | This specification defines two patterns of content negotiation that |
| applicability and practicality. In particular, when the number of |  | can be made visible within the protocol: "proactive", where the |
| preferences or capabilities to be expressed by a client are large |  | server selects the representation based upon the user agent's stated |
| (such as when many different formats are supported by a user-agent), |  | preferences, and "reactive" negotiation, where the server provides a |
| proactive negotiation becomes unwieldy, and might not be appropriate. |  | list of representations for the user agent to choose from. Other |
| Conversely, when the number of representations to choose from is very |  | patterns of content negotiation include "conditional content", where |
| large, reactive negotiation might not be appropriate. |  | the representation consists of multiple parts that are selectively |
|  |  | rendered based on user agent parameters, "active content", where the |
|  |  | representation contains a script that makes additional (more |
|  |  | specific) requests based on the user agent characteristics, and |
|  |  | "Transparent Content Negotiation" ([RFC2295]), where content |
|  |  | selection is performed by an intermediary. These patterns are not |
|  |  | mutually exclusive, and each has trade-offs in applicability and |
|  |  | practicality. |
| Note that, in all cases, the supplier of representations has the |  | Note that, in all cases, the supplier of representations to the |
| responsibility for determining which representations might be |  | origin server determines which representations might be considered to |
| considered to be the "same information". |  | be the "same information". |
| 3.4.1. Proactive Negotiation |  | 3.4.1. Proactive Negotiation |
| If the selection of the best representation for a response is made by |  | When content negotiation preferences are sent by the user agent in a |
| an algorithm located at the server, it is called proactive |  | request in order to encourage an algorithm located at the server to |
| negotiation. Selection is based on the available representations of |  | select the preferred representation, it is called proactive |
| the response (the dimensions over which it can vary; e.g., language, |  | negotiation (a.k.a., server-driven negotiation). Selection is based |
| content-coding, etc.) and the contents of particular header fields in |  | on the available representations for a response (the dimensions over |
| the request message or on other information pertaining to the request |  | which it might vary, such as language, content-coding, etc.) compared |
| (such as the network address of the client). |  | to various information supplied in the request, including both the |
|  |  | explicit negotiation fields of Section 5.3 and implicit |
|  |  | characteristics, such as the client's network address or parts of the |
|  |  | User-Agent field. |
| Proactive negotiation is advantageous when the algorithm for |  | Proactive negotiation is advantageous when the algorithm for |
| selecting from among the available representations is difficult to |  | selecting from among the available representations is difficult to |
| describe to the user agent, or when the server desires to send its |  | describe to a user agent, or when the server desires to send its |
| "best guess" to the client along with the first response (hoping to |  | "best guess" to the user agent along with the first response (hoping |
| avoid the round-trip delay of a subsequent request if the "best |  | to avoid the round-trip delay of a subsequent request if the "best |
| guess" is good enough for the user). In order to improve the |  | guess" is good enough for the user). In order to improve the |
| server's guess, the user agent MAY include request header fields |  | server's guess, a user agent MAY send request header fields that |
| (Accept, Accept-Language, Accept-Encoding, etc.) which describe its |  | describe its preferences. |
| preferences for such a response. |  |  |
| Proactive negotiation has disadvantages: |  |  |
| 1. It is impossible for the server to accurately determine what |  |  |
| might be "best" for any given user, since that would require |  |  |
| complete knowledge of both the capabilities of the user agent and |  |  |
| the intended use for the response (e.g., does the user want to |  |  |
| view it on screen or print it on paper?). |  |  |
| 2. Having the user agent describe its capabilities in every request |  | Proactive negotiation has serious disadvantages: |
| can be both very inefficient (given that only a small percentage |  |  |
| of responses have multiple representations) and a potential |  |  |
| violation of the user's privacy. |  |  |
| 3. It complicates the implementation of an origin server and the |  | o It is impossible for the server to accurately determine what might |
| algorithms for generating responses to a request. |  | be "best" for any given user, since that would require complete |
|  |  | knowledge of both the capabilities of the user agent and the |
|  |  | intended use for the response (e.g., does the user want to view it |
|  |  | on screen or print it on paper?); |
| 4. It might limit a public cache's ability to use the same response |  | o Having the user agent describe its capabilities in every request |
| for multiple user's requests. |  | can be both very inefficient (given that only a small percentage |
|  |  | of responses have multiple representations) and a potential risk |
|  |  | to the user's privacy; |
| Proactive negotiation allows the user agent to specify its |  | o It complicates the implementation of an origin server and the |
| preferences, but it cannot expect responses to always honor them. |  | algorithms for generating responses to a request; and, |
| For example, the origin server might not implement proactive |  |  |
| negotiation, or it might decide that sending a response that doesn't |  |  |
| conform to them is better than sending a 406 (Not Acceptable) |  |  |
| response. |  |  |
| HTTP/1.1 includes the following header fields for enabling proactive |  | o It limits the reusability of responses for shared caching. |
| negotiation through description of user agent capabilities and user |  |  |
| preferences: Accept (Section 6.3.2), Accept-Charset (Section 6.3.3), |  |  |
| Accept-Encoding (Section 6.3.4), Accept-Language (Section 6.3.5), and |  |  |
| User-Agent (Section 6.5.3). However, an origin server is not limited |  |  |
| to these dimensions and MAY vary the response based on any aspect of |  |  |
| the request, including aspects of the connection (e.g., IP address) |  |  |
| or information within extension header fields not defined by this |  |  |
| specification. |  |  |
| Note: In practice, User-Agent based negotiation is fragile, |  | A user agent cannot rely on proactive negotiation preferences being |
| because new clients might not be recognized. |  | consistently honored, since the origin server might not implement |
|  |  | proactive negotiation for the requested resource or might decide that |
|  |  | sending a response that doesn't conform to the user agent's |
|  |  | preferences is better than sending a 406 (Not Acceptable) response. |
| The Vary header field (Section 8.2.1) can be used to express the |  | An origin server MAY generate a Vary header field (Section 7.1.4) in |
| parameters the server uses to select a representation that is subject |  | responses that are subject to proactive negotiation to indicate what |
| to proactive negotiation. |  | parameters of request information might be used in its selection |
|  |  | 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, selection of the best representation for a |  | With reactive negotiation (a.k.a., agent-driven negotiation), |
| response is performed by the user agent after receiving an initial |  | selection of the best representation for a response is performed by |
| response from the origin server. Selection is based on a list of the |  | the user agent after receiving an initial response from the origin |
| available representations of the response included within the header |  | server with a list of alternative resources. If the user agent is |
| fields or body of the initial response, with each representation |  | not satisfied by the initial response, it can perform a GET request |
| identified by its own URI. Selection from among the representations |  | on one or more of the alternative resources, selected based on |
| can be performed automatically (if the user agent is capable of doing |  | metadata included in the list, to obtain a different form of |
| so) or manually by the user selecting from a generated (possibly |  | representation. Selection of alternatives might be performed |
| hypertext) menu. |  | automatically by the user agent or manually by the user selecting |
|  |  | from a generated (possibly hypertext) menu. |
|  |  | A server can send a 300 (Multiple Choices) response to indicate that |
|  |  | reactive negotiation by the user agent is desired, or a 406 (Not |
|  |  | Acceptable) status code to indicate that proactive negotiation has |
|  |  | failed. In both cases, the response ought to include information |
|  |  | about the available representations so that the user or user agent |
|  |  | can react by making a selection. |
| Reactive negotiation is advantageous when the response would vary |  | Reactive negotiation is advantageous when the response would vary |
| over commonly-used dimensions (such as type, language, or encoding), |  | over commonly-used dimensions (such as type, language, or encoding), |
| when the origin server is unable to determine a user agent's |  | when the origin server is unable to determine a user agent's |
| capabilities from examining the request, and generally when public |  | capabilities from examining the request, and generally when public |
| caches are used to distribute server load and reduce network usage. |  | caches are used to distribute server load and reduce network usage. |
| Reactive negotiation suffers from the disadvantage of needing a |  | Reactive negotiation suffers from the disadvantages of transmitting a |
| second request to obtain the best alternate representation. This |  | list of alternatives to the user agent, which degrades user-perceived |
| second request is only efficient when caching is used. In addition, |  | latency if transmitted in the header section, and needing a second |
| this specification does not define any mechanism for supporting |  | request to obtain an alternate representation. Furthermore, this |
| automatic selection, though it also does not prevent any such |  | specification does not define a mechanism for supporting automatic |
| mechanism from being developed as an extension and used within |  | selection, though it does not prevent such a mechanism from being |
| HTTP/1.1. |  | developed as an extension. |
| This specification defines the 300 (Multiple Choices) and 406 (Not |  |  |
| Acceptable) status codes for enabling reactive negotiation when the |  |  |
| server is unwilling or unable to provide a varying response using |  |  |
| proactive negotiation. |  |  |
| 4. Product Tokens |  |  |
| Product tokens are used to allow communicating applications to |  |  |
| identify themselves by software name and version. Most fields using |  |  |
| product tokens also allow sub-products which form a significant part |  |  |
| of the application to be listed, separated by whitespace. By |  |  |
| convention, the products are listed in order of their significance |  |  |
| for identifying the application. |  |  |
| product = token ["/" product-version] |  |  |
| product-version = token |  |  |
| Examples: |  |  |
| User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |  |  |
| Server: Apache/0.8.4 |  |  |
| Product tokens SHOULD be short and to the point. They MUST NOT be |  |  |
| used for advertising or other non-essential information. Although |  |  |
| any token octet MAY appear in a product-version, this token SHOULD |  |  |
| only be used for a version identifier (i.e., successive versions of |  |  |
| the same product SHOULD only differ in the product-version portion of |  |  |
| the product value). |  |  |
| 5. Request Methods |  | 4. Request Methods |
| 5.1. Overview |  | 4.1. Overview |
| The request method token is the primary source of request semantics; |  | The request method token is the primary source of request semantics; |
| it indicates the purpose for which the client has made this request |  | it indicates the purpose for which the client has made this request |
| and what is expected by the client as a successful result. The |  | and what is expected by the client as a successful result. The |
| request semantics MAY be further specialized by the semantics of some |  | request semantics might be further specialized by the semantics of |
| header fields when present in a request (Section 6) if those |  | some header fields when present in a request (Section 5) if those |
| additional semantics do not conflict with the method. |  | additional semantics do not conflict with the method. |
| method = token |  | method = token |
| HTTP was originally designed to be usable as an interface to |  | HTTP was originally designed to be usable as an interface to |
| distributed object systems. The request method was envisioned as |  | distributed object systems. The request method was envisioned as |
| applying semantics to a target resource in much the same way as |  | applying semantics to a target resource in much the same way as |
| invoking a defined method on an identified object would apply |  | invoking a defined method on an identified object would apply |
| semantics. The method token is case-sensitive because it might be |  | semantics. The method token is case-sensitive because it might be |
| used as a gateway to object-based systems with case-sensitive method |  | used as a gateway to object-based systems with case-sensitive method |
| names. |  | names. |
| Unlike distributed objects, the standardized request methods in HTTP |  | Unlike distributed objects, the standardized request methods in HTTP |
| are not resource-specific, since uniform interfaces provide for |  | are not resource-specific, since uniform interfaces provide for |
| better visibility and reuse in network-based systems [REST]. Once |  | better visibility and reuse in network-based systems [REST]. Once |
| defined, a standardized method MUST have the same semantics when |  | defined, a standardized method ought to have the same semantics when |
| applied to any resource, though each resource determines for itself |  | applied to any resource, though each resource determines for itself |
| whether those semantics are implemented or allowed. |  | whether those semantics are implemented or allowed. |
| This specification defines a number of standardized methods that are |  | This specification defines a number of standardized methods that are |
| commonly used in HTTP, as outlined by the following table. By |  | commonly used in HTTP, as outlined by the following table. By |
| convention, standardized methods are defined in all-uppercase ASCII |  | convention, standardized methods are defined in all-uppercase ASCII |
| letters. |  | letters. |
| +---------+-------------------------------------------------+-------+ |  | +---------+-------------------------------------------------+-------+ |
| | Method | Description | Sec. | |  | | Method | Description | Sec. | |
| +---------+-------------------------------------------------+-------+ |  | +---------+-------------------------------------------------+-------+ |
| | GET | Transfer a current representation of the target | 5.3.1 | |  | | GET | Transfer a current representation of the target | 4.3.1 | |
| | | resource. | | |  | | | resource. | | |
| | HEAD | Same as GET, but do not include a message body | 5.3.2 | |  | | HEAD | Same as GET, but only transfer the status line | 4.3.2 | |
| | | in the response. | | |  | | | and header block. | | |
| | POST | Perform resource-specific processing on the | 5.3.3 | |  | | POST | Perform resource-specific processing on the | 4.3.3 | |
| | | request payload. | | |  | | | request payload. | | |
| | PUT | Replace all current representations of the | 5.3.4 | |  | | PUT | Replace all current representations of the | 4.3.4 | |
| | | target resource with the request payload. | | |  | | | target resource with the request payload. | | |
| | DELETE | Remove all current representations of the | 5.3.5 | |  | | DELETE | Remove all current representations of the | 4.3.5 | |
| | | target resource. | | |  | | | target resource. | | |
| | CONNECT | Establish a tunnel to the server identified by | 5.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 | 5.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 | 5.3.8 | |  | | TRACE | Perform a message loop-back test along the path | 4.3.8 | |
| | | to the target resource. | | |  | | | to the target resource. | | |
| +---------+-------------------------------------------------+-------+ |  | +---------+-------------------------------------------------+-------+ |
| The methods GET and HEAD MUST be supported by all general-purpose |  | All general-purpose servers MUST support the methods GET and HEAD. |
| servers. All other methods are OPTIONAL. When implemented, a server |  | All other methods are OPTIONAL; when implemented, a server MUST |
| MUST implement the above methods according to the semantics defined |  | implement the above methods according to the semantics defined for |
| for them in Section 5.3. |  | them in Section 4.3. |
| Additional methods MAY be used in HTTP; many have already been |  | Additional methods, outside the scope of this specification, have |
| standardized outside the scope of this specification and registered |  | been standardized for use in HTTP. All such methods ought to be |
| within the HTTP Method Registry maintained by IANA, as defined in |  | registered within the HTTP Method Registry maintained by IANA, as |
| Section 9.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 8.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 message 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 |
| origin server SHOULD respond with the 501 (Not Implemented) status |  | origin server SHOULD respond with the 501 (Not Implemented) status |
| code. When a request message is received that is known by an origin |  | code. When a request method is received that is known by an origin |
| server but not allowed for the target resource, the origin server |  | server but not allowed for the target resource, the origin server |
| SHOULD respond with the 405 (Method Not Allowed) status code. |  | SHOULD respond with the 405 (Method Not Allowed) status code. |
| 5.2. Common Method Properties |  | A client can send conditional request header fields (Section 5.2) to |
|  |  | make the requested action conditional on the current state of the |
|  |  | target resource ([Part4]). |
| 5.2.1. Safe Methods |  | 4.2. Common Method Properties |
|  |  | 4.2.1. Safe Methods |
| Request methods are considered "safe" if their defined semantics are |  | Request methods are considered "safe" if their defined semantics are |
| essentially read-only; i.e., the client does not request, and does |  | essentially read-only; i.e., the client does not request, and does |
| not expect, any state change on the origin server as a result of |  | not expect, any state change on the origin server as a result of |
| applying a safe method to a target resource. Likewise, reasonable |  | applying a safe method to a target resource. Likewise, reasonable |
| use of a safe method is not expected to cause any harm, loss of |  | use of a safe method is not expected to cause any harm, loss of |
| property, or unusual burden on the origin server. |  | property, or unusual burden on the origin server. |
| This definition of safe methods does not prevent an implementation |  | This definition of safe methods does not prevent an implementation |
| from including behavior that is potentially harmful, not entirely |  | from including behavior that is potentially harmful, not entirely |
| read-only, or which causes side-effects while invoking a safe method. |  | read-only, or which causes side-effects while invoking a safe method. |
| What is important, however, is that the client did not request that |  | What is important, however, is that the client did not request that |
| additional behavior and cannot be held accountable for it. For |  | additional behavior and cannot be held accountable for it. For |
| example, most servers append request information to access log files |  | example, most servers append request information to access log files |
| at the completion of every response, regardless of the method, and |  | at the completion of every response, regardless of the method, and |
| that is considered safe even though the log storage might become full |  | that is considered safe even though the log storage might become full |
| and crash the server. Likewise, a safe request initiated by |  | and crash the server. Likewise, a safe request initiated by |
| selecting an advertisement on the Web will often have the side-effect |  | selecting an advertisement on the Web will often have the side-effect |
| of charging an advertising account. |  | of charging an advertising account. |
| The GET, HEAD, OPTIONS, and TRACE request methods are defined to be |  | Of the request methods defined by this specification, the GET, HEAD, |
| safe. |  | OPTIONS, and TRACE methods are defined to be safe. |
| The purpose of distinguishing between safe and unsafe methods is to |  | The purpose of distinguishing between safe and unsafe methods is to |
| allow automated retrieval processes (spiders) and cache performance |  | allow automated retrieval processes (spiders) and cache performance |
| optimization (pre-fetching) to work without fear of causing harm. In |  | optimization (pre-fetching) to work without fear of causing harm. In |
| addition, it allows a user agent to apply appropriate constraints on |  | addition, it allows a user agent to apply appropriate constraints on |
| the automated use of unsafe methods when processing potentially |  | the automated use of unsafe methods when processing potentially |
| untrusted content. |  | untrusted content. |
| A user agent SHOULD distinguish between safe and unsafe methods when |  | A user agent SHOULD distinguish between safe and unsafe methods when |
| presenting potential actions to a user, such that the user can be |  | presenting potential actions to a user, such that the user can be |
| skipping to change at page 25, line 14 |  | skipping to change at page 23, line 16 |
| consistent with the request method semantics. For example, it is |  | consistent with the request method semantics. For example, it is |
| common for Web-based content editing software to use actions within |  | common for Web-based content editing software to use actions within |
| query parameters, such as "page?do=delete". If the purpose of such a |  | query parameters, such as "page?do=delete". If the purpose of such a |
| resource is to perform an unsafe action, then the resource MUST |  | resource is to perform an unsafe action, then the resource MUST |
| disable or disallow that action when it is accessed using a safe |  | disable or disallow that action when it is accessed using a safe |
| request method. Failure to do so will result in unfortunate side- |  | request method. Failure to do so will result in unfortunate side- |
| effects when automated processes perform a GET on every URI reference |  | effects when automated processes perform a GET on every URI reference |
| for the sake of link maintenance, pre-fetching, building a search |  | for the sake of link maintenance, pre-fetching, building a search |
| index, etc. |  | index, etc. |
| 5.2.2. Idempotent Methods |  | 4.2.2. Idempotent Methods |
| Request methods are considered "idempotent" if the intended effect of |  | Request methods are considered "idempotent" if the intended effect of |
| multiple identical requests is the same as for a single request. |  | multiple identical requests is the same as for a single request. Of |
| PUT, DELETE, and all safe request methods are idempotent. |  | the request methods defined by this specification, the PUT, DELETE, |
|  |  | and safe request methods are idempotent. |
| 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 it can establish a new |  | before any response is received, then it can establish a new |
| connection and retry the idempotent request because it knows that |  | connection and retry the idempotent request because it knows that |
| repeating the request will have the same effect even if the original |  | repeating the request will have the same effect even if the original |
| request succeeded. Note, however, that repeated failures would |  | request succeeded. Note, however, that repeated failures would |
| indicate a problem within the server. |  | indicate a problem within the server. |
| 5.2.3. Cacheable Methods |  | 4.2.3. Cacheable Methods |
| Request methods are considered "cacheable" if it is possible and |  | Request methods are considered "cacheable" if it is possible and |
| useful to answer a current client request with a stored response from |  | useful to answer a current client request with a stored response from |
| a prior request. GET and HEAD are defined to be cacheable. In |  | a prior request. GET and HEAD are defined to be cacheable. In |
| general, safe methods that do not depend on a current or |  | general, safe methods that do not depend on a current or |
| authoritative response are cacheable, though the overwhelming |  | authoritative response are cacheable, though the overwhelming |
| majority of caches only support GET and HEAD. HTTP requirements for |  | majority of caches only support GET and HEAD. HTTP requirements for |
| cache behavior and cacheable responses are defined in [Part6]. |  | cache behavior and cacheable responses are defined in [Part6]. |
| 5.3. Method Definitions |  | 4.3. Method Definitions |
|  |  | 4.3.1. GET |
| 5.3.1. GET |  |  |
| The GET method requests transfer of a current representation of the |  |  |
| target resource. |  |  |
| If the target resource is a data-producing process, it is the |  | The GET method requests transfer of a current selected representation |
| produced data which shall be returned as the representation in the |  | for the target resource. GET is the primary mechanism of information |
| response and not the source text of the process, unless that text |  | retrieval and the focus of almost all performance optimizations. |
| happens to be the output of the process. |  | Hence, when people speak of retrieving some identifiable information |
|  |  | via HTTP, they are generally referring to making a GET request. |
| The semantics of the GET method change to a "conditional GET" if the |  | It is tempting to think of resource identifiers as remote filesystem |
| request message includes an If-Modified-Since, If-Unmodified-Since, |  | pathnames, and of representations as being a copy of the contents of |
| If-Match, If-None-Match, or If-Range header field ([Part4]). A |  | such files. In fact, that is how many resources are implemented (see |
| conditional GET requests that the representation be transferred only |  | Section 9.1 for related security considerations). However, there are |
| under the circumstances described by the conditional header field(s). |  | no such limitations in practice. The HTTP interface for a resource |
| The conditional GET request is intended to reduce unnecessary network |  | is just as likely to be implemented as a tree of content objects, a |
| usage by allowing cached representations to be refreshed without |  | programmatic view on various database records, or a gateway to other |
| requiring multiple requests or transferring data already held by the |  | information systems. Even when the URI mapping mechanism is tied to |
| client. |  | a filesystem, an origin server might be configured to execute the |
|  |  | files with the request as input and send the output as the |
|  |  | representation, rather then transfer the files directly. Regardless, |
|  |  | only the origin server needs to know how each of its resource |
|  |  | identifiers correspond to an implementation, and how each |
|  |  | implementation manages to select and send a current representation of |
|  |  | the target resource in a response to GET. |
| The semantics of the GET method change to a "partial GET" if the |  | A client can alter the semantics of GET to be a "range request", |
| request message includes a Range header field ([Part5]). A partial |  | requesting transfer of only some part(s) of the selected |
| GET requests that only part of the representation be transferred, as |  | representation, by sending a Range header field in the request |
| described in Section 5.4 of [Part5]. The partial GET request is |  | ([Part5]). |
| intended to reduce unnecessary network usage by allowing partially- |  |  |
| retrieved representations to be completed without transferring data |  |  |
| already held by the client. |  |  |
| A payload within a GET request message has no defined semantics; |  | A payload within a GET request message has no defined semantics; |
| sending a payload body on a GET request might cause some existing |  | sending a payload body on a GET request might cause some existing |
| implementations to reject the request. |  | implementations to reject the request. |
| The response to a GET request is cacheable and MAY be used to satisfy |  | The response to a GET request is cacheable; a cache MAY use it to |
| subsequent GET and HEAD requests (see [Part6]). |  | satisfy subsequent GET and HEAD requests unless otherwise indicated |
|  |  | by the Cache-Control header field (Section 7.2 of [Part6]). |
| See Section 10.2 for security considerations when used for forms. |  |  |
| 5.3.2. HEAD |  | 4.3.2. HEAD |
| The HEAD method is identical to GET except that the server MUST NOT |  | The HEAD method is identical to GET except that the server MUST NOT |
| return a message body in the response. The metadata contained in the |  | send a message body in the response (i.e., the response terminates at |
| HTTP header fields in response to a HEAD request SHOULD be identical |  | the end of the header block). Aside from the payload header fields |
| to the information sent in response to a GET request. This method |  | (Section 3.3), the server SHOULD send the same header fields in |
| can be used for obtaining metadata about the representation implied |  | response to a HEAD request as it would have sent if the request had |
| by the request without transferring the representation data. This |  | been a GET. This method can be used for obtaining metadata about the |
| method is often used for testing hypertext links for validity, |  | selected representation without transferring the representation data. |
|  |  | This method is often used for testing hypertext links for validity, |
| accessibility, and recent modification. |  | accessibility, and recent modification. |
| The response to a HEAD request is cacheable and MAY be used to |  |  |
| satisfy a subsequent HEAD request. It also has potential side |  |  |
| effects on previously stored responses to GET; see Section 5 of |  |  |
| [Part6]. |  |  |
| A payload within a HEAD request message has no defined semantics; |  | A payload within a HEAD request message has no defined semantics; |
| sending a payload body on a HEAD request might cause some existing |  | sending a payload body on a HEAD request might cause some existing |
| implementations to reject the request. |  | implementations to reject the request. |
| 5.3.3. POST |  | The response to a HEAD request is cacheable; a cache MAY use it to |
|  |  | satisfy subsequent HEAD requests unless otherwise indicated by the |
| The POST method requests that the origin server accept the |  | Cache-Control header field (Section 7.2 of [Part6]). A HEAD response |
| representation enclosed in the request as data to be processed by the |  | might also have an effect on previously cached responses to GET; see |
| target resource. POST is designed to allow a uniform method to cover |  | Section 5 of [Part6]. |
| the following functions: |  |  |
| o Annotation of existing resources; |  | 4.3.3. POST |
| o Posting a message to a bulletin board, newsgroup, mailing list, or |  | The POST method requests that the target resource process the |
| similar group of articles; |  | representation enclosed in the request according to the resource's |
|  |  | own specific semantics. For example, POST is used for the following |
|  |  | functions (among others): |
| o Providing a block of data, such as the result of submitting a |  | o Providing a block of data, such as the fields entered into an HTML |
| form, to a data-handling process; |  | form, to a data-handling process; |
| o Extending a database through an append operation. |  | o Posting a message to a bulletin board, newsgroup, mailing list, |
|  |  | blog, or similar group of articles; |
| The actual function performed by the POST method is determined by the |  | o Creating a new resource that has yet to be identified by the |
| server and is usually dependent on the effective request URI. |  | origin server; and |
| The action performed by the POST method might not result in a |  | o Appending data to a resource's existing representation(s). |
| resource that can be identified by a URI. In this case, either 200 |  |  |
| (OK) or 204 (No Content) is the appropriate response status code, |  |  |
| depending on whether or not the response includes a representation |  |  |
| that describes the result. |  |  |
| If a resource has been created on the origin server, the response |  | An origin server indicates response semantics by choosing an |
| SHOULD be 201 (Created) and contain a representation which describes |  | appropriate status code depending on the result of processing the |
| the status of the request and refers to the new resource, and a |  | POST request; almost all of the status codes defined by this |
| Location header field (see Section 8.1.2). |  | specification might be received in a response to POST (the exceptions |
|  |  | being 206, 304, and 416). |
|  |  | If one or more resources has been created on the origin server as a |
|  |  | result of successfully processing a POST request, the origin server |
|  |  | SHOULD send a 201 (Created) response containing a Location header |
|  |  | field that provides an identifier for the primary resource created |
|  |  | (Section 7.1.2) and a representation that describes the status of the |
|  |  | request while referring to the new resource(s). |
| Responses to POST requests are only cacheable when they include |  | Responses to POST requests are only cacheable when they include |
| explicit freshness information (see Section 4.1.1 of [Part6]). A |  | explicit freshness information (see Section 4.1.1 of [Part6]). |
| cached POST response with a Content-Location header field (see |  | However, POST caching is not widely implemented. For cases where an |
| Section 3.1.4.2) whose value is the effective Request URI MAY be used |  | origin server wishes the client to be able to cache the result of a |
| to satisfy subsequent GET and HEAD (not POST) requests. |  | POST in a way that can be reused by a later GET, the origin server |
|  |  | MAY send a 200 (OK) response containing the result and a Content- |
|  |  | Location header field that has the same value as the POST's effective |
|  |  | request URI (Section 3.1.4.2). |
| Note that POST caching is not widely implemented. However, the 303 |  | If the result of processing a POST would be equivalent to a |
| (See Other) response can be used to direct the user agent to retrieve |  | representation of an existing resource, an origin server MAY redirect |
| a cacheable representation of the resource. |  | the user agent to that resource by sending a 303 (See Other) response |
|  |  | with the existing resource's identifier in the Location field. This |
|  |  | has the benefits of providing the user agent a resource identifier |
|  |  | and transferring the representation via a method more amenable to |
|  |  | shared caching, though at the cost of an extra request if the user |
|  |  | agent does not already have the representation cached. |
| 5.3.4. PUT |  | 4.3.4. PUT |
| The PUT method requests that the state of the target resource be |  | The PUT method requests that the state of the target resource be |
| created or replaced with the state defined by the representation |  | created or replaced with the state defined by the representation |
| enclosed in the request message payload. A successful PUT of a given |  | enclosed in the request message payload. A successful PUT of a given |
| representation would suggest that a subsequent GET on that same |  | representation would suggest that a subsequent GET on that same |
| target resource will result in an equivalent representation being |  | target resource will result in an equivalent representation being |
| returned in a 200 (OK) response. However, there is no guarantee that |  | sent in a 200 (OK) response. However, there is no guarantee that |
| such a state change will be observable, since the target resource |  | such a state change will be observable, since the target resource |
| might be acted upon by other user agents in parallel, or might be |  | might be acted upon by other user agents in parallel, or might be |
| subject to dynamic processing by the origin server, before any |  | subject to dynamic processing by the origin server, before any |
| subsequent GET is received. A successful response only implies that |  | subsequent GET is received. A successful response only implies that |
| the user agent's intent was achieved at the time of its processing by |  | the user agent's intent was achieved at the time of its processing by |
| the origin server. |  | the origin server. |
| If the target resource does not have a current representation and the |  | If the target resource does not have a current representation and the |
| PUT successfully creates one, then the origin server MUST inform the |  | PUT successfully creates one, then the origin server MUST inform the |
| user agent by sending a 201 (Created) response. If the target |  | user agent by sending a 201 (Created) response. If the target |
| resource does have a current representation and that representation |  | resource does have a current representation and that representation |
| is successfully modified in accordance with the state of the enclosed |  | is successfully modified in accordance with the state of the enclosed |
| representation, then either a 200 (OK) or 204 (No Content) response |  | representation, then either a 200 (OK) or 204 (No Content) response |
| SHOULD be sent to indicate successful completion of the request. |  | SHOULD be sent to indicate successful completion of the request. |
| Unrecognized header fields SHOULD be ignored (i.e., not saved as part |  | An origin server SHOULD ignore unrecognized header fields received in |
| of the resource state). |  | a PUT request (i.e., do not save them as part of the resource state). |
| An origin server SHOULD verify that the PUT representation is |  | An origin server SHOULD verify that the PUT representation is |
| consistent with any constraints which the server has for the target |  | consistent with any constraints the server has for the target |
| resource that cannot or will not be changed by the PUT. This is |  | resource that cannot or will not be changed by the PUT. This is |
| particularly important when the origin server uses internal |  | particularly important when the origin server uses internal |
| configuration information related to the URI in order to set the |  | configuration information related to the URI in order to set the |
| values for representation metadata on GET responses. When a PUT |  | values for representation metadata on GET responses. When a PUT |
| representation is inconsistent with the target resource, the origin |  | representation is inconsistent with the target resource, the origin |
| server SHOULD either make them consistent, by transforming the |  | server SHOULD either make them consistent, by transforming the |
| representation or changing the resource configuration, or respond |  | representation or changing the resource configuration, or respond |
| with an appropriate error message containing sufficient information |  | with an appropriate error message containing sufficient information |
| to explain why the representation is unsuitable. The 409 (Conflict) |  | to explain why the representation is unsuitable. The 409 (Conflict) |
| or 415 (Unsupported Media Type) status codes are suggested, with the |  | or 415 (Unsupported Media Type) status codes are suggested, with the |
| skipping to change at page 29, line 23 |  | skipping to change at page 27, line 33 |
| origin server beyond what can be expressed by the intent of the user |  | origin server beyond what can be expressed by the intent of the user |
| agent request and the semantics of the origin server response. It |  | agent request and the semantics of the origin server response. It |
| does not define what a resource might be, in any sense of that word, |  | does not define what a resource might be, in any sense of that word, |
| beyond the interface provided via HTTP. It does not define how |  | beyond the interface provided via HTTP. It does not define how |
| resource state is "stored", nor how such storage might change as a |  | resource state is "stored", nor how such storage might change as a |
| result of a change in resource state, nor how the origin server |  | result of a change in resource state, nor how the origin server |
| translates resource state into representations. Generally speaking, |  | translates resource state into representations. Generally speaking, |
| all implementation details behind the resource interface are |  | all implementation details behind the resource interface are |
| intentionally hidden by the server. |  | intentionally hidden by the server. |
|  |  | An origin server MUST NOT send a validator header field |
|  |  | (Section 7.2), such as an ETag or Last-Modified field, in a |
|  |  | successful response to PUT unless the request's representation data |
|  |  | was saved without any transformation applied to the body (i.e., the |
|  |  | resource's new representation data is identical to the representation |
|  |  | data received in the PUT request) and the validator field value |
|  |  | reflects the new representation. This requirement allows a user |
|  |  | agent to know when the representation body it has in memory remains |
|  |  | current as a result of the PUT, thus not in need of retrieving again |
|  |  | from the origin server, and that the new validator(s) received in the |
|  |  | response can be used for future conditional requests in order to |
|  |  | prevent accidental overwrites (Section 5.2). |
| The fundamental difference between the POST and PUT methods is |  | The fundamental difference between the POST and PUT methods is |
| highlighted by the different intent for the target resource. The |  | highlighted by the different intent for the enclosed representation. |
| target resource in a POST request is intended to handle the enclosed |  | The target resource in a POST request is intended to handle the |
| representation as a data-accepting process, such as for a gateway to |  | enclosed representation according to the resource's own semantics, |
| some other protocol or a document that accepts annotations. In |  | whereas the enclosed representation in a PUT request is defined as |
| contrast, the target resource in a PUT request is intended to take |  | replacing the state of the target resource. Hence, the intent of PUT |
| the enclosed representation as a new or replacement value. Hence, |  | is idempotent and visible to intermediaries, even though the exact |
| the intent of PUT is idempotent and visible to intermediaries, even |  | effect is only known by the origin server. |
| though the exact effect is only known by the origin server. |  |  |
| Proper interpretation of a PUT request presumes that the user agent |  | Proper interpretation of a PUT request presumes that the user agent |
| knows what target resource is desired. A service that is intended to |  | knows which target resource is desired. A service that selects a |
| select a proper URI on behalf of the client, after receiving a state- |  | proper URI on behalf of the client, after receiving a state-changing |
| changing request, SHOULD be implemented using the POST method rather |  | request, SHOULD be implemented using the POST method rather than PUT. |
| than PUT. If the origin server will not make the requested PUT state |  | If the origin server will not make the requested PUT state change to |
| change to the target resource and instead wishes to have it applied |  | the target resource and instead wishes to have it applied to a |
| to a different resource, such as when the resource has been moved to |  | different resource, such as when the resource has been moved to a |
| a different URI, then the origin server MUST send a 301 (Moved |  | different URI, then the origin server MUST send an appropriate 3xx |
| Permanently) response; the user agent MAY then make its own decision |  | (Redirection) response; the user agent MAY then make its own decision |
| regarding whether or not to redirect the request. |  | regarding whether or not to redirect the request. |
| A PUT request applied to the target resource MAY have side-effects on |  | A PUT request applied to the target resource MAY have side-effects on |
| other resources. For example, an article might have a URI for |  | other resources. For example, an article might have a URI for |
| identifying "the current version" (a resource) which is separate from |  | identifying "the current version" (a resource) that is separate from |
| the URIs identifying each particular version (different resources |  | the URIs identifying each particular version (different resources |
| that at one point shared the same state as the current version |  | that at one point shared the same state as the current version |
| resource). A successful PUT request on "the current version" URI |  | resource). A successful PUT request on "the current version" URI |
| might therefore create a new version resource in addition to changing |  | might therefore create a new version resource in addition to changing |
| the state of the target resource, and might also cause links to be |  | the state of the target resource, and might also cause links to be |
| added between the related resources. |  | added between the related resources. |
| An origin server SHOULD reject any PUT request that contains a |  | An origin server SHOULD reject any PUT request that contains a |
| Content-Range header field (Section 5.2 of [Part5]), since it might |  | Content-Range header field (Section 4.2 of [Part5]), since it might |
| be misinterpreted as partial content (or might be partial content |  | be misinterpreted as partial content (or might be partial content |
| that is being mistakenly PUT as a full representation). Partial |  | that is being mistakenly PUT as a full representation). Partial |
| content updates are possible by targeting a separately identified |  | content updates are possible by targeting a separately identified |
| resource with state that overlaps a portion of the larger resource, |  | resource with state that overlaps a portion of the larger resource, |
| or by using a different method that has been specifically defined for |  | or by using a different method that has been specifically defined for |
| partial updates (for example, the PATCH method defined in [RFC5789]). |  | partial updates (for example, the PATCH method defined in [RFC5789]). |
| Responses to the PUT method are not cacheable. If a PUT request |  | Responses to the PUT method are not cacheable. If a PUT request |
| passes through a cache that has one or more stored responses for the |  | passes through a cache that has one or more stored responses for the |
| effective request URI, those stored responses will be invalidated |  | effective request URI, those stored responses will be invalidated |
| (see Section 6 of [Part6]). |  | (see Section 6 of [Part6]). |
| 5.3.5. DELETE |  | 4.3.5. DELETE |
| The DELETE method requests that the origin server delete the target |  | The DELETE method requests that the origin server remove the |
| resource. This method MAY be overridden by human intervention (or |  | association between the target resource and its current |
| other means) on the origin server. The client cannot be guaranteed |  | functionality. In effect, this method is similar to the rm command |
| that the operation has been carried out, even if the status code |  | in UNIX: it expresses a deletion operation on the URI mapping of the |
| returned from the origin server indicates that the action has been |  | origin server, rather than an expectation that the previously |
| completed successfully. However, the server SHOULD NOT indicate |  | associated information be deleted. |
| success unless, at the time the response is given, it intends to |  |  |
| delete the resource or move it to an inaccessible location. |  |  |
| A successful response SHOULD be 200 (OK) if the response includes a |  | If the target resource has one or more current representations, they |
| representation describing the status, 202 (Accepted) if the action |  | might or might not be destroyed by the origin server, and the |
| has not yet been enacted, or 204 (No Content) if the action has been |  | associated storage might or might not be reclaimed, depending |
| enacted but the response does not include a representation. |  | entirely on the nature of the resource and its implementation by the |
|  |  | origin server (which are beyond the scope of this specification). |
|  |  | Likewise, other implementation aspects of a resource might need to be |
|  |  | deactivated or archived as a result of a DELETE, such as database or |
|  |  | gateway connections. In general, it is assumed that the origin |
|  |  | server will only allow DELETE on resources for which it has a |
|  |  | prescribed mechanism for accomplishing the deletion. |
|  |  | Relatively few resources allow the DELETE method -- its primary use |
|  |  | is for remote authoring environments, where the user has some |
|  |  | direction regarding its effect. For example, a resource that was |
|  |  | previously created using a PUT request, or identified via the |
|  |  | Location header field after a 201 (Created) response to a POST |
|  |  | request, might allow a corresponding DELETE request to undo those |
|  |  | actions. Similarly, custom user agent implementations that implement |
|  |  | an authoring function, such as revision control clients using HTTP |
|  |  | for remote operations, might use DELETE based on an assumption that |
|  |  | the server's URI space has been crafted to correspond to a version |
|  |  | repository. |
|  |  | If a DELETE method is successfully applied, the origin server SHOULD |
|  |  | send a 202 (Accepted) status code if the action seems okay but has |
|  |  | not yet been enacted, a 204 (No Content) status code if the action |
|  |  | has been enacted and no further information is to be supplied, or a |
|  |  | 200 (OK) status code if the action has been enacted and the response |
|  |  | message includes a representation describing the status. |
| A payload within a DELETE request message has no defined semantics; |  | A payload within a DELETE request message has no defined semantics; |
| sending a payload body on a DELETE request might cause some existing |  | sending a payload body on a DELETE request might cause some existing |
| implementations to reject the request. |  | implementations to reject the request. |
| Responses to the DELETE method are not cacheable. If a DELETE |  | Responses to the DELETE method are not cacheable. If a DELETE |
| request passes through a cache that has one or more stored responses |  | request passes through a cache that has one or more stored responses |
| for the effective request URI, those stored responses will be |  | for the effective request URI, those stored responses will be |
| invalidated (see Section 6 of [Part6]). |  | invalidated (see Section 6 of [Part6]). |
| 5.3.6. CONNECT |  | 4.3.6. CONNECT |
| The CONNECT method requests that the proxy establish a tunnel to the |  | The CONNECT method requests that the recipient establish a tunnel to |
| request-target and, if successful, thereafter restrict its behavior |  | the destination origin server identified by the request-target and, |
| to blind forwarding of packets until the connection is closed. |  | if successful, thereafter restrict its behavior to blind forwarding |
|  |  | of packets, in both directions, until the connection is closed. |
| When using CONNECT, the request-target MUST use the authority form |  | CONNECT is intended only for use in requests to a proxy. An origin |
| (Section 5.3 of [Part1]); i.e., the request-target consists of only |  | server that receives a CONNECT request for itself MAY respond with a |
| the host name and port number of the tunnel destination, separated by |  | 2xx status code to indicate that a connection is established. |
| a colon. For example, |  |  |
|  |  | However, most origin servers do not implement CONNECT. |
|  |  | A client sending a CONNECT request MUST send the authority form of |
|  |  | request-target (Section 5.3 of [Part1]); i.e., the request-target |
|  |  | consists of only the host name and port number of the tunnel |
|  |  | destination, separated by a colon. For example, |
| CONNECT server.example.com:80 HTTP/1.1 |  | CONNECT server.example.com:80 HTTP/1.1 |
| Host: server.example.com:80 |  | Host: server.example.com:80 |
| Any 2xx (Successful) response to a CONNECT request indicates that the |  | The recipient proxy can establish a tunnel either by directly |
| proxy has established a connection to the requested host and port, |  | connecting to the request-target or, if configured to use another |
| and has switched to tunneling the current connection to that server |  | proxy, by forwarding the CONNECT request to the next inbound proxy. |
| connection. The tunneled data from the server begins immediately |  | Any 2xx (Successful) response indicates that the sender (and all |
| after the blank line that concludes the successful response's header |  | inbound proxies) will switch to tunnel mode immediately after the |
| block. |  | blank line that concludes the successful response's header block; |
|  |  | data received after that blank line is from the server identified by |
|  |  | the request-target. Any response other than a successful response |
|  |  | indicates that the tunnel has not yet been formed and that the |
|  |  | connection remains governed by HTTP. |
| A server SHOULD NOT send any Transfer-Encoding or Content-Length |  | A server SHOULD NOT send any Transfer-Encoding or Content-Length |
| header fields in a successful response. A client MUST ignore any |  | header fields in a successful response. A client MUST ignore any |
| Content-Length or Transfer-Encoding header fields received in a |  | Content-Length or Transfer-Encoding header fields received in a |
| successful response. |  | successful response. |
| Any response other than a successful response indicates that the |  | There are significant risks in establishing a tunnel to arbitrary |
| tunnel has not yet been formed and that the connection remains |  | servers, particularly when the destination is a well-known or |
| governed by HTTP. |  | reserved TCP port that is not intended for Web traffic. For example, |
|  |  | a CONNECT to a request-target of "example.com:25" would suggest that |
|  |  | the proxy connect to the reserved port for SMTP traffic; if allowed, |
|  |  | that could trick the proxy into relaying spam email. Proxies that |
|  |  | support CONNECT SHOULD restrict its use to a limited set of known |
|  |  | ports or a configurable whitelist of safe request targets. |
| Proxy authentication might be used to establish the authority to |  | Proxy authentication might be used to establish the authority to |
| create a tunnel: |  | create a tunnel. For example, |
| CONNECT server.example.com:80 HTTP/1.1 |  | CONNECT server.example.com:80 HTTP/1.1 |
| Host: server.example.com:80 |  | Host: server.example.com:80 |
| Proxy-Authorization: basic aGVsbG86d29ybGQ= |  | Proxy-Authorization: basic aGVsbG86d29ybGQ= |
|  |  | When a tunnel intermediary detects that either side has closed its |
|  |  | connection, any outstanding data that came from that side will first |
|  |  | be sent to the other side and then the intermediary will close both |
|  |  | connections. If there is outstanding data left undelivered, that |
|  |  | data will be discarded. |
| A payload within a CONNECT request message has no defined semantics; |  | A payload within a CONNECT request message has no defined semantics; |
| sending a payload body on a CONNECT request might cause some existing |  | sending a payload body on a CONNECT request might cause some existing |
| implementations to reject the request. |  | implementations to reject the request. |
| Similar to a pipelined HTTP/1.1 request, data to be tunneled from |  | Responses to the CONNECT method are not cacheable. |
| client to server MAY be sent immediately after the request (before a |  |  |
| response is received). The usual caveats also apply: data can be |  |  |
| discarded if the eventual response is negative, and the connection |  |  |
| can be reset with no response if more than one TCP segment is |  |  |
| outstanding. |  |  |
| It might be the case that the proxy itself can only reach the |  |  |
| requested origin server through another proxy. In this case, the |  |  |
| first proxy SHOULD make a CONNECT request of that next proxy, |  |  |
| requesting a tunnel to the authority. A proxy MUST NOT respond with |  |  |
| any 2xx status code unless it has either a direct or tunnel |  |  |
| connection established to the authority. |  |  |
| If at any point either one of the peers gets disconnected, any |  |  |
| outstanding data that came from that peer will be passed to the other |  |  |
| one, and after that also the other connection will be terminated by |  |  |
| the proxy. If there is outstanding data to that peer undelivered, |  |  |
| that data will be discarded. |  |  |
| An origin server which receives a CONNECT request for itself MAY |  |  |
| respond with a 2xx status code to indicate that a connection is |  |  |
| established. However, most origin servers do not implement CONNECT. |  |  |
| 5.3.7. OPTIONS |  | 4.3.7. OPTIONS |
| The OPTIONS method requests information about the communication |  | The OPTIONS method requests information about the communication |
| options available on the request/response chain identified by the |  | options available on the request/response chain identified by the |
| effective request URI. This method allows a client to determine the |  | effective request URI. This method allows a client to determine the |
| options and/or requirements associated with a resource, or the |  | options and/or requirements associated with a resource, or the |
| capabilities of a server, without implying a resource action or |  | capabilities of a server, without implying a resource action. |
| initiating a resource retrieval. |  |  |
| Responses to the OPTIONS method are not cacheable. |  |  |
| If the OPTIONS request includes a payload, then the media type MUST |  |  |
| be indicated by a Content-Type field. Although this specification |  |  |
| does not define any use for such a body, future extensions to HTTP |  |  |
| might use the OPTIONS body to make more detailed queries on the |  |  |
| server. |  |  |
| If the request-target (Section 5.3 of [Part1]) is an asterisk ("*"), |  | An OPTIONS request with an asterisk ("*") as the request-target |
| the OPTIONS request is intended to apply to the server in general |  | (Section 5.3 of [Part1]) applies to the server in general rather than |
| rather than to a specific resource. Since a server's communication |  | to a specific resource. Since a server's communication options |
| options typically depend on the resource, the "*" request is only |  | typically depend on the resource, the "*" request is only useful as a |
| useful as a "ping" or "no-op" type of method; it does nothing beyond |  | "ping" or "no-op" type of method; it does nothing beyond allowing the |
| allowing the client to test the capabilities of the server. For |  | client to test the capabilities of the server. For example, this can |
| example, this can be used to test a proxy for HTTP/1.1 conformance |  | be used to test a proxy for HTTP/1.1 conformance (or lack thereof). |
| (or lack thereof). |  |  |
| If the request-target is not an asterisk, the OPTIONS request applies |  | If the request-target is not an asterisk, the OPTIONS request applies |
| only to the options that are available when communicating with that |  | to the options that are available when communicating with the target |
| resource. |  | resource. |
| A 200 (OK) response SHOULD include any header fields that indicate |  | A server generating a successful response to OPTIONS SHOULD send any |
| optional features implemented by the server and applicable to that |  | header fields that might indicate optional features implemented by |
| resource (e.g., Allow), possibly including extensions not defined by |  | the server and applicable to the target resource (e.g., Allow), |
| this specification. The response payload, if any, SHOULD also |  | including potential extensions not defined by this specification. |
| include information about the communication options. The format for |  | The response payload, if any, might also describe the communication |
| such a payload is not defined by this specification, but might be |  | options in a machine or human-readable representation. A standard |
| defined by future extensions to HTTP. Content negotiation MAY be |  | format for such a representation is not defined by this |
| used to select the appropriate representation. If no payload body is |  | specification, but might be defined by future extensions to HTTP. A |
| included, the response MUST include a Content-Length field with a |  | server MUST generate a Content-Length field with a value of "0" if no |
| field-value of "0". |  | payload body is to be sent in the response. |
| The Max-Forwards header field MAY be used to target a specific proxy |  | A client MAY send a Max-Forwards header field in an OPTIONS request |
| in the request chain (see Section 6.1.1). If no Max-Forwards field |  | to target a specific recipient in the request chain (see |
| is present in the request, then the forwarded request MUST NOT |  | Section 5.1.2). A proxy MUST NOT generate a Max-Forwards header |
| include a Max-Forwards field. |  | field while forwarding a request unless that request was received |
|  |  | with a Max-Forwards field. |
| 5.3.8. TRACE |  | A client that generates an OPTIONS request containing a payload body |
|  |  | MUST send a valid Content-Type header field describing the |
|  |  | representation media type. Although this specification does not |
|  |  | define any use for such a payload, future extensions to HTTP might |
|  |  | use the OPTIONS body to make more detailed queries about the target |
|  |  | resource. |
|  |  | Responses to the OPTIONS method are not cacheable. |
|  |  | 4.3.8. TRACE |
| The TRACE method requests a remote, application-level loop-back of |  | The TRACE method requests a remote, application-level loop-back of |
| the request message. The final recipient of the request SHOULD |  | the request message. The final recipient of the request SHOULD |
| reflect the message received back to the client as the message body |  | reflect the message received, excluding some fields described below, |
| of a 200 (OK) response. The final recipient is either the origin |  | back to the client as the message body of a 200 (OK) response with a |
| server or the first proxy to receive a Max-Forwards value of zero (0) |  | Content-Type of "message/http" (Section 7.3.1 of [Part1]). The final |
| in the request (see Section 6.1.1). A TRACE request MUST NOT include |  | recipient is either the origin server or the first server to receive |
| a message body. |  | a Max-Forwards value of zero (0) in the request (Section 5.1.2). |
|  |  | A client MUST NOT send header fields in a TRACE request containing |
|  |  | sensitive data that might be disclosed by the response. For example, |
|  |  | it would be foolish for a user agent to send stored user credentials |
|  |  | [Part7] or cookies [RFC6265] in a TRACE request. The final recipient |
|  |  | SHOULD exclude any request header fields from the response body that |
|  |  | are likely to contain sensitive data. |
| TRACE allows the client to see what is being received at the other |  | TRACE allows the client to see what is being received at the other |
| end of the request chain and use that data for testing or diagnostic |  | end of the request chain and use that data for testing or diagnostic |
| information. The value of the Via header field (Section 5.7 of |  | information. The value of the Via header field (Section 5.7.1 of |
| [Part1]) is of particular interest, since it acts as a trace of the |  | [Part1]) is of particular interest, since it acts as a trace of the |
| request chain. Use of the Max-Forwards header field allows the |  | request chain. Use of the Max-Forwards header field allows the |
| client to limit the length of the request chain, which is useful for |  | client to limit the length of the request chain, which is useful for |
| testing a chain of proxies forwarding messages in an infinite loop. |  | testing a chain of proxies forwarding messages in an infinite loop. |
| If the request is valid, the response SHOULD have a Content-Type of |  | A client MUST NOT send a message body in a TRACE request. |
| "message/http" (see Section 7.3.1 of [Part1]) and contain a message |  |  |
| body that encloses a copy of the entire request message. Responses |  |  |
| to the TRACE method are not cacheable. |  |  |
| 6. Request Header Fields |  | Responses to the TRACE method are not cacheable. |
|  |  | 5. Request Header Fields |
| A client sends request header fields to provide more information |  | A client sends request header fields to provide more information |
| about the request context, make the request conditional based on the |  | about the request context, make the request conditional based on the |
| target resource state, suggest preferred formats for the response, |  | target resource state, suggest preferred formats for the response, |
| supply authentication credentials, or modify the expected request |  | supply authentication credentials, or modify the expected request |
| processing. These fields act as request modifiers, similar to the |  | processing. These fields act as request modifiers, similar to the |
| parameters on a programming language method invocation. |  | parameters on a programming language method invocation. |
| 6.1. Controls |  | 5.1. Controls |
| Controls are request header fields that direct specific handling of |  | Controls are request header fields that direct specific handling of |
| the request. |  | the request. |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
|  |  | | Cache-Control | Section 7.2 of [Part6] | |
|  |  | | Expect | Section 5.1.1 | |
| | Host | Section 5.4 of [Part1] | |  | | Host | Section 5.4 of [Part1] | |
| | Max-Forwards | Section 6.1.1 | |  | | Max-Forwards | Section 5.1.2 | |
| | Expect | Section 6.1.2 | |  | | Pragma | Section 7.4 of [Part6] | |
| | Range | Section 5.4 of [Part5] | |  | | Range | Section 3.1 of [Part5] | |
|  |  | | TE | Section 4.3 of [Part1] | |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| 6.1.1. Max-Forwards |  | 5.1.1. Expect |
| The "Max-Forwards" header field provides a mechanism with the TRACE |  |  |
| (Section 5.3.8) and OPTIONS (Section 5.3.7) methods to limit the |  |  |
| number of times that the request is forwarded by proxies. This can |  |  |
| be useful when the client is attempting to trace a request which |  |  |
| appears to be failing or looping mid-chain. |  |  |
| Max-Forwards = 1*DIGIT |  |  |
| The Max-Forwards value is a decimal integer indicating the remaining |  |  |
| number of times this request message can be forwarded. |  |  |
| Each recipient of a TRACE or OPTIONS request containing a Max- |  |  |
| Forwards header field MUST check and update its value prior to |  |  |
| forwarding the request. If the received value is zero (0), the |  |  |
| recipient MUST NOT forward the request; instead, it MUST respond as |  |  |
| the final recipient. If the received Max-Forwards value is greater |  |  |
| than zero, then the forwarded message MUST contain an updated Max- |  |  |
| Forwards field with a value decremented by one (1). |  |  |
| The Max-Forwards header field MAY be ignored for all other request |  |  |
| methods. |  |  |
| 6.1.2. Expect |  |  |
| The "Expect" header field is used to indicate that particular server |  | The "Expect" header field is used to indicate that particular server |
| behaviors are required by the client. |  | behaviors are required by the client. |
| Expect = 1#expectation |  | Expect = 1#expectation |
| expectation = expect-name [ BWS "=" BWS expect-value ] |  | expectation = expect-name [ BWS "=" BWS expect-value ] |
| *( OWS ";" [ OWS expect-param ] ) |  | *( OWS ";" [ OWS expect-param ] ) |
| expect-param = expect-name [ BWS "=" BWS expect-value ] |  | expect-param = expect-name [ BWS "=" BWS expect-value ] |
| expect-name = token |  | expect-name = token |
| expect-value = token / quoted-string |  | expect-value = token / quoted-string |
| If all received Expect header field(s) are syntactically valid but |  | If all received Expect header field(s) are syntactically valid but |
| contain an expectation that the recipient does not understand or |  | contain an expectation that the recipient does not understand or |
| cannot comply with, the recipient MUST respond with a 417 |  | cannot comply with, the recipient MUST respond with a 417 |
| (Expectation Failed) status code. A recipient of a syntactically |  | (Expectation Failed) status code. A recipient of a syntactically |
| invalid Expectation header field MUST respond with a 4xx status code |  | invalid Expectation header field MUST respond with a 4xx status code |
| other than 417. |  | other than 417. |
| The only expectation defined by this specification is: |  |  |
| 100-continue |  |  |
| The "100-continue" expectation is defined below. It does not |  |  |
| support any expect-params. |  |  |
| Comparison is case-insensitive for names (expect-name), and case- |  | Comparison is case-insensitive for names (expect-name), and case- |
| sensitive for values (expect-value). |  | sensitive for values (expect-value). |
| The Expect mechanism is hop-by-hop: the above requirements apply to |  | The Expect header field MUST be forwarded if the request is |
| any server, including proxies. However, the Expect header field |  |  |
| itself is end-to-end; it MUST be forwarded if the request is |  |  |
| forwarded. |  | forwarded. |
| Many older HTTP/1.0 and HTTP/1.1 applications do not understand the |  | Many older HTTP/1.0 and HTTP/1.1 servers do not understand the Expect |
| Expect header field. |  | header field. |
| 6.1.2.1. Use of the 100 (Continue) Status |  | 5.1.1.1. Use of the 100 (Continue) Status |
| The purpose of the 100 (Continue) status code (Section 7.2.1) is to |  | The only expectation defined by this specification is: |
| allow a client that is sending a request message with a payload to |  |  |
| determine if the origin server is willing to accept the request |  | 100-continue |
|  |  | The request includes a payload body and the client will wait for a |
|  |  | 100 (Continue) response after sending the request header section |
|  |  | but before sending the payload body. The 100-continue expectation |
|  |  | does not use any expect-params. |
|  |  | The primary purpose of the 100 (Continue) status code (Section 6.2.1) |
|  |  | is to allow a client that is sending a request message with a payload |
|  |  | to determine if the origin server is willing to accept the request |
| (based on the request header fields) before the client sends the |  | (based on the request header fields) before the client sends the |
| payload body. In some cases, it might either be inappropriate or |  | payload body. In some cases, it might either be inappropriate or |
| highly inefficient for the client to send the payload body if the |  | highly inefficient for the client to send the payload body if the |
| server will reject the message without looking at the body. |  | server will reject the message without looking at the body. |
| Requirements for HTTP/1.1 clients: |  | Requirements for HTTP/1.1 clients: |
| o If a client will wait for a 100 (Continue) response before sending |  | o If a client will wait for a 100 (Continue) response before sending |
| the payload body, it MUST send an Expect header field with the |  | the payload body, it MUST send an Expect header field with the |
| "100-continue" expectation. |  | "100-continue" expectation. |
| skipping to change at page 36, line 10 |  | skipping to change at page 34, line 40 |
| Because of the presence of older implementations, the protocol allows |  | Because of the presence of older implementations, the protocol allows |
| ambiguous situations in which a client might send "Expect: 100- |  | ambiguous situations in which a client might send "Expect: 100- |
| continue" without receiving either a 417 (Expectation Failed) or a |  | continue" without receiving either a 417 (Expectation Failed) or a |
| 100 (Continue) status code. Therefore, when a client sends this |  | 100 (Continue) status code. Therefore, when a client sends this |
| header field to an origin server (possibly via a proxy) from which it |  | header field to an origin server (possibly via a proxy) from which it |
| has never seen a 100 (Continue) status code, the client SHOULD NOT |  | has never seen a 100 (Continue) status code, the client SHOULD NOT |
| wait for an indefinite period before sending the payload body. |  | wait for an indefinite period before sending the payload body. |
| Requirements for HTTP/1.1 origin servers: |  | Requirements for HTTP/1.1 origin servers: |
| o Upon receiving a request which includes an Expect header field |  | o Upon receiving a request that includes an Expect header field with |
| with the "100-continue" expectation, an origin server MUST either |  | the "100-continue" expectation, an origin server MUST either |
| respond with 100 (Continue) status code and continue to read from |  | respond with 100 (Continue) status code and continue to read from |
| the input stream, or respond with a final status code. The origin |  | the input stream, or respond with a final status code. The origin |
| server MUST NOT wait for the payload body before sending the 100 |  | server MUST NOT wait for the payload body before sending the 100 |
| (Continue) response. If it responds with a final status code, it |  | (Continue) response. If the origin server responds with a final |
| MAY close the transport connection or it MAY continue to read and |  | status code, it MUST NOT have performed the request method and MAY |
| discard the rest of the request. It MUST NOT perform the request |  | either close the connection or continue to read and discard the |
| method if it returns a final status code. |  | rest of the request. |
| o An origin server SHOULD NOT send a 100 (Continue) response if the |  | o An origin server SHOULD NOT send a 100 (Continue) response if the |
| request message does not include an Expect header field with the |  | request message does not include an Expect header field with the |
| "100-continue" expectation, and MUST NOT send a 100 (Continue) |  | "100-continue" expectation, and MUST NOT send a 100 (Continue) |
| response if such a request comes from an HTTP/1.0 (or earlier) |  | response if such a request comes from an HTTP/1.0 (or earlier) |
| client. There is an exception to this rule: for compatibility |  | client. There is an exception to this rule: for compatibility |
| with [RFC2068], a server MAY send a 100 (Continue) status code in |  | with [RFC2068], a server MAY send a 100 (Continue) status code in |
| response to an HTTP/1.1 PUT or POST request that does not include |  | response to an HTTP/1.1 PUT or POST request that does not include |
| an Expect header field with the "100-continue" expectation. This |  | an Expect header field with the "100-continue" expectation. This |
| exception, the purpose of which is to minimize any client |  | exception, the purpose of which is to minimize any client |
| skipping to change at page 37, line 25 |  | skipping to change at page 36, line 6 |
| HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST |  | HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST |
| respond with a 417 (Expectation Failed) status code. |  | respond with a 417 (Expectation Failed) status code. |
| o Proxies SHOULD maintain a record of the HTTP version numbers |  | o Proxies SHOULD maintain a record of the HTTP version numbers |
| received from recently-referenced next-hop servers. |  | received from recently-referenced next-hop servers. |
| o A proxy MUST NOT forward a 100 (Continue) response if the request |  | o A proxy MUST NOT forward a 100 (Continue) response if the request |
| message was received from an HTTP/1.0 (or earlier) client and did |  | message was received from an HTTP/1.0 (or earlier) client and did |
| not include an Expect header field with the "100-continue" |  | not include an Expect header field with the "100-continue" |
| expectation. This requirement overrides the general rule for |  | expectation. This requirement overrides the general rule for |
| forwarding of 1xx responses (see Section 7.2.1). |  | forwarding of 1xx responses (see Section 6.2.1). |
| 6.2. Conditionals |  | 5.1.2. Max-Forwards |
| Conditionals are request header fields that indicate a precondition |  | The "Max-Forwards" header field provides a mechanism with the TRACE |
| to be tested before applying the method semantics to the target |  | (Section 4.3.8) and OPTIONS (Section 4.3.7) methods to limit the |
| resource. Each precondition is based on metadata that is expected to |  | number of times that the request is forwarded by proxies. This can |
| change if the selected representation of the target resource is |  | be useful when the client is attempting to trace a request that |
| changed. The HTTP/1.1 conditional request mechanisms are defined in |  | appears to be failing or looping mid-chain. |
|  |  | Max-Forwards = 1*DIGIT |
|  |  | The Max-Forwards value is a decimal integer indicating the remaining |
|  |  | number of times this request message can be forwarded. |
|  |  | Each recipient of a TRACE or OPTIONS request containing a Max- |
|  |  | Forwards header field MUST check and update its value prior to |
|  |  | forwarding the request. If the received value is zero (0), the |
|  |  | recipient MUST NOT forward the request; instead, it MUST respond as |
|  |  | the final recipient. If the received Max-Forwards value is greater |
|  |  | than zero, then the forwarded message MUST contain an updated Max- |
|  |  | Forwards field with a value decremented by one (1). |
|  |  | The Max-Forwards header field MAY be ignored for all other request |
|  |  | methods. |
|  |  | 5.2. Conditionals |
|  |  | The HTTP conditional request header fields [Part4] allow a client to |
|  |  | place a precondition on the state of the target resource, so that the |
|  |  | action corresponding to the method semantics will not be applied if |
|  |  | the precondition evaluates to false. Each precondition defined by |
|  |  | this specification consists of a comparison between a set of |
|  |  | validators obtained from prior representations of the target resource |
|  |  | to the current state of validators for the selected representation |
|  |  | (Section 7.2). Hence, these preconditions evaluate whether the state |
|  |  | of the target resource has changed since a given state known by the |
|  |  | client. The effect of such an evaluation depends on the method |
|  |  | semantics and choice of conditional, as defined in Section 5 of |
| [Part4]. |  | [Part4]. |
| +---------------------+------------------------+ |  | +---------------------+------------------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +---------------------+------------------------+ |  | +---------------------+------------------------+ |
| | If-Match | Section 3.1 of [Part4] | |  | | If-Match | Section 3.1 of [Part4] | |
| | If-None-Match | Section 3.2 of [Part4] | |  | | If-None-Match | Section 3.2 of [Part4] | |
| | If-Modified-Since | Section 3.3 of [Part4] | |  | | If-Modified-Since | Section 3.3 of [Part4] | |
| | If-Unmodified-Since | Section 3.4 of [Part4] | |  | | If-Unmodified-Since | Section 3.4 of [Part4] | |
| | If-Range | Section 5.3 of [Part5] | |  | | If-Range | Section 3.2 of [Part5] | |
| +---------------------+------------------------+ |  | +---------------------+------------------------+ |
| 6.3. Content Negotiation |  | 5.3. Content Negotiation |
|  |  | The following request header fields are sent by a user agent to |
|  |  | engage in proactive negotiation of the response content, as defined |
|  |  | in Section 3.4.1. The preferences sent in these fields apply to any |
|  |  | content in the response, including representations of the target |
|  |  | resource, representations of error or processing status, and |
|  |  | potentially even the miscellaneous text strings that might appear |
|  |  | within the protocol. |
| +-------------------+---------------+ |  | +-------------------+---------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +-------------------+---------------+ |  | +-------------------+---------------+ |
| | Accept | Section 6.3.2 | |  | | Accept | Section 5.3.2 | |
| | Accept-Charset | Section 6.3.3 | |  | | Accept-Charset | Section 5.3.3 | |
| | Accept-Encoding | Section 6.3.4 | |  | | Accept-Encoding | Section 5.3.4 | |
| | Accept-Language | Section 6.3.5 | |  | | Accept-Language | Section 5.3.5 | |
| +-------------------+---------------+ |  | +-------------------+---------------+ |
| 6.3.1. Quality Values |  | 5.3.1. Quality Values |
| Many of the request header fields for proactive content negotiation |  | Many of the request header fields for proactive negotiation use a |
| use a common parameter, named "q" (case-insensitive), to assign a |  | common parameter, named "q" (case-insensitive), to assign a relative |
| relative "weight" to the preference for that associated kind of |  | "weight" to the preference for that associated kind of content. This |
| content. This weight is referred to as a "quality value" (or |  | weight is referred to as a "quality value" (or "qvalue") because the |
| "qvalue") because the same parameter name is often used within server |  | same parameter name is often used within server configurations to |
| configurations to assign a weight to the relative quality of the |  | assign a weight to the relative quality of the various |
| various representations that can be selected for a resource. |  | representations that can be selected for a resource. |
| The weight is normalized to a real number in the range 0 through 1, |  | The weight is normalized to a real number in the range 0 through 1, |
| where 0.001 is the least preferred and 1 is the most preferred; a |  | where 0.001 is the least preferred and 1 is the most preferred; a |
| value of 0 means "not acceptable". If no "q" parameter is present, |  | value of 0 means "not acceptable". If no "q" parameter is present, |
| the default weight is 1. |  | the default weight is 1. |
| weight = OWS ";" OWS "q=" qvalue |  | weight = OWS ";" OWS "q=" qvalue |
| qvalue = ( "0" [ "." 0*3DIGIT ] ) |  | qvalue = ( "0" [ "." 0*3DIGIT ] ) |
| / ( "1" [ "." 0*3("0") ] ) |  | / ( "1" [ "." 0*3("0") ] ) |
| A sender of qvalue MUST NOT generate more than three digits after the |  | A sender of qvalue MUST NOT generate more than three digits after the |
| decimal point. User configuration of these values ought to be |  | decimal point. User configuration of these values ought to be |
| limited in the same fashion. |  | limited in the same fashion. |
| 6.3.2. Accept |  | 5.3.2. Accept |
| The "Accept" header field can be used by user agents to specify |  | The "Accept" header field can be used by user agents to specify |
| response media types that are acceptable. Accept header fields can |  | response media types that are acceptable. Accept header fields can |
| be used to indicate that the request is specifically limited to a |  | be used to indicate that the request is specifically limited to a |
| 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 [ "=" word ] |
| 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 MAY 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 MAY be followed by one or more accept-params, |  | Each media-range might be followed by zero or more applicable media |
| beginning with the "q" parameter for indicating a relative weight, as |  | type parameters (e.g., charset), an optional "q" parameter for |
| defined in Section 6.3.1. The first "q" parameter (if any) separates |  | indicating a relative weight (Section 5.3.1), and then zero or more |
| the media-range parameter(s) from the accept-params. |  | extension parameters. The "q" parameter is necessary if any accept- |
|  |  | ext are present, since it acts as a separator between the two |
|  |  | parameter sets. |
| Note: Use of the "q" parameter name to separate media type |  | Note: Use of the "q" parameter name to separate media type |
| parameters from Accept extension parameters is due to historical |  | parameters from Accept extension parameters is due to historical |
| practice. Although this prevents any media type parameter named |  | practice. Although this prevents any media type parameter named |
| "q" from being used with a media range, such an event is believed |  | "q" from being used with a media range, such an event is believed |
| to be unlikely given the lack of any "q" parameters in the IANA |  | to be unlikely given the lack of any "q" parameters in the IANA |
| media type registry and the rare usage of any media type |  | media type registry and the rare usage of any media type |
| parameters in Accept. Future media types are discouraged from |  | parameters in Accept. Future media types are discouraged from |
| registering any parameter named "q". |  | registering any parameter named "q". |
| skipping to change at page 40, line 6 |  | skipping to change at page 39, line 19 |
| origin server MAY either honor the Accept header field by sending a |  | origin server MAY either honor the Accept header field by sending a |
| 406 (Not Acceptable) response or disregard the Accept header field by |  | 406 (Not Acceptable) response or disregard the Accept header field by |
| treating the response as if it is not subject to content negotiation. |  | treating the response as if it is not subject to content negotiation. |
| A more elaborate example is |  | A more elaborate example is |
| Accept: text/plain; q=0.5, text/html, |  | Accept: text/plain; q=0.5, text/html, |
| text/x-dvi; q=0.8, text/x-c |  | text/x-dvi; q=0.8, text/x-c |
| Verbally, this would be interpreted as "text/html and text/x-c are |  | Verbally, this would be interpreted as "text/html and text/x-c are |
| the preferred media types, but if they do not exist, then send the |  | the equally preferred media types, but if they do not exist, then |
| text/x-dvi representation, and if that does not exist, send the text/ |  | send the text/x-dvi representation, and if that does not exist, send |
| plain representation". |  | the text/plain representation". |
| Media ranges can be overridden by more specific media ranges or |  | Media ranges can be overridden by more specific media ranges or |
| specific media types. If more than one media range applies to a |  | specific media types. If more than one media range applies to a |
| given type, the most specific reference has precedence. For example, |  | given type, the most specific reference has precedence. For example, |
| Accept: text/*, text/plain, text/plain;format=flowed, */* |  | Accept: text/*, text/plain, text/plain;format=flowed, */* |
| have the following precedence: |  | have the following precedence: |
| 1. text/plain;format=flowed |  | 1. text/plain;format=flowed |
| 2. text/plain |  | 2. text/plain |
| 3. text/* |  | 3. text/* |
| 4. */* |  | 4. */* |
| The media type quality factor associated with a given type is |  | The media type quality factor associated with a given type is |
| determined by finding the media range with the highest precedence |  | determined by finding the media range with the highest precedence |
| which matches that type. For example, |  | that matches the type. For example, |
| Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, |  | Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, |
| text/html;level=2;q=0.4, */*;q=0.5 |  | text/html;level=2;q=0.4, */*;q=0.5 |
| would cause the following values to be associated: |  | would cause the following values to be associated: |
| +-------------------+---------------+ |  | +-------------------+---------------+ |
| | Media Type | Quality Value | |  | | Media Type | Quality Value | |
| +-------------------+---------------+ |  | +-------------------+---------------+ |
| | text/html;level=1 | 1 | |  | | text/html;level=1 | 1 | |
| | text/html | 0.7 | |  | | text/html | 0.7 | |
| | text/plain | 0.3 | |  | | text/plain | 0.3 | |
| | image/jpeg | 0.5 | |  | | image/jpeg | 0.5 | |
| | text/html;level=2 | 0.4 | |  | | text/html;level=2 | 0.4 | |
| | text/html;level=3 | 0.7 | |  | | text/html;level=3 | 0.7 | |
| +-------------------+---------------+ |  | +-------------------+---------------+ |
| Note: A user agent might be provided with a default set of quality |  | Note: A user agent might be provided with a default set of quality |
| values for certain media ranges. However, unless the user agent is a |  | values for certain media ranges. However, unless the user agent is a |
| closed system which cannot interact with other rendering agents, this |  | closed system that cannot interact with other rendering agents, this |
| default set ought to be configurable by the user. |  | default set ought to be configurable by the user. |
| 6.3.3. Accept-Charset |  | 5.3.3. Accept-Charset |
| The "Accept-Charset" header field can be used by user agents to |  | The "Accept-Charset" header field can be sent by a user agent to |
| indicate what character encodings are acceptable in a response |  | indicate what charsets are acceptable in textual response content. |
| payload. This field allows clients capable of understanding more |  | This field allows user agents capable of understanding more |
| comprehensive or special-purpose character encodings to signal that |  | comprehensive or special-purpose charsets to signal that capability |
| capability to a server which is capable of representing documents in |  | to an origin server that is capable of representing information in |
| those character encodings. |  | those charsets. |
| Accept-Charset = 1#( ( charset / "*" ) [ weight ] ) |  | Accept-Charset = 1#( ( charset / "*" ) [ weight ] ) |
| Character encoding values (a.k.a., charsets) are described in |  | Charset names are defined in Section 3.1.1.2. A user agent MAY |
| Section 3.1.1.2. Each charset MAY be given an associated quality |  | associate a quality value with each charset to indicate the user's |
| value which represents the user's preference for that charset, as |  | relative preference for that charset, as defined in Section 5.3.1. |
| defined in Section 6.3.1. An example is |  | An example is |
| Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 |  | Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 |
| The special value "*", if present in the Accept-Charset field, |  | The special value "*", if present in the Accept-Charset field, |
| matches every character encoding which is not mentioned elsewhere in |  | matches every charset that is not mentioned elsewhere in the Accept- |
| the Accept-Charset field. If no "*" is present in an Accept-Charset |  | Charset field. If no "*" is present in an Accept-Charset field, then |
| field, then any character encodings not explicitly mentioned in the |  | any charsets not explicitly mentioned in the field are considered |
| 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 character encoding in response. |  | user agent will accept any charset in response. Most general-purpose |
|  |  | user agents do not send Accept-Charset, unless specifically |
|  |  | configured to do so, because a detailed list of supported charsets |
|  |  | makes it easier for a server to identify an individual by virtue of |
|  |  | the user agent's request characteristics (Section 9.6). |
| 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 have a character |  | the available representations for the response has a charset that is |
| encoding that is listed as acceptable, the origin server MAY either |  | listed as acceptable, the origin server MAY either honor the Accept- |
| honor the Accept-Charset header field by sending a 406 (Not |  | Charset header field, by sending a 406 (Not Acceptable) response, or |
| Acceptable) response or disregard the Accept-Charset header field by |  | disregard the Accept-Charset header field by treating the resource as |
| treating the response as if it is not subject to content negotiation. |  | if it is not subject to content negotiation. |
| 6.3.4. Accept-Encoding |  | 5.3.4. Accept-Encoding |
| The "Accept-Encoding" header field can be used by user agents to |  | The "Accept-Encoding" header field can be used by user agents to |
| indicate what response content-codings (Section 3.1.2.1) are |  | indicate what response content-codings (Section 3.1.2.1) are |
| acceptable in the response. An "identity" token is used as a synonym |  | acceptable in the response. An "identity" token is used as a synonym |
| for "no encoding" in order to communicate when no encoding is |  | for "no encoding" in order to communicate when no encoding is |
| preferred. |  | preferred. |
| Accept-Encoding = #( codings [ weight ] ) |  | Accept-Encoding = #( codings [ weight ] ) |
| codings = content-coding / "identity" / "*" |  | codings = content-coding / "identity" / "*" |
| Each codings value MAY be given an associated quality value which |  | Each codings value MAY be given an associated quality value |
| represents the preference for that encoding, as defined in |  | representing the preference for that encoding, as defined in |
| Section 6.3.1. |  | Section 5.3.1. The asterisk "*" symbol in an Accept-Encoding field |
|  |  | matches any available content-coding not explicitly listed in the |
|  |  | header field. |
| For example, |  | For example, |
| Accept-Encoding: compress, gzip |  | Accept-Encoding: compress, gzip |
| Accept-Encoding: |  | Accept-Encoding: |
| Accept-Encoding: * |  | Accept-Encoding: * |
| Accept-Encoding: compress;q=0.5, gzip;q=1.0 |  | Accept-Encoding: compress;q=0.5, gzip;q=1.0 |
| Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 |  | Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 |
|  |  | A request without an Accept-Encoding header field implies that the |
|  |  | user agent has no preferences regarding content-codings. Although |
|  |  | this allows the server to use any content-coding in a response, it |
|  |  | does not imply that the user agent will be able to correctly process |
|  |  | all encodings. |
| A server tests whether a content-coding for a given representation is |  | A server tests whether a content-coding for a given representation is |
| acceptable, according to an Accept-Encoding field, using these rules: |  | acceptable using these rules: |
| 1. The special "*" symbol in an Accept-Encoding field matches any |  | 1. If no Accept-Encoding field is in the request, any content-coding |
| available content-coding not explicitly listed in the header |  | is considered acceptable by the user agent. |
| field. |  |  |
| 2. If the representation has no content-coding, then it is |  | 2. If the representation has no content-coding, then it is |
| acceptable by default unless specifically excluded by the Accept- |  | acceptable by default unless specifically excluded by the Accept- |
| Encoding field stating either "identity;q=0" or "*;q=0" without a |  | Encoding field stating either "identity;q=0" or "*;q=0" without a |
| more specific entry for "identity". |  | more specific entry for "identity". |
| 3. If the representation's content-coding is one of the content- |  | 3. If the representation's content-coding is one of the content- |
| codings listed in the Accept-Encoding field, then it is |  | codings listed in the Accept-Encoding field, then it is |
| acceptable unless it is accompanied by a qvalue of 0. (As |  | acceptable unless it is accompanied by a qvalue of 0. (As |
| defined in Section 6.3.1, a qvalue of 0 means "not acceptable".) |  | defined in Section 5.3.1, a qvalue of 0 means "not acceptable".) |
| 4. If multiple content-codings are acceptable, then the acceptable |  | 4. If multiple content-codings are acceptable, then the acceptable |
| content-coding with the highest non-zero qvalue is preferred. |  | content-coding with the highest non-zero qvalue is preferred. |
| An Accept-Encoding header field with a combined field-value that is |  | An Accept-Encoding header field with a combined field-value that is |
| empty implies that the user agent does not want any content-coding in |  | empty implies that the user agent does not want any content-coding in |
| response. If an Accept-Encoding header field is present in a request |  | response. If an Accept-Encoding header field is present in a request |
| and none of the available representations for the response have a |  | and none of the available representations for the response have a |
| content-coding that is listed as acceptable, the origin server SHOULD |  | content-coding that is listed as acceptable, the origin server SHOULD |
| send a response without any content-coding. |  | send a response without any content-coding. |
| A request without an Accept-Encoding header field implies that the |  |  |
| user agent will accept any content-coding in response. |  |  |
| Note: Most HTTP/1.0 applications do not recognize or obey qvalues |  | Note: Most HTTP/1.0 applications do not recognize or obey qvalues |
| associated with content-codings. This means that qvalues will not |  | associated with content-codings. This means that qvalues might |
| work and are not permitted with x-gzip or x-compress. |  | not work and are not permitted with x-gzip or x-compress. |
| 6.3.5. Accept-Language |  | 5.3.5. Accept-Language |
| The "Accept-Language" header field can be used by user agents to |  | The "Accept-Language" header field can be used by user agents to |
| indicate the set of natural languages that are preferred in the |  | indicate the set of natural languages that are preferred in the |
| response. Language tags are defined in Section 3.1.3.1. |  | response. Language tags are defined in Section 3.1.3.1. |
| Accept-Language = 1#( language-range [ weight ] ) |  | Accept-Language = 1#( language-range [ weight ] ) |
| language-range = |  | language-range = |
| <language-range, defined in [RFC4647], Section 2.1> |  | <language-range, defined in [RFC4647], Section 2.1> |
| Each language-range can be given an associated quality value which |  | Each language-range can be given an associated quality value |
| represents an estimate of the user's preference for the languages |  | representing an estimate of the user's preference for the languages |
| specified by that range, as defined in Section 6.3.1. For example, |  | specified by that range, as defined in Section 5.3.1. For example, |
| Accept-Language: da, en-gb;q=0.8, en;q=0.7 |  | Accept-Language: da, en-gb;q=0.8, en;q=0.7 |
| would mean: "I prefer Danish, but will accept British English and |  | would mean: "I prefer Danish, but will accept British English and |
| other types of English". (see also Section 2.3 of [RFC4647]) |  | other types of English". |
|  |  | Note that some recipients treat the order in which language tags are |
|  |  | listed as an indication of descending priority, particularly for tags |
|  |  | that are assigned equal quality values (no value is the same as q=1). |
|  |  | However, this behavior cannot be relied upon. For consistency and to |
|  |  | maximize interoperability, many user agents assign each language tag |
|  |  | a unique quality value while also listing them in order of decreasing |
|  |  | quality. Additional discussion of language priority lists can be |
|  |  | 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. |  | scheme for their requirements. The "Basic Filtering" scheme |
|  |  | ([RFC4647], Section 3.3.1) is identical to the matching scheme that |
| Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is |  | was previously defined for HTTP in Section 14.4 of [RFC2616]. |
| identical to the matching scheme that was previously defined 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. For a discussion of this |  | preferences of the user in every request (Section 9.6). |
| issue, see Section 10.5. |  |  |
| As intelligibility is highly dependent on the individual user, it is |  | Since intelligibility is highly dependent on the individual user, |
| recommended that client applications make the choice of linguistic |  | user agents need to allow user control over the linguistic |
| preference available to the user. If the choice is not made |  | preference. A user agent that does not provide such control to the |
| available, then the Accept-Language header field MUST NOT be given in |  | user MUST NOT send an Accept-Language header field. |
| the request. |  |  |
| Note: When making the choice of linguistic preference available to |  | Note: User agents ought to provide guidance to users when setting |
| the user, we remind implementers of the fact that users are not |  | a preference, since users are rarely familiar with the details of |
| familiar with the details of language matching as described above, |  | language matching as described above. For example, users might |
| and ought to be provided appropriate guidance. As an example, |  | assume that on selecting "en-gb", they will be served any kind of |
| users might assume that on selecting "en-gb", they will be served |  | English document if British English is not available. A user |
| any kind of English document if British English is not available. |  | agent might suggest, in such a case, to add "en" to the list for |
| A user agent might suggest in such a case to add "en" to get the |  | better matching behavior. |
| best matching behavior. |  |  |
| 6.4. Authentication Credentials |  | 5.4. Authentication Credentials |
|  |  | Two header fields are used for carrying authentication credentials, |
|  |  | as defined in [Part7]. Note that various custom mechanisms for user |
|  |  | authentication use the Cookie header field for this purpose, as |
|  |  | defined in [RFC6265]. |
| +---------------------+------------------------+ |  | +---------------------+------------------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +---------------------+------------------------+ |  | +---------------------+------------------------+ |
| | Authorization | Section 4.1 of [Part7] | |  | | Authorization | Section 4.1 of [Part7] | |
| | Proxy-Authorization | Section 4.3 of [Part7] | |  | | Proxy-Authorization | Section 4.3 of [Part7] | |
| +---------------------+------------------------+ |  | +---------------------+------------------------+ |
| 6.5. Context |  | 5.5. Request Context |
| +-------------------+------------------------+ |  | The following request header fields provide additional information |
| | Header Field Name | Defined in... | |  | about the request context, including information about the user, user |
| +-------------------+------------------------+ |  | agent, and resource behind the request. |
| | From | Section 6.5.1 | |  |  |
| | Referer | Section 6.5.2 | |  |  |
| | TE | Section 4.3 of [Part1] | |  |  |
| | User-Agent | Section 6.5.3 | |  |  |
| +-------------------+------------------------+ |  |  |
| 6.5.1. From |  | +-------------------+---------------+ |
|  |  | | Header Field Name | Defined in... | |
|  |  | +-------------------+---------------+ |
|  |  | | From | Section 5.5.1 | |
|  |  | | Referer | Section 5.5.2 | |
|  |  | | User-Agent | Section 5.5.3 | |
|  |  | +-------------------+---------------+ |
| The "From" header field, if given, SHOULD contain an Internet e-mail |  | 5.5.1. From |
| address for the human user who controls the requesting user agent. |  |  |
| The address SHOULD be machine-usable, as defined by "mailbox" in |  | The "From" header field contains an Internet email address for a |
| Section 3.4 of [RFC5322]: |  | human user who controls the requesting user agent. The address ought |
|  |  | to be machine-usable, as defined by "mailbox" in Section 3.4 of |
|  |  | [RFC5322]: |
| From = mailbox |  | From = mailbox |
| mailbox = <mailbox, defined in [RFC5322], Section 3.4> |  | mailbox = <mailbox, defined in [RFC5322], Section 3.4> |
| An example is: |  | An example is: |
| From: webmaster@example.org |  | From: webmaster@example.org |
| This header field MAY be used for logging purposes and as a means for |  | The From header field is rarely sent by non-robotic user agents. A |
| identifying the source of invalid or unwanted requests. It SHOULD |  | user agent SHOULD NOT send a From header field without explicit |
| NOT be used as an insecure form of access protection. The |  | configuration by the user, since that might conflict with the user's |
| interpretation of this field is that the request is being performed |  | privacy interests or their site's security policy. |
| on behalf of the person given, who accepts responsibility for the |  |  |
| method performed. In particular, robot agents SHOULD include this |  |  |
| header field so that the person responsible for running the robot can |  |  |
| be contacted if problems occur on the receiving end. |  |  |
| The Internet e-mail address in this field MAY be separate from the |  |  |
| Internet host which issued the request. For example, when a request |  |  |
| is passed through a proxy the original issuer's address SHOULD be |  |  |
| used. |  |  |
| The client SHOULD NOT send the From header field without the user's |  |  |
| approval, as it might conflict with the user's privacy interests or |  |  |
| their site's security policy. It is strongly recommended that the |  |  |
| user be able to disable, enable, and modify the value of this field |  |  |
| at any time prior to a request. |  |  |
| 6.5.2. Referer |  | Robotic user agents SHOULD send a valid From header field so that the |
|  |  | person responsible for running the robot can be contacted if problems |
|  |  | occur on servers, such as if the robot is sending excessive, |
|  |  | unwanted, or invalid requests. |
| The "Referer" [sic] header field allows the client to specify the URI |  | Servers SHOULD NOT use the From header field for access control or |
| of the resource from which the target URI was obtained (the |  | authentication, since most recipients will assume that the field |
| "referrer", although the header field is misspelled.). |  | value is public information. |
| The Referer header field allows servers to generate lists of back- |  | 5.5.2. Referer |
| links to resources for interest, logging, optimized caching, etc. It |  |  |
| also allows obsolete or mistyped links to be traced for maintenance. |  |  |
| Some servers use Referer as a means of controlling where they allow |  |  |
| links from (so-called "deep linking"), but legitimate requests do not |  |  |
| always contain a Referer header field. |  |  |
| If the target URI was obtained from a source that does not have its |  | The "Referer" [sic] header field allows the user agent to specify a |
| own URI (e.g., input from the user keyboard), the Referer field MUST |  | URI reference for the resource from which the target URI was obtained |
| either be sent with the value "about:blank", or not be sent at all. |  | (i.e., the "referrer", though the field name is misspelled). A user |
| Note that this requirement does not apply to sources with non-HTTP |  | agent MUST exclude any fragment or userinfo components [RFC3986] when |
| URIs (e.g., FTP). |  | generating the Referer field value. |
| Referer = absolute-URI / partial-URI |  | Referer = absolute-URI / partial-URI |
|  |  | Referer allows servers to generate back-links to other resources for |
|  |  | simple analytics, logging, optimized caching, etc. It also allows |
|  |  | obsolete or mistyped links to be found for maintenance. Some servers |
|  |  | use Referer as a means of denying links from other sites (so-called |
|  |  | "deep linking") or restricting cross-site request forgery (CSRF), but |
|  |  | not all requests contain a Referer header field. |
| Example: |  | Example: |
| Referer: http://www.example.org/hypertext/Overview.html |  | Referer: http://www.example.org/hypertext/Overview.html |
| If the field value is a relative URI, it SHOULD be interpreted |  | If the target URI was obtained from a source that does not have its |
| relative to the effective request URI. The URI MUST NOT include a |  | own URI (e.g., input from the user keyboard, or an entry within the |
| fragment. See Section 10.2 for security considerations. |  | user's bookmarks/favorites), the user agent MUST either exclude |
|  |  | Referer or send it with a value of "about:blank". |
| 6.5.3. User-Agent |  | The Referer field has the potential to reveal information about the |
|  |  | request context or browsing history of the user, which is a privacy |
|  |  | concern if the referring resource's identifier reveals personal |
|  |  | information (such as an account name) or a resource that is supposed |
|  |  | to be confidential (such as behind a firewall or internal to a |
|  |  | secured service). Most general-purpose user agents do not send the |
|  |  | Referer header field when the referring resource is a local "file" or |
|  |  | "data" URI. A user agent SHOULD NOT send a Referer header field in |
|  |  | an unsecured HTTP request if the referring page was received with a |
|  |  | secure protocol. See Section 9.3 for additional security |
|  |  | considerations. |
| The "User-Agent" header field contains information about the user |  | Some intermediaries have been known to indiscriminately remove |
| agent originating the request. User agents SHOULD include this field |  | Referer header fields from outgoing requests. This has the |
| with requests. |  | unfortunate side-effect of interfering with protection against CSRF |
|  |  | attacks, which can be far more harmful to their users. |
|  |  | Intermediaries and user agent extensions that wish to limit |
|  |  | information disclosure in Referer ought to restrict their changes to |
|  |  | specific edits, such as replacing internal domain names with |
|  |  | pseudonyms or truncating the query and/or path components. |
|  |  | Intermediaries SHOULD NOT modify or delete the Referer field when the |
|  |  | field value shares the same scheme and host as the request target. |
| Typically, it is used for statistical purposes, the tracing of |  | 5.5.3. User-Agent |
| protocol violations, and tailoring responses to avoid particular user |  |  |
| agent limitations. |  |  |
| The field can contain multiple product tokens (Section 4) and |  | The "User-Agent" header field contains information about the user |
| comments (Section 3.2 of [Part1]) identifying the agent and its |  | agent originating the request, which is often used by servers to help |
| significant subproducts. By convention, the product tokens are |  | identify the scope of reported interoperability problems, to work |
| listed in order of their significance for identifying the |  | around or tailor responses to avoid particular user agent |
| application. |  | limitations, and for analytics regarding browser or operating system |
|  |  | use. A user agent SHOULD send a User-Agent field in each request |
|  |  | unless specifically configured not to do so. |
| Because this field is usually sent on every request a user agent |  | User-Agent = product *( RWS ( product / comment ) ) |
| makes, implementations are encouraged not to include needlessly fine- |  |  |
| grained detail, and to limit (or even prohibit) the addition of |  |  |
| subproducts by third parties. Overly long and detailed User-Agent |  |  |
| field values make requests larger and can also be used to identify |  |  |
| ("fingerprint") the user against their wishes. |  |  |
| Likewise, implementations are encouraged not to use the product |  | The User-Agent field-value consists of one or more product |
| tokens of other implementations in order to declare compatibility |  | identifiers, each followed by zero or more comments (Section 3.2 of |
| with them, as this circumvents the purpose of the field. Finally, |  | [Part1]), which together identify the user agent software and its |
| they are encouraged not to use comments to identify products; doing |  | significant subproducts. By convention, the product identifiers are |
| so makes the field value more difficult to parse. |  | listed in decreasing order of their significance for identifying the |
|  |  | user agent software. Each product identifier consists of a name and |
|  |  | optional version. |
| User-Agent = product *( RWS ( product / comment ) ) |  | product = token ["/" product-version] |
|  |  | product-version = token |
|  |  | Senders SHOULD limit generated product identifiers to what is |
|  |  | necessary to identify the product; senders MUST NOT generate |
|  |  | advertising or other non-essential information within the product |
|  |  | identifier. Senders SHOULD NOT generate information in product- |
|  |  | version that is not a version identifier (i.e., successive versions |
|  |  | of the same product name ought to only differ in the product-version |
|  |  | portion of the product identifier). |
| Example: |  | Example: |
| User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |  | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
| 7. Response Status Codes |  | A user agent SHOULD NOT generate a User-Agent field containing |
|  |  | needlessly fine-grained detail and SHOULD limit the addition of |
|  |  | subproducts by third parties. Overly long and detailed User-Agent |
|  |  | field values increase request latency and the risk of a user being |
|  |  | identified against their wishes ("fingerprinting"). |
| The status-code element is a 3-digit integer result code of the |  | Likewise, implementations are encouraged not to use the product |
| attempt to understand and satisfy the request. |  | tokens of other implementations in order to declare compatibility |
|  |  | with them, as this circumvents the purpose of the field. If a user |
|  |  | agent masquerades as a different user agent, recipients can assume |
|  |  | that the user intentionally desires to see responses tailored for |
|  |  | that identified user agent, even if they might not work as well for |
|  |  | the actual user agent being used. |
| HTTP status codes are extensible. HTTP applications are not required |  | 6. Response Status Codes |
| to understand the meaning of all registered status codes, though such |  |  |
| understanding is obviously desirable. However, applications MUST |  | The status-code element is a 3-digit integer code giving the result |
|  |  | of the attempt to understand and satisfy the request. |
|  |  | HTTP status codes are extensible. HTTP clients are not required to |
|  |  | understand the meaning of all registered status codes, though such |
|  |  | understanding is obviously desirable. However, clients MUST |
| understand the class of any status code, as indicated by the first |  | understand the class of any status code, as indicated by the first |
| digit, and treat any unrecognized response as being equivalent to the |  | digit, and treat an unrecognized status code as being equivalent to |
| x00 status code of that class, with the exception that an |  | the x00 status code of that class, with the exception that a response |
| unrecognized response MUST NOT be cached. For example, if an |  | with an unrecognized status code MUST NOT be cached. |
| unrecognized status code of 431 is received by the client, it can |  |  |
| safely assume that there was something wrong with its request and |  | For example, if an unrecognized status code of 471 is received by a |
| treat the response as if it had received a 400 status code. In such |  | client, the client can assume that there was something wrong with its |
| cases, user agents SHOULD present to the user the representation |  | request and treat the response as if it had received a 400 status |
| enclosed with the response, since that representation is likely to |  | code. The response message will usually contain a representation |
| include human-readable information which will explain the unusual |  | that explains the status. |
| status. |  |  |
| The first digit of the status-code defines the class of response. |  | The first digit of the status-code defines the class of response. |
| The last two digits do not have any categorization role. There are 5 |  | The last two digits do not have any categorization role. There are 5 |
| values for the first digit: |  | values for the first digit: |
| o 1xx (Informational): Request received, continuing process |  | o 1xx (Informational): The request was received, continuing process |
| o 2xx (Successful): The action was successfully received, |  |  |
|  |  | o 2xx (Successful): The request was successfully received, |
| understood, and accepted |  | understood, and accepted |
| o 3xx (Redirection): Further action needs to be taken in order to |  | o 3xx (Redirection): Further action needs to be taken in order to |
| complete the request |  | complete the request |
| o 4xx (Client Error): The request contains bad syntax or cannot be |  | o 4xx (Client Error): The request contains bad syntax or cannot be |
| fulfilled |  | fulfilled |
| o 5xx (Server Error): The server failed to fulfill an apparently |  | o 5xx (Server Error): The server failed to fulfill an apparently |
| valid request |  | valid request |
| For most status codes the response can carry a payload, in which case |  | 6.1. Overview of Status Codes |
| a Content-Type header field indicates the payload's media type |  |  |
| (Section 3.1.1.5). |  |  |
| 7.1. Overview of Status Codes |  |  |
| The status codes listed below are defined in this specification, |  | The status codes listed below are defined in this specification, |
| Section 4 of [Part4], Section 3 of [Part5], and Section 3 of [Part7]. |  | Section 4 of [Part4], Section 4 of [Part5], and Section 3 of [Part7]. |
| The reason phrases listed here are only recommendations -- they can |  | The reason phrases listed here are only recommendations -- they can |
| be replaced by local equivalents without affecting the protocol. |  | be replaced by local equivalents without affecting the protocol. |
| +-------------+------------------------------+----------------------+ |  | +------+-------------------------------+------------------------+ |
| | status-code | reason-phrase | Defined in... | |  | | code | reason-phrase | Defined in... | |
| +-------------+------------------------------+----------------------+ |  | +------+-------------------------------+------------------------+ |
| | 100 | Continue | Section 7.2.1 | |  | | 100 | Continue | Section 6.2.1 | |
| | 101 | Switching Protocols | Section 7.2.2 | |  | | 101 | Switching Protocols | Section 6.2.2 | |
| | 200 | OK | Section 7.3.1 | |  | | 200 | OK | Section 6.3.1 | |
| | 201 | Created | Section 7.3.2 | |  | | 201 | Created | Section 6.3.2 | |
| | 202 | Accepted | Section 7.3.3 | |  | | 202 | Accepted | Section 6.3.3 | |
| | 203 | Non-Authoritative | Section 7.3.4 | |  | | 203 | Non-Authoritative Information | Section 6.3.4 | |
| | | Information | | |  | | 204 | No Content | Section 6.3.5 | |
| | 204 | No Content | Section 7.3.5 | |  | | 205 | Reset Content | Section 6.3.6 | |
| | 205 | Reset Content | Section 7.3.6 | |  | | 206 | Partial Content | Section 4.1 of [Part5] | |
| | 206 | Partial Content | Section 3.1 of | |  | | 300 | Multiple Choices | Section 6.4.1 | |
| | | | [Part5] | |  | | 301 | Moved Permanently | Section 6.4.2 | |
| | 300 | Multiple Choices | Section 7.4.1 | |  | | 302 | Found | Section 6.4.3 | |
| | 301 | Moved Permanently | Section 7.4.2 | |  | | 303 | See Other | Section 6.4.4 | |
| | 302 | Found | Section 7.4.3 | |  | | 304 | Not Modified | Section 4.1 of [Part4] | |
| | 303 | See Other | Section 7.4.4 | |  | | 305 | Use Proxy | Section 6.4.5 | |
| | 304 | Not Modified | Section 4.1 of | |  | | 307 | Temporary Redirect | Section 6.4.7 | |
| | | | [Part4] | |  | | 400 | Bad Request | Section 6.5.1 | |
| | 305 | Use Proxy | Section 7.4.5 | |  | | 401 | Unauthorized | Section 3.1 of [Part7] | |
| | 307 | Temporary Redirect | Section 7.4.7 | |  | | 402 | Payment Required | Section 6.5.2 | |
| | 400 | Bad Request | Section 7.5.1 | |  | | 403 | Forbidden | Section 6.5.3 | |
| | 401 | Unauthorized | Section 3.1 of | |  | | 404 | Not Found | Section 6.5.4 | |
| | | | [Part7] | |  | | 405 | Method Not Allowed | Section 6.5.5 | |
| | 402 | Payment Required | Section 7.5.2 | |  | | 406 | Not Acceptable | Section 6.5.6 | |
| | 403 | Forbidden | Section 7.5.3 | |  | | 407 | Proxy Authentication Required | Section 3.2 of [Part7] | |
| | 404 | Not Found | Section 7.5.4 | |  | | 408 | Request Time-out | Section 6.5.7 | |
| | 405 | Method Not Allowed | Section 7.5.5 | |  | | 409 | Conflict | Section 6.5.8 | |
| | 406 | Not Acceptable | Section 7.5.6 | |  | | 410 | Gone | Section 6.5.9 | |
| | 407 | Proxy Authentication | Section 3.2 of | |  | | 411 | Length Required | Section 6.5.10 | |
| | | Required | [Part7] | |  | | 412 | Precondition Failed | Section 4.2 of [Part4] | |
| | 408 | Request Time-out | Section 7.5.7 | |  | | 413 | Payload Too Large | Section 6.5.11 | |
| | 409 | Conflict | Section 7.5.8 | |  | | 414 | URI Too Long | Section 6.5.12 | |
| | 410 | Gone | Section 7.5.9 | |  | | 415 | Unsupported Media Type | Section 6.5.13 | |
| | 411 | Length Required | Section 7.5.10 | |  | | 416 | Range Not Satisfiable | Section 4.4 of [Part5] | |
| | 412 | Precondition Failed | Section 4.2 of | |  | | 417 | Expectation Failed | Section 6.5.14 | |
| | | | [Part4] | |  | | 426 | Upgrade Required | Section 6.5.15 | |
| | 413 | Request Representation Too | Section 7.5.11 | |  | | 500 | Internal Server Error | Section 6.6.1 | |
| | | Large | | |  | | 501 | Not Implemented | Section 6.6.2 | |
| | 414 | URI Too Long | Section 7.5.12 | |  | | 502 | Bad Gateway | Section 6.6.3 | |
| | 415 | Unsupported Media Type | Section 7.5.13 | |  | | 503 | Service Unavailable | Section 6.6.4 | |
| | 416 | Requested range not | Section 3.2 of | |  | | 504 | Gateway Time-out | Section 6.6.5 | |
| | | satisfiable | [Part5] | |  | | 505 | HTTP Version Not Supported | Section 6.6.6 | |
| | 417 | Expectation Failed | Section 7.5.14 | |  | +------+-------------------------------+------------------------+ |
| | 426 | Upgrade Required | Section 7.5.15 | |  |  |
| | 500 | Internal Server Error | Section 7.6.1 | |  |  |
| | 501 | Not Implemented | Section 7.6.2 | |  |  |
| | 502 | Bad Gateway | Section 7.6.3 | |  |  |
| | 503 | Service Unavailable | Section 7.6.4 | |  |  |
| | 504 | Gateway Time-out | Section 7.6.5 | |  |  |
| | 505 | HTTP Version not supported | Section 7.6.6 | |  |  |
| +-------------+------------------------------+----------------------+ |  |  |
| Note that this list is not exhaustive -- it does not include |  | Note that this list is not exhaustive -- it does not include |
| extension status codes defined in other specifications. |  | extension status codes defined in other specifications. |
| 7.2. Informational 1xx |  | Responses with status codes that are defined as cacheable by default |
|  |  | (e.g., 200, 203, 206, 300, 301, and 410 in this specification) can be |
|  |  | reused by a cache with heuristic expiration unless otherwise |
|  |  | indicated by the method definition or explicit cache controls |
|  |  | [Part6]; all other status codes are not cacheable by default. |
| This class of status code indicates a provisional response, |  | 6.2. Informational 1xx |
| consisting only of the status-line and optional header fields, and is |  |  |
| terminated by an empty line. There are no required header fields for |  | The 1xx (Informational) class of status code indicates an interim |
| this class of status code. Since HTTP/1.0 did not define any 1xx |  | response for communicating connection status or request progress |
|  |  | prior to completing the requested action and sending a final |
|  |  | response. All 1xx responses consist of only the status-line and |
|  |  | optional header fields, and thus are terminated by the empty line at |
|  |  | the end of the header block. Since HTTP/1.0 did not define any 1xx |
| status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 |  | status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 |
| client except under experimental conditions. |  | client except under experimental conditions. |
| A client MUST be prepared to accept one or more 1xx status responses |  | A client MUST be prepared to accept one or more 1xx status responses |
| prior to a regular response, even if the client does not expect a 100 |  | prior to a final response, even if the client does not expect one. A |
| (Continue) status message. Unexpected 1xx status responses MAY be |  | user agent MAY ignore unexpected 1xx status responses. |
| ignored by a user agent. |  |  |
| Proxies MUST forward 1xx responses, unless the connection between the |  | Proxies MUST forward 1xx responses, unless the connection between the |
| proxy and its client has been closed, or unless the proxy itself |  | proxy and its client has been closed, or unless the proxy itself |
| requested the generation of the 1xx response. (For example, if a |  | requested the generation of the 1xx response. For example, if a |
| proxy adds an "Expect: 100-continue" field when it forwards a |  | proxy adds an "Expect: 100-continue" field when it forwards a |
| request, then it need not forward the corresponding 100 (Continue) |  | request, then it need not forward the corresponding 100 (Continue) |
| response(s).) |  | response(s). |
| 7.2.1. 100 Continue |  | 6.2.1. 100 Continue |
| The client SHOULD continue with its request. This interim response |  | The 100 (Continue) status code indicates that the initial part of a |
| is used to inform the client that the initial part of the request has |  | request has been received and has not yet been rejected by the |
| been received and has not yet been rejected by the server. The |  | server. The server intends to send a final response after the |
| client SHOULD continue by sending the remainder of the request or, if |  | request has been fully received and acted upon. |
| the request has already been completed, ignore this response. The |  |  |
| server MUST send a final response after the request has been |  |  |
| completed. See Section 6.1.2.1 for detailed discussion of the use |  |  |
| and handling of this status code. |  |  |
| 7.2.2. 101 Switching Protocols |  | When the request contains an Expect header field that includes a 100- |
|  |  | continue expectation, the 100 response indicates that the server |
|  |  | wishes to receive the request payload body, as described in |
|  |  | Section 5.1.1.1. The client ought to continue sending the request |
|  |  | and discard the 100 response. |
| The server understands and is willing to comply with the client's |  | If the request did not contain an Expect header field containing the |
| request, via the Upgrade message header field (Section 6.3 of |  | 100-continue expectation, the client can simply discard this interim |
| [Part1]), for a change in the application protocol being used on this |  | response. |
| connection. The server will switch protocols to those defined by the |  |  |
| response's Upgrade header field immediately after the empty line |  |  |
| which terminates the 101 response. |  |  |
| The protocol SHOULD be switched only when it is advantageous to do |  | 6.2.2. 101 Switching Protocols |
| so. For example, switching to a newer version of HTTP is |  |  |
| advantageous over older versions, and switching to a real-time, |  |  |
| synchronous protocol might be advantageous when delivering resources |  |  |
| that use such features. |  |  |
| 7.3. Successful 2xx |  | The 101 (Switching Protocols) status code indicates that the server |
|  |  | understands and is willing to comply with the client's request, via |
|  |  | the Upgrade header field (Section 6.7 of [Part1]), for a change in |
|  |  | the application protocol being used on this connection. The server |
|  |  | MUST generate an Upgrade header field in the response that indicates |
|  |  | which protocol(s) will be switched to immediately after the empty |
|  |  | line that terminates the 101 response. |
| This class of status code indicates that the client's request was |  | It is assumed that the server will only agree to switch protocols |
| successfully received, understood, and accepted. |  | when it is advantageous to do so. For example, switching to a newer |
|  |  | version of HTTP might be advantageous over older versions, and |
|  |  | switching to a real-time, synchronous protocol might be advantageous |
|  |  | when delivering resources that use such features. |
| 7.3.1. 200 OK |  | 6.3. Successful 2xx |
| The request has succeeded. The payload returned with the response is |  | The 2xx (Successful) class of status code indicates that the client's |
| dependent on the method used in the request, for example: |  | request was successfully received, understood, and accepted. |
| GET a representation of the target resource is sent in the response; |  | 6.3.1. 200 OK |
| HEAD the same representation as GET, except without the message |  | The |
| body; |  | 200 (OK) status code indicates that the request has succeeded. The |
|  |  | payload sent in a 200 response depends on the request method. For |
|  |  | the methods defined by this specification, the intended meaning of |
|  |  | the payload can be summarized as: |
| POST a representation describing or containing the result of the |  | GET a representation of the target resource; |
| action; |  |  |
| TRACE a representation containing the request message as received by |  | HEAD the same representation as GET, but without the representation |
| the end server. |  | data; |
| Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to |  | POST a representation of the status of, or results obtained from, |
| determine freshness for 200 responses. |  | the action; |
| 7.3.2. 201 Created |  | PUT, DELETE a representation of the status of the action; |
| The request has been fulfilled and has resulted in one or more new |  | OPTIONS a representation of the communications options; |
| resources being created. |  |  |
| Newly created resources are typically linked to from the response |  | TRACE a representation of the request message as received by the end |
| payload, with the most relevant URI also being carried in the |  | server. |
| Location header field. If the newly created resource's URI is the |  |  |
| same as the Effective Request URI, this information can be omitted |  |  |
| (e.g., in the case of a response to a PUT request). |  |  |
| The origin server MUST create the resource(s) before returning the |  | Aside from responses to CONNECT, a 200 response always has a payload, |
| 201 status code. If the action cannot be carried out immediately, |  | though an origin server MAY generate a payload body of zero length. |
| the server SHOULD respond with 202 (Accepted) response instead. |  | If no payload is desired, an origin server ought to send 204 (No |
|  |  | Content) instead. For CONNECT, no payload is allowed because the |
|  |  | successful result is a tunnel, which begins immediately after the 200 |
|  |  | response header block. |
| A 201 response MAY contain an ETag response header field indicating |  | A 200 response is cacheable unless otherwise indicated by the method |
| the current value of the entity-tag for the representation of the |  | definition or explicit cache controls (see Section 4.1.2 of [Part6]). |
| resource identified by the Location header field or, in case the |  |  |
| Location header field was omitted, by the Effective Request URI (see |  |  |
| Section 2.3 of [Part4]). |  |  |
| 7.3.3. 202 Accepted |  | 6.3.2. 201 Created |
| The request has been accepted for processing, but the processing has |  | The 201 (Created) status code indicates that the request has been |
| not been completed. The request might or might not eventually be |  | fulfilled and has resulted in one or more new resources being |
| acted upon, as it might be disallowed when processing actually takes |  | created. The primary resource created by the request is identified |
| place. There is no facility for re-sending a status code from an |  | by either a Location header field in the response or, if no Location |
| asynchronous operation such as this. |  | field is received, by the effective request URI. |
|  |  | The 201 response payload typically describes and links to the |
|  |  | resource(s) created. See Section 7.2 for a discussion of the meaning |
|  |  | and purpose of validator header fields, such as ETag and Last- |
|  |  | Modified, in a 201 response. |
|  |  | 6.3.3. 202 Accepted |
|  |  | The 202 (Accepted) status code indicates that the request has been |
|  |  | accepted for processing, but the processing has not been completed. |
|  |  | The request might or might not eventually be acted upon, as it might |
|  |  | be disallowed when processing actually takes place. There is no |
|  |  | facility in HTTP for re-sending a status code from an asynchronous |
|  |  | operation. |
| The 202 response is intentionally non-committal. Its purpose is to |  | The 202 response is intentionally non-committal. Its purpose is to |
| allow a server to accept a request for some other process (perhaps a |  | allow a server to accept a request for some other process (perhaps a |
| batch-oriented process that is only run once per day) without |  | batch-oriented process that is only run once per day) without |
| requiring that the user agent's connection to the server persist |  | requiring that the user agent's connection to the server persist |
| until the process is completed. The representation returned with |  | until the process is completed. The representation sent with this |
| this response SHOULD include an indication of the request's current |  | response ought to describe the request's current status and point to |
| status and either a pointer to a status monitor or some estimate of |  | (or embed) a status monitor that can provide the user with an |
| when the user can expect the request to be fulfilled. |  | estimate of when the request will be fulfilled. |
| 7.3.4. 203 Non-Authoritative Information |  | 6.3.4. 203 Non-Authoritative Information |
| The representation in the response has been transformed or otherwise |  | The 203 (Non-Authoritative Information) status code indicates that |
| modified by a transforming proxy (Section 2.3 of [Part1]). Note that |  | the request was successful but the enclosed payload has been modified |
| the behavior of transforming intermediaries is controlled by the no- |  | from that of the origin server's 200 (OK) response by a transforming |
| transform Cache-Control directive (Section 7.2 of [Part6]). |  | proxy (Section 5.7.2 of [Part1]). This status code allows the proxy |
|  |  | to notify recipients when a transformation has been applied, since |
|  |  | that knowledge might impact later decisions regarding the content. |
|  |  | For example, future cache validation requests for the content might |
|  |  | only be applicable along the same request path (through the same |
|  |  | proxies). |
| This status code is only appropriate when the response status code |  | The 203 response is similar to the Warning code of 214 Transformation |
| would have been 200 (OK) otherwise. When the status code before |  | Applied (Section 7.5 of [Part6]), which has the advantage of being |
| transformation would have been different, the 214 Transformation |  | applicable to responses with any status code. |
| Applied warn-code (Section 7.5 of [Part6]) is appropriate. |  |  |
| Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to |  | A 203 response is cacheable unless otherwise indicated by the method |
| determine freshness for 203 responses. |  | definition or explicit cache controls (see Section 4.1.2 of [Part6]). |
| 7.3.5. 204 No Content |  | 6.3.5. 204 No Content |
| The 204 (No Content) status code indicates that the server has |  | The 204 (No Content) status code indicates that the server has |
| successfully fulfilled the request and that there is no additional |  | successfully fulfilled the request and that there is no additional |
| content to return in the response payload body. Metadata in the |  | content to send in the response payload body. Metadata in the |
| response header fields refer to the target resource and its current |  | response header fields refer to the target resource and its selected |
| representation after the requested action. |  | representation after the requested action was applied. |
| For example, if a 204 status code is received in response to a PUT |  | For example, if a 204 status code is received in response to a PUT |
| request and the response contains an ETag header field, then the PUT |  | request and the response contains an ETag header field, then the PUT |
| was successful and the ETag field-value contains the entity-tag for |  | was successful and the ETag field-value contains the entity-tag for |
| the new representation of that target resource. |  | the new representation of that target resource. |
| The 204 response allows a server to indicate that the action has been |  | The 204 response allows a server to indicate that the action has been |
| successfully applied to the target resource while implying that the |  | successfully applied to the target resource, while implying that the |
| user agent SHOULD NOT traverse away from its current "document view" |  | user agent does not need to traverse away from its current "document |
| (if any). The server assumes that the user agent will provide some |  | view" (if any). The server assumes that the user agent will provide |
| indication of the success to its user, in accord with its own |  | some indication of the success to its user, in accord with its own |
| interface, and apply any new or updated metadata in the response to |  | interface, and apply any new or updated metadata in the response to |
| the active representation. |  | its active representation. |
| For example, a 204 status code is commonly used with document editing |  | For example, a 204 status code is commonly used with document editing |
| interfaces corresponding to a "save" action, such that the document |  | interfaces corresponding to a "save" action, such that the document |
| being saved remains available to the user for editing. It is also |  | being saved remains available to the user for editing. It is also |
| frequently used with interfaces that expect automated data transfers |  | frequently used with interfaces that expect automated data transfers |
| to be prevalent, such as within distributed version control systems. |  | to be prevalent, such as within distributed version control systems. |
| The 204 response MUST NOT include a message body, and thus is always |  | A 204 response is terminated by the first empty line after the header |
| terminated by the first empty line after the header fields. |  | fields because it cannot contain a message body. |
| 7.3.6. 205 Reset Content |  | A 204 response is cacheable unless otherwise indicated by the method |
|  |  | definition or explicit cache controls (see Section 4.1.2 of [Part6]). |
| The server has fulfilled the request and the user agent SHOULD reset |  | 6.3.6. 205 Reset Content |
| the document view which caused the request to be sent. This response |  |  |
| is primarily intended to allow input for actions to take place via |  |  |
| user input, followed by a clearing of the form in which the input is |  |  |
| given so that the user can easily initiate another input action. |  |  |
| The message body included with the response MUST be empty. Note that |  | The 205 (Reset Content) status code indicates that the server has |
| receivers still need to parse the response according to the algorithm |  | fulfilled the request and desires that the user agent reset the |
| defined in Section 3.3 of [Part1]. |  | "document view", which caused the request to be sent, to its original |
|  |  | state as received from the origin server. |
| 7.4. Redirection 3xx |  | This response is intended to support a common data entry use case |
|  |  | where the user receives content that supports data entry (a form, |
|  |  | notepad, canvas, etc.), enters or manipulates data in that space, |
|  |  | causes the entered data to be submitted in a request, and then the |
|  |  | data entry mechanism is reset for the next entry so that the user can |
|  |  | easily initiate another input action. |
| This class of status code indicates that further action needs to be |  | Since the 205 status code implies that no additional content will be |
| taken by the user agent in order to fulfill the request. If the |  | provided in the payload, the server MUST send a message body of zero |
| required action involves a subsequent HTTP request, it MAY be carried |  | length. In other words, the server MUST send a "Content-Length: 0" |
| out by the user agent without interaction with the user if and only |  | field in a 205 response or close the connection immediately after |
| if the method used in the second request is known to be "safe", as |  | sending the blank line terminating the header section. |
| defined in Section 5.2.1. |  |  |
| There are several types of redirects: |  | 6.4. Redirection 3xx |
| 1. Redirects of the request to another URI, either temporarily or |  | The 3xx (Redirection) class of status code indicates that further |
| permanently. The new URI is specified in the Location header |  | action needs to be taken by the user agent in order to fulfill the |
| field. In this specification, the status codes 301 (Moved |  | request. If a Location header field (Section 7.1.2) is provided, the |
| Permanently), 302 (Found), and 307 (Temporary Redirect) fall |  | user agent MAY automatically redirect its request to the URI |
| under this category. |  | referenced by the Location field value, even if the specific status |
|  |  | code is not understood. Automatic redirection needs to done with |
|  |  | care for methods not known to be safe, as defined in Section 4.2.1, |
|  |  | since the user might not wish to redirect an unsafe request. |
| 2. Redirection to a new location that represents an indirect |  | There are several types of redirects: |
| response to the request, such as the result of a POST operation |  |  |
| to be retrieved with a subsequent GET request. This is status |  |  |
| code 303 (See Other). |  |  |
| 3. Redirection offering a choice of matching resources for use by |  | 1. Redirects that indicate the resource might be available at a |
| reactive content negotiation (Section 3.4.2). This is status |  | different URI, as provided by the Location field, as in the |
| code 300 (Multiple Choices). |  | status codes 301 (Moved Permanently), 302 (Found), and 307 |
|  |  | (Temporary Redirect). |
| 4. Other kinds of redirection, such as to a cached result (status |  | 2. Redirection that offers a choice of matching resources, each |
| code 304 (Not Modified), see Section 4.1 of [Part4]). |  | capable of representing the original request target, as in the |
|  |  | 300 (Multiple Choices) status code. |
| Note: In HTTP/1.0, only the status codes 301 (Moved Permanently) |  | 3. Redirection to a different resource, identified by the Location |
| and 302 (Found) were defined for the first type of redirect, and |  | field, that can represent an indirect response to the request, as |
| the second type did not exist at all ([RFC1945], Section 9.3). |  | in the 303 (See Other) status code. |
| However it turned out that web forms using POST expected redirects |  |  |
| to change the operation for the subsequent request to retrieval |  |  |
| (GET). To address this use case, HTTP/1.1 introduced the second |  |  |
| type of redirect with the status code 303 (See Other) ([RFC2068], |  |  |
| Section 10.3.4). As user agents did not change their behavior to |  |  |
| maintain backwards compatibility, the first revision of HTTP/1.1 |  |  |
| added yet another status code, 307 (Temporary Redirect), for which |  |  |
| the backwards compatibility problems did not apply ([RFC2616], |  |  |
| Section 10.3.8). Over 10 years later, most user agents still do |  |  |
| method rewriting for status codes 301 and 302, therefore this |  |  |
| specification makes that behavior conformant in case the original |  |  |
| request was POST. |  |  |
| A Location header field on a 3xx response indicates that a client MAY |  | 4. Redirection to a previously cached result, as in the 304 (Not |
| automatically redirect to the URI provided; see Section 8.1.2. |  | Modified) status code. |
| Note that for methods not known to be "safe", as defined in |  | Note: In HTTP/1.0, the status codes 301 (Moved Permanently) and |
| Section 5.2.1, automatic redirection needs to done with care, since |  | 302 (Found) were defined for the first type of redirect |
| the redirect might change the conditions under which the request was |  | ([RFC1945], Section 9.3). Early user agents split on whether the |
| issued. |  | method applied to the redirect target would be the same as the |
|  |  | original request or would be rewritten as GET. Although HTTP |
|  |  | originally defined the former semantics for 301 and 302 (to match |
|  |  | its original implementation at CERN), and defined 303 (See Other) |
|  |  | to match the latter semantics, prevailing practice gradually |
|  |  | converged on the latter semantics for 301 and 302 as well. The |
|  |  | first revision of HTTP/1.1 added 307 (Temporary Redirect) to |
|  |  | indicate the former semantics without being impacted by divergent |
|  |  | practice. Over 10 years later, most user agents still do method |
|  |  | rewriting for 301 and 302; therefore, this specification makes |
|  |  | that behavior conformant when the original request is POST. |
| Clients SHOULD detect and intervene in cyclical redirections (i.e., |  | Clients SHOULD detect and intervene in cyclical redirections (i.e., |
| "infinite" redirection loops). |  | "infinite" redirection loops). |
| Note: An earlier version of this specification recommended a |  | Note: An earlier version of this specification recommended a |
| maximum of five redirections ([RFC2068], Section 10.3). Content |  | maximum of five redirections ([RFC2068], Section 10.3). Content |
| developers need to be aware that some clients might implement such |  | developers need to be aware that some clients might implement such |
| a fixed limitation. |  | a fixed limitation. |
| 7.4.1. 300 Multiple Choices |  | 6.4.1. 300 Multiple Choices |
| The target resource has more than one representation, each with its |  |  |
| own specific location, and reactive negotiation information |  |  |
| (Section 3.4) is being provided so that the user (or user agent) can |  |  |
| select a preferred representation by redirecting its request to that |  |  |
| location. |  |  |
| Unless it was a HEAD request, the response SHOULD include a |  | The 300 (Multiple Choices) status code indicates that the target |
| representation containing a list of representation metadata and |  | resource has more than one representation, each with its own more |
| location(s) from which the user or user agent can choose the one most |  | specific identifier, and information about the alternatives is being |
| appropriate. Depending upon the format and the capabilities of the |  | provided so that the user (or user agent) can select a preferred |
| user agent, selection of the most appropriate choice MAY be performed |  | representation by redirecting its request to one or more of those |
| automatically. However, this specification does not define any |  | identifiers. In other words, the server desires that the user agent |
| standard for such automatic selection. |  | engage in reactive negotiation to select the most appropriate |
|  |  | representation(s) for its needs (Section 3.4). |
| If the server has a preferred choice of representation, it SHOULD |  | If the server has a preferred choice, the server SHOULD generate a |
| include the specific URI for that representation in the Location |  | Location header field containing a preferred choice's URI reference. |
| field; user agents MAY use the Location field value for automatic |  | The user agent MAY use the Location field value for automatic |
| redirection. |  | redirection. |
| Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to |  | For request methods other than HEAD, the server SHOULD generate a |
| determine freshness for 300 responses. |  | payload in the 300 response containing a list of representation |
|  |  | 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 |
|  |  | from that list automatically, depending upon the list format, but |
|  |  | this specification does not define a standard for such automatic |
|  |  | selection. |
| 7.4.2. 301 Moved Permanently |  | A 300 response is cacheable unless otherwise indicated by the method |
|  |  | definition or explicit cache controls (see Section 4.1.2 of [Part6]). |
| The target resource has been assigned a new permanent URI and any |  | Note: The original proposal for 300 defined the URI header field |
| future references to this resource SHOULD use one of the returned |  | as providing a list of alternative representations, such that it |
| URIs. Clients with link editing capabilities ought to automatically |  | would be usable for 200, 300, and 406 responses and be transferred |
| re-link references to the effective request URI to one or more of the |  | in responses to the HEAD method. However, lack of deployment and |
| new references returned by the server, where possible. |  | disagreement over syntax led to both URI and Alternates (a |
|  |  | subsequent proposal) being dropped from this specification. It is |
|  |  | possible to communicate the list using a set of Link header fields |
|  |  | [RFC5988], each with a relationship of "alternate", though |
|  |  | deployment is a chicken-and-egg problem. |
| Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to |  | 6.4.2. 301 Moved Permanently |
| determine freshness for 301 responses. |  |  |
| The new permanent URI SHOULD be given by the Location field in the |  | The 301 (Moved Permanently) status code indicates that the target |
| response. A response payload can contain a short hypertext note with |  | resource has been assigned a new permanent URI and any future |
| a hyperlink to the new URI(s). |  | references to this resource ought to use one of the enclosed URIs. |
|  |  | Clients with link editing capabilities ought to automatically re-link |
|  |  | references to the effective request URI to one or more of the new |
|  |  | references sent by the server, where possible. |
|  |  | The server SHOULD generate a Location header field in the response |
|  |  | containing a preferred URI reference for the new permanent URI. The |
|  |  | user agent MAY use the Location field value for automatic |
|  |  | redirection. The server's response payload usually contains a short |
|  |  | hypertext note with a hyperlink to the new URI(s). |
| Note: For historic reasons, user agents MAY change the request |  | Note: For historic reasons, user agents 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, status code 307 (Temporary Redirect) can be |  | behavior is undesired, status code 307 (Temporary Redirect) can be |
| used instead. |  | used instead. |
| 7.4.3. 302 Found |  | A 301 response is cacheable unless otherwise indicated by the method |
|  |  | definition or explicit cache controls (see Section 4.1.2 of [Part6]). |
| The target resource resides temporarily under a different URI. Since |  | 6.4.3. 302 Found |
| the redirection might be altered on occasion, the client SHOULD |  |  |
| continue to use the effective request URI for future requests. |  |  |
| The temporary URI SHOULD be given by the Location field in the |  | The 302 (Found) status code indicates that the target resource |
| response. A response payload can contain a short hypertext note with |  | resides temporarily under a different URI. Since the redirection |
| a hyperlink to the new URI(s). |  | might be altered on occasion, the client ought to continue to use the |
|  |  | effective request URI for future requests. |
|  |  | The server SHOULD generate a Location header field in the response |
|  |  | containing a URI reference for the different URI. The user agent MAY |
|  |  | use the Location field value for automatic redirection. The server's |
|  |  | response payload usually contains a short hypertext note with a |
|  |  | hyperlink to the different URI(s). |
| Note: For historic reasons, user agents MAY change the request |  | Note: For historic reasons, user agents 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, status code 307 (Temporary Redirect) can be |  | behavior is undesired, status code 307 (Temporary Redirect) can be |
| used instead. |  | used instead. |
| 7.4.4. 303 See Other |  | 6.4.4. 303 See Other |
| The 303 status code indicates that the server is redirecting the user |  | The 303 (See Other) status code indicates that the server is |
| agent to a different resource, as indicated by a URI in the Location |  | redirecting the user agent to a different resource, as indicated by a |
| header field, that is intended to provide an indirect response to the |  | URI in the Location header field, that is intended to provide an |
| original request. In order to satisfy the original request, a user |  | indirect response to the original request. In order to satisfy the |
| agent SHOULD perform a retrieval request using the Location URI (a |  | original request, a user agent ought to perform a retrieval request |
| GET or HEAD request if using HTTP), which can itself be redirected |  | using the Location URI (a GET or HEAD request if using HTTP), which |
| further, and present the eventual result as an answer to the original |  | can itself be redirected further, and present the eventual result as |
| request. Note that the new URI in the Location header field is not |  | an answer to the original request. Note that the new URI in the |
| considered equivalent to the effective request URI. |  | Location header field is not considered equivalent to the effective |
|  |  | request URI. |
| This status code is generally applicable to any HTTP method. It is |  | This status code is applicable to any HTTP method. It is primarily |
| primarily used to allow the output of a POST action to redirect the |  | used to allow the output of a POST action to redirect the user agent |
| user agent to a selected resource, since doing so provides the |  | to a selected resource, since doing so provides the information |
| information corresponding to the POST response in a form that can be |  | corresponding to the POST response in a form that can be separately |
| separately identified, bookmarked, and cached independent of the |  | identified, bookmarked, and cached independent of the original |
| original request. |  | request. |
| A 303 response to a GET request indicates that the requested resource |  | A 303 response to a GET request indicates that the origin server does |
| does not have a representation of its own that can be transferred by |  | not have a representation of the target resource that can be |
| the server over HTTP. The Location URI indicates a resource that is |  | transferred by the server over HTTP. However, the Location field |
| descriptive of the target resource, such that the follow-on |  | value refers to a resource that is descriptive of the target |
| representation might be useful to recipients without implying that it |  | resource, such that making a retrieval request on that other resource |
| adequately represents the target resource. Note that answers to the |  | might result in a representation that is useful to recipients without |
| questions of what can be represented, what representations are |  | implying that it represents the original target resource. Note that |
| adequate, and what might be a useful description are outside the |  | answers to the questions of what can be represented, what |
| scope of HTTP and thus entirely determined by the URI owner(s). |  | representations are adequate, and what might be a useful description |
|  |  | are outside the scope of HTTP. |
| Except for responses to a HEAD request, the representation of a 303 |  | Except for responses to a HEAD request, the representation of a 303 |
| response SHOULD contain a short hypertext note with a hyperlink to |  | response ought to contain a short hypertext note with a hyperlink to |
| the Location URI. |  | the same URI reference provided in the Location header field. |
| 7.4.5. 305 Use Proxy |  | 6.4.5. 305 Use Proxy |
| The 305 status code was defined in a previous version of this |  | The 305 (Use Proxy) status code was defined in a previous version of |
| specification (see Appendix C), and is now deprecated. |  | this specification and is now deprecated (Appendix B). |
| 7.4.6. 306 (Unused) |  | 6.4.6. 306 (Unused) |
| The 306 status code was used in a previous version of the |  | The 306 status code was defined in a previous version of this |
| specification, is no longer used, and the code is reserved. |  | specification, is no longer used, and the code is reserved. |
| 7.4.7. 307 Temporary Redirect |  | 6.4.7. 307 Temporary Redirect |
| The target resource resides temporarily under a different URI. Since |  | The 307 (Temporary Redirect) status code indicates that the target |
| the redirection can change over time, the client SHOULD continue to |  | resource resides temporarily under a different URI and the user agent |
| use the effective request URI for future requests. |  | MUST NOT change the request method if it performs an automatic |
|  |  | redirection to that URI. Since the redirection can change over time, |
|  |  | the client ought to continue using the original effective request URI |
|  |  | for future requests. |
| The temporary URI SHOULD be given by the Location field in the |  | The server SHOULD generate a Location header field in the response |
| response. A response payload can contain a short hypertext note with |  | containing a URI reference for the different URI. The user agent MAY |
| a hyperlink to the new URI(s). |  | use the Location field value for automatic redirection. The server's |
|  |  | response payload usually contains a short hypertext note with a |
|  |  | hyperlink to the different URI(s). |
| Note: This status code is similar to 302 (Found), except that it |  | Note: This status code is similar to 302 (Found), except that it |
| does not allow rewriting the request method from POST to GET. |  | does not allow changing the request method from POST to GET. This |
| This specification defines no equivalent counterpart for 301 |  | specification defines no equivalent counterpart for 301 (Moved |
| (Moved Permanently) ([status-308], however, defines the status |  | Permanently) ([status-308], however, defines the status code 308 |
| code 308 (Permanent Redirect) for this purpose). |  | (Permanent Redirect) for this purpose). |
| 7.5. Client Error 4xx |  | 6.5. Client Error 4xx |
| The 4xx class of status code is intended for cases in which the |  | The 4xx (Client Error) class of status code indicates that the client |
| client seems to have erred. Except when responding to a HEAD |  | seems to have erred. Except when responding to a HEAD request, the |
| request, the server SHOULD include a representation containing an |  | server SHOULD send a representation containing an explanation of the |
| explanation of the error situation, and whether it is a temporary or |  | error situation, and whether it is a temporary or permanent |
| permanent condition. These status codes are applicable to any |  | condition. These status codes are applicable to any request method. |
| request method. User agents SHOULD display any included |  | User agents SHOULD display any included representation to the user. |
| representation to the user. |  |  |
| 7.5.1. 400 Bad Request |  | 6.5.1. 400 Bad Request |
| The server cannot or will not process the request, due to a client |  | The 400 (Bad Request) status code indicates that the server cannot or |
| error (e.g., malformed syntax). |  | will not process the request because the received syntax is invalid, |
|  |  | nonsensical, or exceeds some limitation on what the server is willing |
|  |  | to process. |
| 7.5.2. 402 Payment Required |  | 6.5.2. 402 Payment Required |
| This code is reserved for future use. |  | The 402 (Payment Required) status code is reserved for future use. |
| 7.5.3. 403 Forbidden |  | 6.5.3. 403 Forbidden |
| The server understood the request, but refuses to authorize it. |  | The 403 (Forbidden) status code indicates that the server understood |
| Providing different user authentication credentials might be |  | the request but refuses to authorize it. A server that wishes to |
| successful, but any credentials that were provided in the request are |  | make public why the request has been forbidden can describe that |
| insufficient. The request SHOULD NOT be repeated with the same |  | reason in the response payload (if any). |
| credentials. |  |  |
| If the request method was not HEAD and the server wishes to make |  | If authentication credentials were provided in the request, the |
| public why the request has not been fulfilled, it SHOULD describe the |  | server considers them insufficient to grant access. The client |
| reason for the refusal in the representation. If the server does not |  | SHOULD NOT repeat the request with the same credentials. The client |
| wish to make this information available to the client, the status |  | MAY repeat the request with new or different credentials. However, a |
| code 404 (Not Found) MAY be used instead. |  | request might be forbidden for reasons unrelated to the credentials. |
| 7.5.4. 404 Not Found |  | An origin server that wishes to "hide" the current existence of a |
|  |  | forbidden target resource MAY instead respond with a status code of |
|  |  | 404 (Not Found). |
| The server has not found anything matching the effective request URI. |  | 6.5.4. 404 Not Found |
| No indication is given of whether the condition is temporary or |  |  |
| permanent. The 410 (Gone) status code SHOULD be used if the server |  |  |
| knows, through some internally configurable mechanism, that an old |  |  |
| resource is permanently unavailable and has no forwarding address. |  |  |
| This status code is commonly used when the server does not wish to |  |  |
| reveal exactly why the request has been refused, or when no other |  |  |
| response is applicable. |  |  |
| 7.5.5. 405 Method Not Allowed |  | The 404 (Not Found) status code indicates that the origin server did |
|  |  | not find a current representation for the target resource or is not |
|  |  | willing to disclose that one exists. A 404 status does not indicate |
|  |  | whether this lack of representation is temporary or permanent; the |
|  |  | 410 (Gone) status code is preferred over 404 if the origin server |
|  |  | knows, presumably through some configurable means, that the condition |
|  |  | is likely to be permanent. |
| The method specified in the request-line is not allowed for the |  | A 404 response is cacheable unless otherwise indicated by the method |
| target resource. The response MUST include an Allow header field |  | definition or explicit cache controls (see Section 4.1.2 of [Part6]). |
| containing a list of valid methods for the requested resource. |  |  |
| 7.5.6. 406 Not Acceptable |  | 6.5.5. 405 Method Not Allowed |
| The resource identified by the request is only capable of generating |  | The 405 (Method Not Allowed) status code indicates that the method |
| response representations which have content characteristics not |  | specified in the request-line is known by the origin server but not |
| acceptable according to the Accept and Accept-* header fields sent in |  | supported by the target resource. The origin server MUST generate an |
| the request. |  | Allow header field in a 405 response containing a list of the target |
|  |  | resource's currently supported methods. |
| Unless it was a HEAD request, the response SHOULD include a |  | A 405 response is cacheable unless otherwise indicated by the method |
| representation containing a list of available representation |  | definition or explicit cache controls (see Section 4.1.2 of [Part6]). |
| characteristics and location(s) from which the user or user agent can |  |  |
| choose the one most appropriate. Depending upon the format and the |  |  |
| capabilities of the user agent, selection of the most appropriate |  |  |
| choice MAY be performed automatically. However, this specification |  |  |
| does not define any standard for such automatic selection. |  |  |
| Note: HTTP/1.1 servers are allowed to return responses which are |  | 6.5.6. 406 Not Acceptable |
| not acceptable according to the accept header fields sent in the |  |  |
| request. In some cases, this might even be preferable to sending |  |  |
| a 406 response. User agents are encouraged to inspect the header |  |  |
| fields of an incoming response to determine if it is acceptable. |  |  |
| If the response could be unacceptable, a user agent SHOULD |  | The 406 (Not Acceptable) status code indicates that the target |
| temporarily stop receipt of more data and query the user for a |  | resource does not have a current representation that would be |
| decision on further actions. |  | acceptable to the user agent, according to the proactive negotiation |
|  |  | header fields received in the request (Section 5.3), and the server |
|  |  | is unwilling to supply a default representation. |
| 7.5.7. 408 Request Timeout |  | The server SHOULD generate a payload containing a list of available |
|  |  | representation characteristics and corresponding resource identifiers |
|  |  | from which the user or user agent can choose the one most |
|  |  | appropriate. A user agent MAY automatically select the most |
|  |  | appropriate choice from that list. However, this specification does |
|  |  | not define any standard for such automatic selection, as described in |
|  |  | Section 6.4.1. |
| The client did not produce a request within the time that the server |  | 6.5.7. 408 Request Timeout |
| was prepared to wait. The client MAY repeat the request without |  |  |
| modifications at any later time. |  |  |
| 7.5.8. 409 Conflict |  | The 408 (Request Timeout) status code indicates that the server did |
|  |  | not receive a complete request message within the time that it was |
|  |  | prepared to wait. A server SHOULD send the close connection option |
|  |  | (Section 6.1 of [Part1]) in the response, since 408 implies that the |
|  |  | server has decided to close the connection rather than continue |
|  |  | waiting. If the client has an outstanding request in transit, the |
|  |  | client MAY repeat that request on a new connection. |
| The request could not be completed due to a conflict with the current |  | 6.5.8. 409 Conflict |
| state of the resource. This code is only allowed in situations where |  |  |
| it is expected that the user might be able to resolve the conflict |  | The 409 (Conflict) status code indicates that the request could not |
| and resubmit the request. The payload SHOULD include enough |  | be completed due to a conflict with the current state of the |
| information for the user to recognize the source of the conflict. |  | resource. This code is used in situations where the user might be |
| Ideally, the response representation would include enough information |  | able to resolve the conflict and resubmit the request. The server |
| for the user or user agent to fix the problem; however, that might |  | SHOULD generate a payload that includes enough information for a user |
| not be possible and is not required. |  | to recognize the source of the conflict. |
| Conflicts are most likely to occur in response to a PUT request. For |  | Conflicts are most likely to occur in response to a PUT request. For |
| example, if versioning were being used and the representation being |  | example, if versioning were being used and the representation being |
| PUT included changes to a resource which conflict with those made by |  | PUT included changes to a resource that conflict with those made by |
| an earlier (third-party) request, the server might use the 409 |  | an earlier (third-party) request, the origin server might use a 409 |
| response to indicate that it can't complete the request. In this |  | response to indicate that it can't complete the request. In this |
| case, the response representation would likely contain a list of the |  | case, the response representation would likely contain information |
| differences between the two versions. |  | useful for merging the differences based on the revision history. |
| 7.5.9. 410 Gone |  | 6.5.9. 410 Gone |
| The target resource is no longer available at the server and no |  | The 410 (Gone) status code indicates that access to the target |
| forwarding address is known. This condition is expected to be |  | resource is no longer available at the origin server and that this |
| considered permanent. Clients with link editing capabilities SHOULD |  | condition is likely to be permanent. If the origin server does not |
| delete references to the effective request URI after user approval. |  | know, or has no facility to determine, whether or not the condition |
| If the server does not know, or has no facility to determine, whether |  | is permanent, the status code 404 (Not Found) ought to be used |
| or not the condition is permanent, the status code 404 (Not Found) |  | instead. |
| SHOULD be used instead. |  |  |
| The 410 response is primarily intended to assist the task of web |  | The 410 response is primarily intended to assist the task of web |
| maintenance by notifying the recipient that the resource is |  | maintenance by notifying the recipient that the resource is |
| intentionally unavailable and that the server owners desire that |  | intentionally unavailable and that the server owners desire that |
| remote links to that resource be removed. Such an event is common |  | remote links to that resource be removed. Such an event is common |
| for limited-time, promotional services and for resources belonging to |  | for limited-time, promotional services and for resources belonging to |
| individuals no longer working at the server's site. It is not |  | individuals no longer associated with the origin server's site. It |
| necessary to mark all permanently unavailable resources as "gone" or |  | is not necessary to mark all permanently unavailable resources as |
| to keep the mark for any length of time -- that is left to the |  | "gone" or to keep the mark for any length of time -- that is left to |
| discretion of the server owner. |  | the discretion of the server owner. |
| Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to |  | A 410 response is cacheable unless otherwise indicated by the method |
| determine freshness for 410 responses. |  | definition or explicit cache controls (see Section 4.1.2 of [Part6]). |
| 7.5.10. 411 Length Required |  | 6.5.10. 411 Length Required |
| The server refuses to accept the request without a defined Content- |  | The 411 (Length Required) status code indicates that the server |
| Length. The client MAY repeat the request if it adds a valid |  | refuses to accept the request without a defined Content-Length |
| Content-Length header field containing the length of the message body |  | (Section 3.3.2 of [Part1]). The client MAY repeat the request if it |
| in the request message. |  | adds a valid Content-Length header field containing the length of the |
|  |  | message body in the request message. |
| 7.5.11. 413 Request Representation Too Large |  | 6.5.11. 413 Payload Too Large |
| The server is refusing to process a request because the request |  | The 413 (Payload Too Large) status code indicates that the server is |
| representation is larger than the server is willing or able to |  | refusing to process a request because the request payload is larger |
| process. The server MAY close the connection to prevent the client |  | than the server is willing or able to process. The server MAY close |
| from continuing the request. |  | the connection to prevent the client from continuing the request. |
| If the condition is temporary, the server SHOULD include a Retry- |  | If the condition is temporary, the server SHOULD generate a Retry- |
| After header field to indicate that it is temporary and after what |  | After header field to indicate that it is temporary and after what |
| time the client MAY try again. |  | time the client MAY try again. |
| 7.5.12. 414 URI Too Long |  | 6.5.12. 414 URI Too Long |
| The server is refusing to service the request because the effective |  | The 414 (URI Too Long) status code indicates that the server is |
| request URI is longer than the server is willing to interpret. This |  | refusing to service the request because the request-target (Section |
| rare condition is only likely to occur when a client has improperly |  | 5.3 of [Part1]) is longer than the server is willing to interpret. |
| converted a POST request to a GET request with long query |  | This rare condition is only likely to occur when a client has |
| information, when the client has descended into a URI "black hole" of |  | improperly converted a POST request to a GET request with long query |
|  |  | information, when the client has descended into a "black hole" of |
| redirection (e.g., a redirected URI prefix that points to a suffix of |  | redirection (e.g., a redirected URI prefix that points to a suffix of |
| itself), or when the server is under attack by a client attempting to |  | itself), or when the server is under attack by a client attempting to |
| exploit security holes present in some servers using fixed-length |  | exploit potential security holes. |
| buffers for reading or manipulating the request-target. |  |  |
| 7.5.13. 415 Unsupported Media Type |  | A 414 response is cacheable unless otherwise indicated by the method |
|  |  | definition or explicit cache controls (see Section 4.1.2 of [Part6]). |
| The server is refusing to service the request because the request |  | 6.5.13. 415 Unsupported Media Type |
| payload is in a format not supported by this request method on the |  |  |
| target resource. |  |  |
| 7.5.14. 417 Expectation Failed |  | The 415 (Unsupported Media Type) status code indicates that the |
|  |  | origin server is refusing to service the request because the payload |
|  |  | is in a format not supported by the target resource for this method. |
|  |  | The format problem might be due to the request's indicated Content- |
|  |  | Type or Content-Encoding, or as a result of inspecting the data |
|  |  | directly. |
| The expectation given in an Expect header field (see Section 6.1.2) |  | 6.5.14. 417 Expectation Failed |
| could not be met by this server, or, if the server is a proxy, the |  |  |
| server has unambiguous evidence that the request could not be met by |  |  |
| the next-hop server. |  |  |
| 7.5.15. 426 Upgrade Required |  | The 417 (Expectation Failed) status code indicates that the |
|  |  | expectation given in the request's Expect header field |
|  |  | (Section 5.1.1) could not be met by at least one of the inbound |
|  |  | servers. |
| The request can not be completed without a prior protocol upgrade. |  | 6.5.15. 426 Upgrade Required |
| This response MUST include an Upgrade header field (Section 6.3 of |  |  |
| [Part1]) specifying the required protocols. |  | The 426 (Upgrade Required) status code indicates that the server |
|  |  | refuses to perform the request using the current protocol but might |
|  |  | be willing to do so after the client upgrades to a different |
|  |  | protocol. The server MUST send an Upgrade header field in a 426 |
|  |  | response to indicate the required protocol(s) (Section 6.7 of |
|  |  | [Part1]). |
| Example: |  | Example: |
| HTTP/1.1 426 Upgrade Required |  | HTTP/1.1 426 Upgrade Required |
| Upgrade: HTTP/3.0 |  | Upgrade: HTTP/3.0 |
| Connection: Upgrade |  | Connection: Upgrade |
| Content-Length: 53 |  | Content-Length: 53 |
| Content-Type: text/plain |  | Content-Type: text/plain |
| This service requires use of the HTTP/3.0 protocol. |  | This service requires use of the HTTP/3.0 protocol. |
| The server SHOULD include a message body in the 426 response which |  | 6.6. Server Error 5xx |
| indicates in human readable form the reason for the error and |  |  |
| describes any alternative courses which might be available to the |  |  |
| user. |  |  |
| 7.6. Server Error 5xx |  |  |
| Response status codes beginning with the digit "5" indicate cases in |  | The 5xx (Server Error) class of status code indicates that the server |
| which the server is aware that it has erred or is incapable of |  | is aware that it has erred or is incapable of performing the |
| performing the request. Except when responding to a HEAD request, |  | requested method. Except when responding to a HEAD request, the |
| the server SHOULD include a representation containing an explanation |  | server SHOULD send a representation containing an explanation of the |
| of the error situation, and whether it is a temporary or permanent |  | error situation, and whether it is a temporary or permanent |
| condition. User agents SHOULD display any included representation to |  | condition. User agents SHOULD display any included representation to |
| the user. These response codes are applicable to any request method. |  | the user. These response codes are applicable to any request method. |
| 7.6.1. 500 Internal Server Error |  | 6.6.1. 500 Internal Server Error |
| The server encountered an unexpected condition which prevented it |  | The 500 (Internal Server Error) status code indicates that the server |
| from fulfilling the request. |  | encountered an unexpected condition that prevented it from fulfilling |
|  |  | the request. |
| 7.6.2. 501 Not Implemented |  | 6.6.2. 501 Not Implemented |
| The server does not support the functionality required to fulfill the |  | The 501 (Not Implemented) status code indicates that the server does |
| request. This is the appropriate response when the server does not |  | not support the functionality required to fulfill the request. This |
| recognize the request method and is not capable of supporting it for |  | is the appropriate response when the server does not recognize the |
| any resource. |  | request method and is not capable of supporting it for any resource. |
| 7.6.3. 502 Bad Gateway |  | A 501 response is cacheable unless otherwise indicated by the method |
|  |  | definition or explicit cache controls (see Section 4.1.2 of [Part6]). |
| The server, while acting as a gateway or proxy, received an invalid |  | 6.6.3. 502 Bad Gateway |
| response from the upstream server it accessed in attempting to |  |  |
| fulfill the request. |  |  |
| 7.6.4. 503 Service Unavailable |  | The 502 (Bad Gateway) status code indicates that the server, while |
|  |  | acting as a gateway or proxy, received an invalid response from an |
|  |  | inbound server it accessed while attempting to fulfill the request. |
| The server is currently unable to handle the request due to a |  | 6.6.4. 503 Service Unavailable |
| temporary overloading or maintenance of the server. |  |  |
| The implication is that this is a temporary condition which will be |  | The 503 (Service Unavailable) status code indicates that the server |
| alleviated after some delay. If known, the length of the delay MAY |  | is currently unable to handle the request due to a temporary overload |
| be indicated in a Retry-After header field (Section 8.1.3). If no |  | or scheduled maintenance, which will likely be alleviated after some |
| Retry-After is given, the client SHOULD handle the response as it |  | delay. The server MAY send a Retry-After header field |
| would for a 500 (Internal Server Error) response. |  | (Section 7.1.3) to suggest an appropriate amount of time for the |
|  |  | client to wait before retrying the request. |
| Note: The existence of the 503 status code does not imply that a |  | Note: The existence of the 503 status code does not imply that a |
| server has to use it when becoming overloaded. Some servers might |  | server has to use it when becoming overloaded. Some servers might |
| wish to simply refuse the connection. |  | simply refuse the connection. |
| 7.6.5. 504 Gateway Timeout |  |  |
| The server, while acting as a gateway or proxy, did not receive a |  | 6.6.5. 504 Gateway Timeout |
| timely response from the upstream server specified by the URI (e.g., |  |  |
| HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed |  |  |
| to access in attempting to complete the request. |  |  |
| Note to implementers: some deployed proxies are known to return |  | The 504 (Gateway Timeout) status code indicates that the server, |
| 400 (Bad Request) or 500 (Internal Server Error) when DNS lookups |  | while acting as a gateway or proxy, did not receive a timely response |
| time out. |  | from an upstream server it needed to access in order to complete the |
|  |  | request. |
| 7.6.6. 505 HTTP Version Not Supported |  | 6.6.6. 505 HTTP Version Not Supported |
| The server does not support, or refuses to support, the protocol |  | The 505 (HTTP Version Not Supported) status code indicates that the |
| version that was used in the request message. The server is |  | server does not support, or refuses to support, the protocol version |
| indicating that it is unable or unwilling to complete the request |  | that was used in the request message. The server is indicating that |
| using the same major version as the client, as described in Section |  | it is unable or unwilling to complete the request using the same |
| 2.6 of [Part1], other than with this error message. The response |  | major version as the client, as described in Section 2.6 of [Part1], |
| SHOULD contain a representation describing why that version is not |  | other than with this error message. The server SHOULD generate a |
| supported and what other protocols are supported by that server. |  | representation for the 505 response that describes why that version |
|  |  | is not supported and what other protocols are supported by that |
|  |  | server. |
| 8. Response Header Fields |  | 7. Response Header Fields |
| The response header fields allow the server to pass additional |  | The response header fields allow the server to pass additional |
| information about the response which cannot be placed in the status- |  | information about the response beyond what is placed in the status- |
| line. These header fields give information about the server and |  | line. These header fields give information about the server, about |
| about further access to the target resource (Section 5.5 of [Part1]). |  | further access to the target resource, or about related resources. |
| 8.1. Control Data |  | Although each response header field has a defined meaning, in |
|  |  | general, the precise semantics might be further refined by the |
|  |  | semantics of the request method and/or response status code. |
|  |  | 7.1. Control Data |
| Response header fields can supply control data that supplements the |  | Response header fields can supply control data that supplements the |
| status code or instructs the client where to go next. |  | status code, directs caching, or instructs the client where to go |
|  |  | next. |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| | Age | Section 7.1 of [Part6] | |  | | Age | Section 7.1 of [Part6] | |
| | Date | Section 8.1.1.2 | |  | | Cache-Control | Section 7.2 of [Part6] | |
| | Location | Section 8.1.2 | |  | | Expires | Section 7.3 of [Part6] | |
| | Retry-After | Section 8.1.3 | |  | | Date | Section 7.1.1.2 | |
|  |  | | Location | Section 7.1.2 | |
|  |  | | Retry-After | Section 7.1.3 | |
|  |  | | Vary | Section 7.1.4 | |
|  |  | | Warning | Section 7.5 of [Part6] | |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| 8.1.1. Origination Date |  | 7.1.1. Origination Date |
| 8.1.1.1. Date/Time Formats |  | 7.1.1.1. Date/Time Formats |
| HTTP applications have historically allowed three different formats |  | Prior to 1995, there were three different formats commonly used by |
| for date/time stamps. However, the preferred format is a fixed- |  | servers to communicate timestamps. For compatibility with old |
| length subset of that defined by [RFC1123]: |  | implementations, all three are defined here. The preferred format is |
|  |  | a fixed-length and single-zone subset of the date and time |
|  |  | specification used by the Internet Message Format [RFC5322]. |
| Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 |  | HTTP-date = IMF-fixdate / obs-date |
| The other formats are described here only for compatibility with |  | An example of the preferred format is |
| obsolete implementations. |  |  |
| Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format |  | Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate |
| Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |  |  |
| HTTP/1.1 clients and servers that parse a date value MUST accept all |  | Examples of the two obsolete formats are |
| three formats (for compatibility with HTTP/1.0), though they MUST |  |  |
| only generate the RFC 1123 format for representing HTTP-date values |  |  |
| in header fields. |  |  |
| All HTTP date/time stamps MUST be represented in Greenwich Mean Time |  | Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format |
| (GMT), without exception. For the purposes of HTTP, GMT is exactly |  | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |
| equal to UTC (Coordinated Universal Time). This is indicated in the |  |  |
| first two formats by the inclusion of "GMT" as the three-letter |  |  |
| abbreviation for time zone, and MUST be assumed when reading the |  |  |
| asctime format. HTTP-date is case sensitive and MUST NOT include |  |  |
| additional whitespace beyond that specifically included as SP in the |  |  |
| grammar. |  |  |
| HTTP-date = rfc1123-date / obs-date |  | A recipient that parses a timestamp value in an HTTP header field |
|  |  | MUST accept all three formats. A sender MUST generate the IMF- |
|  |  | fixdate format when sending an HTTP-date value in a header field. |
|  |  | An HTTP-date value represents time as an instance of Coordinated |
|  |  | Universal Time (UTC). The first two formats indicate UTC by the |
|  |  | three-letter abbreviation for Greenwich Mean Time, "GMT", a |
|  |  | 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 |
|  |  | clock ought to use NTP ([RFC1305]) or some similar protocol to |
|  |  | synchronize its clock to UTC. |
| Preferred format: |  | Preferred format: |
| rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT |  | IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT |
| ; fixed length subset of the format defined in |  | ; fixed length/zone subset of the format defined in |
| ; Section 5.2.14 of [RFC1123] |  | ; 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 63, line 37 |  | skipping to change at page 64, line 45 |
| / %x4D.61.79 ; "May", case-sensitive |  | / %x4D.61.79 ; "May", case-sensitive |
| / %x4A.75.6E ; "Jun", case-sensitive |  | / %x4A.75.6E ; "Jun", case-sensitive |
| / %x4A.75.6C ; "Jul", case-sensitive |  | / %x4A.75.6C ; "Jul", case-sensitive |
| / %x41.75.67 ; "Aug", case-sensitive |  | / %x41.75.67 ; "Aug", case-sensitive |
| / %x53.65.70 ; "Sep", case-sensitive |  | / %x53.65.70 ; "Sep", case-sensitive |
| / %x4F.63.74 ; "Oct", case-sensitive |  | / %x4F.63.74 ; "Oct", case-sensitive |
| / %x4E.6F.76 ; "Nov", case-sensitive |  | / %x4E.6F.76 ; "Nov", case-sensitive |
| / %x44.65.63 ; "Dec", case-sensitive |  | / %x44.65.63 ; "Dec", case-sensitive |
| year = 4DIGIT |  | year = 4DIGIT |
| GMT = %x47.4D.54 ; "GMT", case-sensitive |  | GMT = %x47.4D.54 ; "GMT", case-sensitive |
| time-of-day = hour ":" minute ":" second |  | time-of-day = hour ":" minute ":" second |
| ; 00:00:00 - 23:59:59 |  | ; 00:00:00 - 23:59:60 (leap second) |
| hour = 2DIGIT |  | hour = 2DIGIT |
| minute = 2DIGIT |  | minute = 2DIGIT |
| second = 2DIGIT |  | second = 2DIGIT |
| The semantics of day-name, day, month, year, and time-of-day are the |  |  |
| same as those defined for the RFC 5322 constructs with the |  |  |
| corresponding name ([RFC5322], Section 3.3). |  |  |
| Obsolete formats: |  | Obsolete formats: |
| obs-date = rfc850-date / asctime-date |  | obs-date = rfc850-date / asctime-date |
| 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 |
| date2 = day "-" month "-" 2DIGIT |  | date2 = day "-" month "-" 2DIGIT |
| ; day-month-year (e.g., 02-Jun-82) |  | ; e.g., 02-Jun-82 |
| day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive |  | day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive |
| / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive |  | / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive |
| / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive |  | / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive |
| / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive |  | / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive |
| / %x46.72.69.64.61.79 ; "Friday", case-sensitive |  | / %x46.72.69.64.61.79 ; "Friday", case-sensitive |
| / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive |  | / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive |
| / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive |  | / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive |
| asctime-date = day-name SP date3 SP time-of-day SP year |  | asctime-date = day-name SP date3 SP time-of-day SP year |
| date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) |  | date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) |
| ; month day (e.g., Jun 2) |  | ; e.g., Jun 2 |
| Note: Recipients of date values are encouraged to be robust in |  | HTTP-date is case sensitive. A sender MUST NOT generate additional |
| accepting date values that might have been sent by non-HTTP |  | whitespace in an HTTP-date beyond that specifically included as SP in |
| applications, as is sometimes the case when retrieving or posting |  | the grammar. The semantics of day-name, day, month, year, and time- |
| messages via proxies/gateways to SMTP or NNTP. |  | of-day are the same as those defined for the Internet Message Format |
|  |  | constructs with the corresponding name ([RFC5322], Section 3.3). |
|  |  | Recipients of a timestamp value in rfc850-date format, which uses a |
|  |  | two-digit year, SHOULD interpret a timestamp that appears to be more |
|  |  | than 50 years in the future as representing the most recent year in |
|  |  | the past that had the same last two digits. |
|  |  | Recipients of timestamp values are encouraged to be robust in parsing |
|  |  | timestamps unless otherwise restricted by the field definition. For |
|  |  | example, messages are occasionally forwarded over HTTP from a non- |
|  |  | HTTP source that might generate any of the date and time |
|  |  | specifications defined by the Internet Message Format. |
| Note: HTTP requirements for the date/time stamp format apply only |  | Note: HTTP requirements for the date/time stamp format apply only |
| to their usage within the protocol stream. Clients and servers |  | to their usage within the protocol stream. Implementations are |
| are not required to use these formats for user presentation, |  | not required to use these formats for user presentation, request |
| request logging, etc. |  | logging, etc. |
| 8.1.1.2. Date |  | 7.1.1.2. Date |
| The "Date" header field represents the date and time at which the |  | The "Date" header field represents the date and time at which the |
| message was originated, having the same semantics as the Origination |  | message was originated, having the same semantics as the Origination |
| Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The |  | Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The |
| field value is an HTTP-date, as defined in Section 8.1.1.1; it MUST |  | field value is an HTTP-date, as defined in Section 7.1.1.1. |
| be sent in rfc1123-date format. |  |  |
| Date = HTTP-date |  | Date = HTTP-date |
| An example is |  | An example is |
| Date: Tue, 15 Nov 1994 08:12:31 GMT |  | Date: Tue, 15 Nov 1994 08:12:31 GMT |
| Origin servers MUST include a Date header field in all responses, |  | When a Date header field is generated, the sender SHOULD generate its |
| except in these cases: |  | field value as the best available approximation of the date and time |
|  |  | of message generation. In theory, the date ought to represent the |
| 1. If the response status code is 100 (Continue) or 101 (Switching |  | moment just before the payload is generated. In practice, the date |
| Protocols), the response MAY include a Date header field, at the |  | can be generated at any time during message origination. |
| server's option. |  |  |
| 2. If the response status code conveys a server error, e.g., 500 |  |  |
| (Internal Server Error) or 503 (Service Unavailable), and it is |  |  |
| inconvenient or impossible to generate a valid Date. |  |  |
| 3. If the server does not have a clock that can provide a reasonable |  |  |
| approximation of the current time, its responses MUST NOT include |  |  |
| a Date header field. |  |  |
| A received message that does not have a Date header field MUST be |  | An origin server MUST NOT send a Date header field if it does not |
| assigned one by the recipient if the message will be cached by that |  | have a clock capable of providing a reasonable approximation of the |
| recipient. |  | current instance in Coordinated Universal Time. An origin server MAY |
|  |  | send a Date header field if the response is in the 1xx |
|  |  | (Informational) or 5xx (Server Error) class of status codes. An |
|  |  | origin server MUST send a Date header field in all other cases. |
| Clients can use the Date header field as well; in order to keep |  | A recipient with a clock that receives a response message without a |
| request messages small, they are advised not to include it when it |  | Date header field MUST record the time it was received and append a |
| doesn't convey any useful information (as is usually the case for |  | corresponding Date header field to the message's header block if it |
| requests that do not contain a payload). |  | is cached or forwarded downstream. |
| The HTTP-date sent in a Date header field SHOULD NOT represent a date |  | A user agent MAY send a Date header field in a request, though |
| and time subsequent to the generation of the message. It SHOULD |  | generally will not do so unless it is believed to convey useful |
| represent the best available approximation of the date and time of |  | information to the server. For example, custom applications of HTTP |
| message generation, unless the implementation has no means of |  | might convey a Date if the server is expected to adjust its |
| generating a reasonably accurate date and time. In theory, the date |  | interpretation of the user's request based on differences between the |
| ought to represent the moment just before the payload is generated. |  | user agent and server clocks. |
| In practice, the date can be generated at any time during the message |  |  |
| origination without affecting its semantic value. |  |  |
| 8.1.2. Location |  | 7.1.2. Location |
| The "Location" header field MAY be sent in responses to refer to a |  | The "Location" header field is used in some responses to refer to a |
| specific resource in accordance with the semantics of the status |  | specific resource in relation to the response. The type of |
| code. |  | relationship is defined by the combination of request method and |
|  |  | status code semantics. |
| Location = URI-reference |  | Location = URI-reference |
| For 201 (Created) responses, the Location is the URI of the new |  |  |
| resource which was created by the request. For 3xx (Redirection) |  |  |
| responses, the location SHOULD indicate the server's preferred URI |  |  |
| for automatic redirection to the resource. |  |  |
| The field value consists of a single URI-reference. When it has the |  | The field value consists of a single URI-reference. When it has the |
| form of a relative reference ([RFC3986], Section 4.2), the final |  | form of a relative reference ([RFC3986], Section 4.2), the final |
| value is computed by resolving it against the effective request URI |  | value is computed by resolving it against the effective request URI |
| ([RFC3986], Section 5). If the original URI, as navigated to by the |  | ([RFC3986], Section 5). |
| user agent, did contain a fragment identifier, and the final value |  |  |
| does not, then the original URI's fragment identifier is added to the |  |  |
| final value. |  |  |
| For example, the original URI "http://www.example.org/~tim", combined |  | For 201 (Created) responses, the Location value refers to the primary |
| with a field value given as: |  | resource created by the request. For 3xx (Redirection) responses, |
|  |  | the Location value refers to the preferred target resource for |
|  |  | automatically redirecting the request. |
| Location: /pub/WWW/People.html#tim |  | When Location is provided in a 3xx (Redirection) response and the URI |
|  |  | reference that the user agent used to generate the request target |
|  |  | contains a fragment identifier, the user agent SHOULD process the |
|  |  | redirection as if the Location field value inherits the original |
|  |  | fragment. In other words, if the Location does not have a fragment |
|  |  | component, the user agent SHOULD interpret the Location reference as |
|  |  | if it had the original reference's fragment. |
| would result in a final value of |  | For example, a GET request generated for the URI reference |
| "http://www.example.org/pub/WWW/People.html#tim" |  | "http://www.example.org/~tim" might result in a 303 (See Other) |
|  |  | response containing the header field: |
| An original URI "http://www.example.org/index.html#larry", combined |  | Location: /People.html#tim |
| with a field value given as: |  |  |
|  |  | which suggests that the user agent redirect to |
|  |  | "http://www.example.org/People.html#tim" |
|  |  | Likewise, a GET request generated for the URI reference |
|  |  | "http://www.example.org/index.html#larry" might result in a 301 |
|  |  | (Moved Permanently) response containing the header field: |
| Location: http://www.example.net/index.html |  | Location: http://www.example.net/index.html |
| would result in a final value of |  | which suggests that the user agent redirect to |
| "http://www.example.net/index.html#larry", preserving the original |  | "http://www.example.net/index.html#larry", preserving the original |
| fragment identifier. |  | fragment identifier. |
|  |  | There are circumstances in which a fragment identifier in a Location |
|  |  | value would not be appropriate. For example, the Location header |
|  |  | field in a 201 (Created) response is supposed to provide a URI that |
|  |  | is specific to the created resource. |
| Note: Some recipients attempt to recover from Location fields that |  | Note: Some recipients attempt to recover from Location fields that |
| are not valid URI references. This specification does not mandate |  | are not valid URI references. This specification does not mandate |
| or define such processing, but does allow it. |  | or define such processing, but does allow it for the sake of |
|  |  | robustness. |
| There are circumstances in which a fragment identifier in a Location |  |  |
| URI would not be appropriate. For instance, when it appears in a 201 |  |  |
| (Created) response, where the Location header field specifies the URI |  |  |
| for the entire created resource. |  |  |
| Note: The Content-Location header field (Section 3.1.4.2) differs |  | Note: The Content-Location header field (Section 3.1.4.2) differs |
| from Location in that the Content-Location identifies the most |  | from Location in that the Content-Location refers to the most |
| specific resource corresponding to the enclosed representation. |  | specific resource corresponding to the enclosed representation. |
| It is therefore possible for a response to contain header fields |  | It is therefore possible for a response to contain both the |
| for both Location and Content-Location. |  | Location and Content-Location header fields. |
| 8.1.3. Retry-After |  | 7.1.3. Retry-After |
| The header "Retry-After" field can be used with a 503 (Service |  | Servers send the "Retry-After" header field to indicate how long the |
| Unavailable) response to indicate how long the service is expected to |  | user agent ought to wait before making a follow-up request. When |
| be unavailable to the requesting client. This field MAY also be used |  | sent with a 503 (Service Unavailable) response, Retry-After indicates |
| with any 3xx (Redirection) response to indicate the minimum time the |  | how long the service is expected to be unavailable to the client. |
| user-agent is asked to wait before issuing the redirected request. |  | When sent with any 3xx (Redirection) response, Retry-After indicates |
|  |  | the minimum time that the user agent is asked to wait before issuing |
|  |  | the redirected request. |
| The value of this field can be either an HTTP-date or an integer |  | The value of this field can be either an HTTP-date or an integer |
| number of seconds (in decimal) after the time of the response. |  | number of seconds (in decimal) after the time of the response. |
| Retry-After = HTTP-date / delta-seconds |  | Retry-After = HTTP-date / delta-seconds |
| Time spans are non-negative decimal integers, representing time in |  | Time spans are non-negative decimal integers, representing time in |
| seconds. |  | seconds. |
| delta-seconds = 1*DIGIT |  | delta-seconds = 1*DIGIT |
| Two examples of its use are |  | Two examples of its use are |
| Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |  | Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |
| Retry-After: 120 |  | Retry-After: 120 |
| In the latter example, the delay is 2 minutes. |  | In the latter example, the delay is 2 minutes. |
| 8.2. Selected Representation Header Fields |  | 7.1.4. Vary |
| We use the term "selected representation" to refer to the the current |  | The "Vary" header field describes what parts of a request message, |
| representation of a target resource that would have been selected in |  | aside from the method and request target, might influence the origin |
| a successful response if the same request had used the method GET and |  | server's process for selecting and representing the response. The |
| excluded any conditional request header fields. |  | value consists of either a single asterisk ("*") or a list of header |
|  |  | field names (case-insensitive). |
| Additional header fields define metadata about the selected |  | Vary = "*" / 1#field-name |
| representation, which might differ from the representation included |  |  |
| in the message for responses to some state-changing methods. The |  |  |
| following header fields are defined as selected representation |  |  |
| metadata: |  |  |
| +-------------------+------------------------+ |  | A Vary field value of "*" signals that anything about the request |
| | Header Field Name | Defined in... | |  | might play a role in selecting the response representation, possibly |
| +-------------------+------------------------+ |  | including elements outside the message syntax (e.g., the client's |
| | ETag | Section 2.3 of [Part4] | |  | network address), and thus a recipient will not be able to determine |
| | Last-Modified | Section 2.2 of [Part4] | |  | whether this response is appropriate for a later request without |
| | Vary | Section 8.2.1 | |  | forwarding the request to the origin server. A proxy MUST NOT |
| +-------------------+------------------------+ |  | generate a Vary field with a "*" value. |
| 8.2.1. Vary |  | A Vary field value consisting of a comma-separated list of names |
|  |  | indicates that the named request header fields, known as the |
|  |  | selecting header fields, might have a role in selecting the |
|  |  | representation. The potential selecting header fields are not |
|  |  | limited to those defined by this specification. |
| The "Vary" header field conveys the set of header fields that were |  | For example, a response that contains |
| used to select the representation. |  |  |
| Caches use this information as part of determining whether a stored |  | Vary: accept-encoding, accept-language |
| response can be used to satisfy a given request (Section 4.3 of |  |  |
| [Part6]). |  |  |
| In uncacheable or stale responses, the Vary field value advises the |  | indicates that the origin server might have used the request's |
| user agent about the criteria that were used to select the |  | Accept-Encoding and Accept-Language fields (or lack thereof) as |
| representation. |  | determining factors while choosing the content for this response. |
| Vary = "*" / 1#field-name |  | An origin server might send Vary with a list of fields for two |
|  |  | purposes: |
| The set of header fields named by the Vary field value is known as |  | 1. To inform cache recipients that they MUST NOT use this response |
| the selecting header fields. |  | to satisfy a later request unless the later request has the same |
|  |  | values for the listed fields as the original request (Section 4.3 |
|  |  | of [Part6]). In other words, Vary expands the cache key required |
|  |  | to match a new request to the stored cache entry. |
| A server SHOULD include a Vary header field with any cacheable |  | 2. To inform user agent recipients that this response is subject to |
| response that is subject to proactive negotiation. Doing so allows a |  | content negotiation (Section 5.3) and that a different |
| cache to properly interpret future requests on that resource and |  | representation might be sent in a subsequent request if |
| informs the user agent about the presence of negotiation on that |  | additional parameters are provided in the listed header fields |
| resource. A server MAY include a Vary header field with a non- |  | (proactive negotiation). |
| cacheable response that is subject to proactive negotiation, since |  |  |
| this might provide the user agent with useful information about the |  |  |
| dimensions over which the response varies at the time of the |  |  |
| response. |  |  |
| A Vary field value of "*" signals that unspecified parameters not |  | An origin server SHOULD send a Vary header field when its algorithm |
| limited to the header fields (e.g., the network address of the |  | for selecting a representation varies based on aspects of the request |
| client), play a role in the selection of the response representation; |  | message other than the method and request target, unless the variance |
| therefore, a cache cannot determine whether this response is |  | cannot be crossed or the origin server has been deliberately |
| appropriate. A proxy MUST NOT generate the "*" value. |  | configured to prevent cache transparency. For example, there is no |
|  |  | need to send the Authorization field name in Vary because reuse |
|  |  | across users is constrained by the field definition (Section 4.1 of |
|  |  | [Part7]). Likewise, an origin server might use Cache-Control |
|  |  | directives (Section 7.2 of [Part6]) to supplant Vary if it considers |
|  |  | the variance less significant than the performance cost of Vary's |
|  |  | impact on caching. |
| The field-names given are not limited to the set of standard header |  | 7.2. Validator Header Fields |
| fields defined by this specification. Field names are case- |  |  |
| insensitive. |  |  |
| 8.3. Authentication Challenges |  | Validator header fields convey metadata about the selected |
|  |  | representation (Section 3). In responses to safe requests, validator |
|  |  | fields describe the selected representation chosen by the origin |
|  |  | server while handling the response. Note that, depending on the |
|  |  | status code semantics, the selected representation for a given |
|  |  | response is not necessarily the same as the representation enclosed |
|  |  | as response payload. |
|  |  | In a successful response to a state-changing request, validator |
|  |  | fields describe the new representation that has replaced the prior |
|  |  | selected representation as a result of processing the request. |
|  |  | For example, an ETag header field in a 201 response communicates the |
|  |  | entity-tag of the newly created resource's representation, so that it |
|  |  | can be used in later conditional requests to prevent the "lost |
|  |  | update" problem [Part4]. |
|  |  | +-------------------+------------------------+ |
|  |  | | Header Field Name | Defined in... | |
|  |  | +-------------------+------------------------+ |
|  |  | | ETag | Section 2.3 of [Part4] | |
|  |  | | Last-Modified | Section 2.2 of [Part4] | |
|  |  | +-------------------+------------------------+ |
|  |  | 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.4 of [Part7] | |
| | Proxy-Authenticate | Section 4.2 of [Part7] | |  | | Proxy-Authenticate | Section 4.2 of [Part7] | |
| +--------------------+------------------------+ |  | +--------------------+------------------------+ |
| 8.4. Informative |  | 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... | |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| | Accept-Ranges | Section 5.1 of [Part5] | |  | | Accept-Ranges | Section 2.3 of [Part5] | |
| | Allow | Section 8.4.1 | |  | | Allow | Section 7.4.1 | |
| | Server | Section 8.4.2 | |  | | Server | Section 7.4.2 | |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| 8.4.1. Allow |  | 7.4.1. Allow |
| The "Allow" header field lists the set of methods advertised as |  | The "Allow" header field lists the set of methods advertised as |
| supported by the target resource. The purpose of this field is |  | supported by the target resource. The purpose of this field is |
| strictly to inform the recipient of valid request methods associated |  | strictly to inform the recipient of valid request methods associated |
| with the resource. |  | with the resource. |
| Allow = #method |  | Allow = #method |
| Example of use: |  | Example of use: |
| Allow: GET, HEAD, PUT |  | Allow: GET, HEAD, PUT |
| The actual set of allowed methods is defined by the origin server at |  | The actual set of allowed methods is defined by the origin server at |
| the time of each request. |  | the time of each request. An origin server MUST generate an Allow |
|  |  | field in a 405 (Method Not Allowed) response and MAY do so in any |
|  |  | other response. An empty Allow field value indicates that the |
|  |  | resource allows no methods, which might occur in a 405 response if |
|  |  | the resource has been temporarily disabled by configuration. |
| A proxy MUST NOT modify the Allow header field -- it does not need to |  | A proxy MUST NOT modify the Allow header field -- it does not need to |
| understand all the methods specified in order to handle them |  | understand all of the indicated methods in order to handle them |
| according to the generic message handling rules. |  | according to the generic message handling rules. |
| 8.4.2. Server |  | 7.4.2. Server |
| The "Server" header field contains information about the software |  | The "Server" header field contains information about the software |
| used by the origin server to handle the request. |  | used by the origin server to handle the request, which is often used |
|  |  | by clients to help identify the scope of reported interoperability |
| The field can contain multiple product tokens (Section 4) and |  | problems, to work around or tailor requests to avoid particular |
| comments (Section 3.2 of [Part1]) identifying the server and any |  | server limitations, and for analytics regarding server or operating |
| significant subproducts. The product tokens are listed in order of |  | system use. An origin server MAY generate a Server field in its |
| their significance for identifying the application. |  | responses. |
| Server = product *( RWS ( product / comment ) ) |  | Server = product *( RWS ( product / comment ) ) |
|  |  | The Server field-value consists of one or more product identifiers, |
|  |  | each followed by zero or more comments (Section 3.2 of [Part1]), |
|  |  | which together identify the origin server software and its |
|  |  | significant subproducts. By convention, the product identifiers are |
|  |  | listed in decreasing order of their significance for identifying the |
|  |  | origin server software. Each product identifier consists of a name |
|  |  | and optional version, as defined in Section 5.5.3. |
| Example: |  | Example: |
| Server: CERN/3.0 libwww/2.17 |  | Server: CERN/3.0 libwww/2.17 |
| If the response is being forwarded through a proxy, the proxy |  | An origin server SHOULD NOT generate a Server field containing |
| application MUST NOT modify the Server header field. Instead, it |  | needlessly fine-grained detail and SHOULD limit the addition of |
| MUST include a Via field (as described in Section 5.7 of [Part1]). |  | subproducts by third parties. Overly long and detailed Server field |
|  |  | values increase response latency and potentially reveal internal |
| Note: Revealing the specific software version of the server might |  | implementation details that might make it (slightly) easier for |
| allow the server machine to become more vulnerable to attacks |  | attackers to find and exploit known security holes. |
| against software that is known to contain security holes. Server |  |  |
| implementers are encouraged to make this field a configurable |  |  |
| option. |  |  |
| 9. IANA Considerations |  | 8. IANA Considerations |
| 9.1. Method Registry |  | 8.1. Method Registry |
| The HTTP Method Registry defines the name space for the request |  | The HTTP Method Registry defines the name space for the request |
| method token (Section 5). The method registry is maintained at |  | method token (Section 4). The method registry is maintained at |
| <http://www.iana.org/assignments/http-methods>. |  | <http://www.iana.org/assignments/http-methods>. |
| 9.1.1. Procedure |  | 8.1.1. Procedure |
| HTTP method registrations MUST include the following fields: |  | HTTP method registrations MUST include the following fields: |
| o Method Name (see Section 5) |  | o Method Name (see Section 4) |
| o Safe ("yes" or "no", see Section 5.2.1) |  | o Safe ("yes" or "no", see Section 4.2.1) |
| o Idempotent ("yes" or "no", see Section 5.2.2) |  | o Idempotent ("yes" or "no", see Section 4.2.2) |
| o Pointer to specification text |  | o Pointer to specification text |
| Values to be added to this name space require IETF Review (see |  | Values to be added to this name space require IETF Review (see |
| [RFC5226], Section 4.1). |  | [RFC5226], Section 4.1). |
| 9.1.2. Considerations for New Methods |  | 8.1.2. Considerations for New Methods |
| Standardized methods are generic; that is, they are potentially |  | Standardized methods are generic; that is, they are potentially |
| applicable to any resource, not just one particular media type, kind |  | applicable to any resource, not just one particular media type, kind |
| of resource, or application. As such, it is preferred that new |  | of resource, or application. As such, it is preferred that new |
| methods be registered in a document that isn't specific to a single |  | methods be registered in a document that isn't specific to a single |
| application or data format, since orthogonal technologies deserve |  | application or data format, since orthogonal technologies deserve |
| orthogonal specification. |  | orthogonal specification. |
| Since message parsing (Section 3.3 of [Part1]) needs to be |  | Since message parsing (Section 3.3 of [Part1]) needs to be |
| independent of method semantics (aside from responses to HEAD), |  | independent of method semantics (aside from responses to HEAD), |
| definitions of new methods cannot change the parsing algorithm or |  | definitions of new methods cannot change the parsing algorithm or |
| prohibit the presence of a message body on either the request or the |  | prohibit the presence of a message body on either the request or the |
| response message. Definitions of new methods can specify that only a |  | response message. Definitions of new methods can specify that only a |
| zero-length message body is allowed by requiring a Content-Length |  | zero-length message body is allowed by requiring a Content-Length |
| header field with a value of "0". |  | header field with a value of "0". |
| New method definitions need to indicate whether they are safe |  | A new method definition needs to indicate whether it is safe |
| (Section 5.2.1), idempotent (Section 5.2.2), cacheable |  | (Section 4.2.1), idempotent (Section 4.2.2), cacheable |
| (Section 5.2.3), and what semantics are to be associated with the |  | (Section 4.2.3), what semantics are to be associated with the payload |
| payload body if any is present in the request. If a method is |  | body if any is present in the request, and what refinements the |
| cacheable, the method definition ought to describe how, and under |  | method makes to header field or status code semantics. If the new |
|  |  | method is cacheable, its definition ought to describe how, and under |
| what conditions, a cache can store a response and use it to satisfy a |  | what conditions, a cache can store a response and use it to satisfy a |
| subsequent request. |  | subsequent request. The new method ought to describe whether it can |
|  |  | be made conditional (Section 5.2) and, if so, how a server responds |
|  |  | when the condition is false. Likewise, if the new method might have |
|  |  | some use for partial response semantics ([Part5]), it ought to |
|  |  | document this too. |
| 9.1.3. Registrations |  | 8.1.3. Registrations |
| The HTTP Method Registry shall be populated with the registrations |  | The HTTP Method Registry shall be populated with the registrations |
| below: |  | below: |
| +---------+------+------------+---------------+ |  | +---------+------+------------+---------------+ |
| | Method | Safe | Idempotent | Reference | |  | | Method | Safe | Idempotent | Reference | |
| +---------+------+------------+---------------+ |  | +---------+------+------------+---------------+ |
| | CONNECT | no | no | Section 5.3.6 | |  | | CONNECT | no | no | Section 4.3.6 | |
| | DELETE | no | yes | Section 5.3.5 | |  | | DELETE | no | yes | Section 4.3.5 | |
| | GET | yes | yes | Section 5.3.1 | |  | | GET | yes | yes | Section 4.3.1 | |
| | HEAD | yes | yes | Section 5.3.2 | |  | | HEAD | yes | yes | Section 4.3.2 | |
| | OPTIONS | yes | yes | Section 5.3.7 | |  | | OPTIONS | yes | yes | Section 4.3.7 | |
| | POST | no | no | Section 5.3.3 | |  | | POST | no | no | Section 4.3.3 | |
| | PUT | no | yes | Section 5.3.4 | |  | | PUT | no | yes | Section 4.3.4 | |
| | TRACE | yes | yes | Section 5.3.8 | |  | | TRACE | yes | yes | Section 4.3.8 | |
| +---------+------+------------+---------------+ |  | +---------+------+------------+---------------+ |
| 9.2. Status Code Registry |  | 8.2. Status Code Registry |
| The HTTP Status Code Registry defines the name space for the response |  | The HTTP Status Code Registry defines the name space for the response |
| status-code token (Section 7). The status code registry is |  | status-code token (Section 6). The status code registry is |
| maintained at <http://www.iana.org/assignments/http-status-codes>. |  | maintained at <http://www.iana.org/assignments/http-status-codes>. |
| This section replaces the registration procedure for HTTP Status |  | This section replaces the registration procedure for HTTP Status |
| Codes previously defined in Section 7.1 of [RFC2817]. |  | Codes previously defined in Section 7.1 of [RFC2817]. |
| 9.2.1. Procedure |  | 8.2.1. Procedure |
| Values to be added to the HTTP status code name space require IETF |  | Values to be added to the HTTP status code name space require IETF |
| Review (see [RFC5226], Section 4.1). |  | Review (see [RFC5226], Section 4.1). |
| 9.2.2. Considerations for New Status Codes |  | 8.2.2. Considerations for New Status Codes |
| When it is necessary to express semantics for a response that are not |  | When it is necessary to express semantics for a response that are not |
| defined by current status codes, a new status code can be registered. |  | defined by current status codes, a new status code can be registered. |
| HTTP status codes are generic; they are potentially applicable to any |  |  |
| resource, not just one particular media type, "type" of resource, or |  | Status codes are generic; they are potentially applicable to any |
| application. As such, it is preferred that new status codes be |  | resource, not just one particular media type, kind of resource, or |
| registered in a document that isn't specific to a single application. |  | application of HTTP. As such, it is preferred that new status codes |
|  |  | be registered in a document that isn't specific to a single |
|  |  | application. |
| New status codes are required to fall under one of the categories |  | New status codes are required to fall under one of the categories |
| defined in Section 7. To allow existing parsers to properly handle |  | defined in Section 6. To allow existing parsers to process the |
| them, new status codes cannot disallow a payload, although they can |  | response message, new status codes cannot disallow a payload, |
| mandate a zero-length payload body. |  | although they can mandate a zero-length payload body. |
| A definition for a new status code ought to explain the request |  | Proposals for new status codes that are not yet widely deployed ought |
| conditions that produce a response containing that status code (e.g., |  | to avoid allocating a specific number for the code until there is |
| combinations of request header fields and/or method(s)) along with |  | clear consensus that it will be registered; instead, early drafts can |
| any dependencies on response header fields (e.g., what fields are |  | use a notation such as "4NN", or "3N0" .. "3N9", to indicate the |
| required and what fields can modify the semantics). A response that |  | class of the proposed status code(s) without consuming a number |
| can transfer a payload ought to specify expected cache behavior |  | prematurely. |
| (e.g., cacheability and freshness criteria, as described in [Part6]) |  |  |
| and whether the payload has any implied association with an |  |  |
| identified resource (Section 3.1.4.1). |  |  |
| 9.2.3. Registrations |  | The definition of a new status code ought to explain the request |
|  |  | conditions that would cause a response containing that status code |
|  |  | (e.g., combinations of request header fields and/or method(s)) along |
|  |  | with any dependencies on response header fields (e.g., what fields |
|  |  | are required, what fields can modify the semantics, and what header |
|  |  | field semantics are further refined when used with the new status |
|  |  | code). |
|  |  | The definition of a new status code ought to specify whether or not |
|  |  | it is cacheable. Note that all status codes can be cached if the |
|  |  | response they occur in has explicit freshness information; however, |
|  |  | status codes that are defined as being cacheable are allowed to be |
|  |  | cached without explicit freshness information. Likewise, the |
|  |  | definition of a status code can place constraints upon cache |
|  |  | behaviour. See [Part6] for more information. |
|  |  | Finally, the definition of a new status code ought to indicate |
|  |  | whether the payload has any implied association with an identified |
|  |  | resource (Section 3.1.4.1). |
|  |  | 8.2.3. Registrations |
| The HTTP Status Code Registry shall be updated with the registrations |  | The HTTP Status Code Registry shall be updated with the registrations |
| below: |  | below: |
| +-------+----------------------------------+----------------+ |  | +-------+-------------------------------+----------------+ |
| | Value | Description | Reference | |  | | Value | Description | Reference | |
| +-------+----------------------------------+----------------+ |  | +-------+-------------------------------+----------------+ |
| | 100 | Continue | Section 7.2.1 | |  | | 100 | Continue | Section 6.2.1 | |
| | 101 | Switching Protocols | Section 7.2.2 | |  | | 101 | Switching Protocols | Section 6.2.2 | |
| | 200 | OK | Section 7.3.1 | |  | | 200 | OK | Section 6.3.1 | |
| | 201 | Created | Section 7.3.2 | |  | | 201 | Created | Section 6.3.2 | |
| | 202 | Accepted | Section 7.3.3 | |  | | 202 | Accepted | Section 6.3.3 | |
| | 203 | Non-Authoritative Information | Section 7.3.4 | |  | | 203 | Non-Authoritative Information | Section 6.3.4 | |
| | 204 | No Content | Section 7.3.5 | |  | | 204 | No Content | Section 6.3.5 | |
| | 205 | Reset Content | Section 7.3.6 | |  | | 205 | Reset Content | Section 6.3.6 | |
| | 300 | Multiple Choices | Section 7.4.1 | |  | | 300 | Multiple Choices | Section 6.4.1 | |
| | 301 | Moved Permanently | Section 7.4.2 | |  | | 301 | Moved Permanently | Section 6.4.2 | |
| | 302 | Found | Section 7.4.3 | |  | | 302 | Found | Section 6.4.3 | |
| | 303 | See Other | Section 7.4.4 | |  | | 303 | See Other | Section 6.4.4 | |
| | 305 | Use Proxy | Section 7.4.5 | |  | | 305 | Use Proxy | Section 6.4.5 | |
| | 306 | (Unused) | Section 7.4.6 | |  | | 306 | (Unused) | Section 6.4.6 | |
| | 307 | Temporary Redirect | Section 7.4.7 | |  | | 307 | Temporary Redirect | Section 6.4.7 | |
| | 400 | Bad Request | Section 7.5.1 | |  | | 400 | Bad Request | Section 6.5.1 | |
| | 402 | Payment Required | Section 7.5.2 | |  | | 402 | Payment Required | Section 6.5.2 | |
| | 403 | Forbidden | Section 7.5.3 | |  | | 403 | Forbidden | Section 6.5.3 | |
| | 404 | Not Found | Section 7.5.4 | |  | | 404 | Not Found | Section 6.5.4 | |
| | 405 | Method Not Allowed | Section 7.5.5 | |  | | 405 | Method Not Allowed | Section 6.5.5 | |
| | 406 | Not Acceptable | Section 7.5.6 | |  | | 406 | Not Acceptable | Section 6.5.6 | |
| | 408 | Request Timeout | Section 7.5.7 | |  | | 408 | Request Timeout | Section 6.5.7 | |
| | 409 | Conflict | Section 7.5.8 | |  | | 409 | Conflict | Section 6.5.8 | |
| | 410 | Gone | Section 7.5.9 | |  | | 410 | Gone | Section 6.5.9 | |
| | 411 | Length Required | Section 7.5.10 | |  | | 411 | Length Required | Section 6.5.10 | |
| | 413 | Request Representation Too Large | Section 7.5.11 | |  | | 413 | Payload Too Large | Section 6.5.11 | |
| | 414 | URI Too Long | Section 7.5.12 | |  | | 414 | URI Too Long | Section 6.5.12 | |
| | 415 | Unsupported Media Type | Section 7.5.13 | |  | | 415 | Unsupported Media Type | Section 6.5.13 | |
| | 417 | Expectation Failed | Section 7.5.14 | |  | | 417 | Expectation Failed | Section 6.5.14 | |
| | 426 | Upgrade Required | Section 7.5.15 | |  | | 426 | Upgrade Required | Section 6.5.15 | |
| | 500 | Internal Server Error | Section 7.6.1 | |  | | 500 | Internal Server Error | Section 6.6.1 | |
| | 501 | Not Implemented | Section 7.6.2 | |  | | 501 | Not Implemented | Section 6.6.2 | |
| | 502 | Bad Gateway | Section 7.6.3 | |  | | 502 | Bad Gateway | Section 6.6.3 | |
| | 503 | Service Unavailable | Section 7.6.4 | |  | | 503 | Service Unavailable | Section 6.6.4 | |
| | 504 | Gateway Timeout | Section 7.6.5 | |  | | 504 | Gateway Timeout | Section 6.6.5 | |
| | 505 | HTTP Version Not Supported | Section 7.6.6 | |  | | 505 | HTTP Version Not Supported | Section 6.6.6 | |
| +-------+----------------------------------+----------------+ |  | +-------+-------------------------------+----------------+ |
| 9.3. Header Field Registry |  | 8.3. Header Field Registry |
| HTTP header fields are registered within the Message Header Field |  | HTTP header fields are registered within the Message Header Field |
| Registry located at <http://www.iana.org/assignments/message-headers/ |  | Registry located at <http://www.iana.org/assignments/message-headers/ |
| message-header-index.html>, as defined by [RFC3864]. |  | message-header-index.html>, as defined by [BCP90]. |
| 9.3.1. Considerations for New Header Fields |  | 8.3.1. Considerations for New Header Fields |
| Header fields are key:value pairs that can be used to communicate |  | Header fields are key:value pairs that can be used to communicate |
| data about the message, its payload, the target resource, or the |  | data about the message, its payload, the target resource, or the |
| connection (i.e., control data). See Section 3.2 of [Part1] for a |  | connection (i.e., control data). See Section 3.2 of [Part1] for a |
| general definition of header field syntax in HTTP messages. |  | general definition of header field syntax in HTTP messages. |
| The requirements for header field names are defined in Section 4.1 of |  | The requirements for header field names are defined in [BCP90]. |
| [RFC3864]. Authors of specifications defining new fields are advised |  | Authors of specifications defining new fields are advised to keep the |
| to keep the name as short as practical, and not to prefix them with |  | name as short as practical and to not prefix the name with "X-" |
| "X-" if they are to be registered (either immediately or in the |  | unless the header field will never be used on the Internet. (The |
| future). |  | "x-" prefix idiom has been extensively misused in practice; it was |
|  |  | intended to only be used as a mechanism for avoiding name collisions |
|  |  | inside proprietary software or intranet processing, since the prefix |
|  |  | would ensure that private names never collide with a newly registered |
|  |  | Internet name.) |
| 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 Appendix B of |  | ABNF ([RFC5234]), using the extension defined in Appendix B of |
| [Part1] as necessary, and are usually constrained to the range of |  | [Part1] as necessary, and are usually constrained to the range of |
| ASCII characters. Header fields needing a greater range of |  | ASCII characters. Header fields needing a greater range of |
| characters can use an encoding such as the one defined in [RFC5987]. |  | characters can use an encoding such as the one defined in [RFC5987]. |
|  |  | Leading and trailing whitespace in raw field values is removed upon |
|  |  | field parsing (Section 3.2.4 of [Part1]). Field definitions where |
|  |  | leading or trailing whitespace in values is significant will have to |
|  |  | use a container syntax such as quoted-string. |
| 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's payload. Typically, components that might contain a |  | field-value. Typically, components that might contain a comma are |
| comma are protected with double-quotes using the quoted-string ABNF |  | protected with double-quotes using the quoted-string ABNF production |
| production (Section 3.2.4 of [Part1]). |  | (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 75, line 9 |  | skipping to change at page 77, line 17 |
| example, see the notes on parameter handling for media types in |  | example, see the notes on parameter handling for media types in |
| Section 3.1.1.1). |  | Section 3.1.1.1). |
| Authors of specifications defining new header fields are advised to |  | Authors of specifications defining new header fields are advised to |
| consider documenting: |  | consider documenting: |
| o Whether the field is a single value, or whether it can be a list |  | o Whether the field is a single value, or whether it can be a list |
| (delimited by commas; see Section 3.2 of [Part1]). |  | (delimited by commas; see Section 3.2 of [Part1]). |
| If it does not use the list syntax, document how to treat messages |  | If it does not use the list syntax, document how to treat messages |
| where the header field occurs multiple times (a sensible default |  | where the field occurs multiple times (a sensible default would be |
| would be to ignore the header field, but this might not always be |  | to ignore the field, but this might not always be the right |
| the right choice). |  | choice). |
| Note that intermediaries and software libraries might combine |  | Note that intermediaries and software libraries might combine |
| multiple header field instances into a single one, despite the |  | multiple header field instances into a single one, despite the |
| header field not allowing this. A robust format enables |  | field's definition not allowing the list syntax. A robust format |
| recipients to discover these situations (good example: "Content- |  | enables recipients to discover these situations (good example: |
| Type", as the comma can only appear inside quoted strings; bad |  | "Content-Type", as the comma can only appear inside quoted |
| example: "Location", as a comma can occur inside a URI). |  | strings; bad example: "Location", as a comma can occur inside a |
|  |  | URI). |
| o Under what conditions the header field can be used; e.g., only in |  | o Under what conditions the header field can be used; e.g., only in |
| responses or requests, in all messages, only on responses to a |  | responses or requests, in all messages, only on responses to a |
| particular request method. |  | particular request method, etc. |
|  |  | o Whether the field semantics are further refined by the context, |
|  |  | such as by existing request methods or status codes. |
| o Whether it is appropriate to list the field-name in the Connection |  | o Whether it is appropriate to list the field-name in the Connection |
| header field (i.e., if the header field is to be hop-by-hop, see |  | header field (i.e., if the header field is to be hop-by-hop; see |
| Section 6.1 of [Part1]). |  | Section 6.1 of [Part1]). |
| o Under what conditions intermediaries are allowed to modify the |  | o Under what conditions intermediaries are allowed to insert, |
| header field's value, insert or delete it. |  | delete, or modify the field's value. |
| o How the header field might interact with caching (see [Part6]). |  | o How the header field might interact with caching (see [Part6]). |
| 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. |
| 9.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 6.3.2 | |  | | Accept | http | standard | Section 5.3.2 | |
| | Accept-Charset | http | standard | Section 6.3.3 | |  | | Accept-Charset | http | standard | Section 5.3.3 | |
| | Accept-Encoding | http | standard | Section 6.3.4 | |  | | Accept-Encoding | http | standard | Section 5.3.4 | |
| | Accept-Language | http | standard | Section 6.3.5 | |  | | Accept-Language | http | standard | Section 5.3.5 | |
| | Allow | http | standard | Section 8.4.1 | |  | | Allow | http | standard | Section 7.4.1 | |
| | Content-Encoding | http | standard | Section 3.1.2.2 | |  | | Content-Encoding | http | standard | Section 3.1.2.2 | |
| | Content-Language | http | standard | Section 3.1.3.2 | |  | | Content-Language | http | standard | Section 3.1.3.2 | |
| | Content-Location | http | standard | Section 3.1.4.2 | |  | | Content-Location | http | standard | Section 3.1.4.2 | |
| | Content-Type | http | standard | Section 3.1.1.5 | |  | | Content-Type | http | standard | Section 3.1.1.5 | |
| | Date | http | standard | Section 8.1.1.2 | |  | | Date | http | standard | Section 7.1.1.2 | |
| | Expect | http | standard | Section 6.1.2 | |  | | Expect | http | standard | Section 5.1.1 | |
| | From | http | standard | Section 6.5.1 | |  | | From | http | standard | Section 5.5.1 | |
| | Location | http | standard | Section 8.1.2 | |  | | Location | http | standard | Section 7.1.2 | |
| | MIME-Version | http | standard | Appendix A.1 | |  | | MIME-Version | http | standard | Appendix A.1 | |
| | Max-Forwards | http | standard | Section 6.1.1 | |  | | Max-Forwards | http | standard | Section 5.1.2 | |
| | Referer | http | standard | Section 6.5.2 | |  | | Referer | http | standard | Section 5.5.2 | |
| | Retry-After | http | standard | Section 8.1.3 | |  | | Retry-After | http | standard | Section 7.1.3 | |
| | Server | http | standard | Section 8.4.2 | |  | | Server | http | standard | Section 7.4.2 | |
| | User-Agent | http | standard | Section 6.5.3 | |  | | User-Agent | http | standard | Section 5.5.3 | |
| | Vary | http | standard | Section 8.2.1 | |  | | Vary | http | standard | Section 7.1.4 | |
| +-------------------+----------+----------+-----------------+ |  | +-------------------+----------+----------+-----------------+ |
| The change controller for the above registrations is: "IETF |  | The change controller for the above registrations is: "IETF |
| (iesg@ietf.org) - Internet Engineering Task Force". |  | (iesg@ietf.org) - Internet Engineering Task Force". |
| 9.4. Content Coding Registry |  | 8.4. Content Coding Registry |
| The HTTP Content Coding Registry defines the name space for content |  | The HTTP Content Coding Registry defines the name space for content |
| coding names (Section 4.2 of [Part1]). The content coding registry |  | coding names (Section 4.2 of [Part1]). The content coding registry |
| is maintained at <http://www.iana.org/assignments/http-parameters>. |  | is maintained at <http://www.iana.org/assignments/http-parameters>. |
| 9.4.1. Procedure |  | 8.4.1. Procedure |
| Content Coding registrations MUST include the following fields: |  | Content Coding registrations MUST include the following fields: |
| o Name |  | o Name |
| o Description |  | o Description |
| o Pointer to specification text |  | o Pointer to specification text |
| Names of content codings MUST NOT overlap with names of transfer |  | Names of content codings MUST NOT overlap with names of transfer |
| codings (Section 4 of [Part1]), unless the encoding transformation is |  | codings (Section 4 of [Part1]), unless the encoding transformation is |
| identical (as is the case for the compression codings defined in |  | identical (as is the case for the compression codings defined in |
| Section 4.2 of [Part1]). |  | Section 4.2 of [Part1]). |
| Values to be added to this name space require IETF Review (see |  | Values to be added to this name space require IETF Review (see |
| Section 4.1 of [RFC5226]), and MUST conform to the purpose of content |  | Section 4.1 of [RFC5226]), and MUST conform to the purpose of content |
| coding defined in this section. |  | coding defined in this section. |
| skipping to change at page 77, line 9 |  | skipping to change at page 79, line 15 |
| Names of content codings MUST NOT overlap with names of transfer |  | Names of content codings MUST NOT overlap with names of transfer |
| codings (Section 4 of [Part1]), unless the encoding transformation is |  | codings (Section 4 of [Part1]), unless the encoding transformation is |
| identical (as is the case for the compression codings defined in |  | identical (as is the case for the compression codings defined in |
| Section 4.2 of [Part1]). |  | Section 4.2 of [Part1]). |
| Values to be added to this name space require IETF Review (see |  | Values to be added to this name space require IETF Review (see |
| Section 4.1 of [RFC5226]), and MUST conform to the purpose of content |  | Section 4.1 of [RFC5226]), and MUST conform to the purpose of content |
| coding defined in this section. |  | coding defined in this section. |
| 9.4.2. Registrations |  | 8.4.2. Registrations |
| The HTTP Content Codings Registry shall be updated with the |  | The HTTP Content Codings Registry shall be updated with the |
| registrations below: |  | registrations below: |
| +----------+----------------------------------------+---------------+ |  | +----------+----------------------------------------+---------------+ |
| | Name | Description | Reference | |  | | Name | Description | Reference | |
| +----------+----------------------------------------+---------------+ |  | +----------+----------------------------------------+---------------+ |
| | compress | UNIX "compress" program method | Section 4.2.1 | |  | | compress | UNIX "compress" program method | Section 4.2.1 | |
| | | | of [Part1] | |  | | | | of [Part1] | |
| | deflate | "deflate" compression mechanism | Section 4.2.2 | |  | | deflate | "deflate" compression mechanism | Section 4.2.2 | |
| | | ([RFC1951]) used inside the "zlib" | of [Part1] | |  | | | ([RFC1951]) used inside the "zlib" | of [Part1] | |
| | | data format ([RFC1950]) | | |  | | | data format ([RFC1950]) | | |
| | gzip | Same as GNU zip [RFC1952] | Section 4.2.3 | |  | | gzip | Same as GNU zip [RFC1952] | Section 4.2.3 | |
| | | | of [Part1] | |  | | | | of [Part1] | |
| | identity | reserved (synonym for "no encoding" in | Section 6.3.4 | |  | | identity | reserved (synonym for "no encoding" in | Section 5.3.4 | |
| | | Accept-Encoding header field) | | |  | | | Accept-Encoding header field) | | |
| +----------+----------------------------------------+---------------+ |  | +----------+----------------------------------------+---------------+ |
| 10. Security Considerations |  | 9. Security Considerations |
| This section is meant to inform application developers, information |  |  |
| providers, and users of the security limitations in HTTP/1.1 as |  |  |
| described by this document. The discussion does not include |  |  |
| definitive solutions to the problems revealed, though it does make |  |  |
| some suggestions for reducing security risks. |  |  |
| 10.1. Transfer of Sensitive Information |  |  |
| Like any generic data transfer protocol, HTTP cannot regulate the |  |  |
| content of the data that is transferred, nor is there any a priori |  |  |
| method of determining the sensitivity of any particular piece of |  |  |
| information within the context of any given request. Therefore, |  |  |
| applications SHOULD supply as much control over this information as |  |  |
| possible to the provider of that information. Four header fields are |  |  |
| worth special mention in this context: Server, Via, Referer and From. |  |  |
| Revealing the specific software version of the server might allow the |  |  |
| server machine to become more vulnerable to attacks against software |  |  |
| that is known to contain security holes. Implementers SHOULD make |  |  |
| the Server header field a configurable option. |  |  |
| Proxies which serve as a portal through a network firewall SHOULD |  |  |
| take special precautions regarding the transfer of header information |  |  |
| that identifies the hosts behind the firewall. In particular, they |  |  |
| SHOULD remove, or replace with sanitized versions, any Via fields |  |  |
| generated behind the firewall. |  |  |
| The Referer header field allows reading patterns to be studied and |  | This section is meant to inform developers, information providers, |
| reverse links drawn. Although it can be very useful, its power can |  | and users of known security concerns relevant to HTTP/1.1 semantics |
| be abused if user details are not separated from the information |  | and its use for transferring information over the Internet. |
| contained in the Referer. Even when the personal information has |  |  |
| been removed, the Referer header field might indicate a private |  |  |
| document's URI whose publication would be inappropriate. |  |  |
| The information sent in the From field might conflict with the user's |  | 9.1. Attacks Based On File and Path Names |
| privacy interests or their site's security policy, and hence it |  |  |
| SHOULD NOT be transmitted without the user being able to disable, |  |  |
| enable, and modify the contents of the field. The user MUST be able |  |  |
| to set the contents of this field within a user preference or |  |  |
| application defaults configuration. |  |  |
| We suggest, though do not require, that a convenient toggle interface |  | Origin servers frequently make use of their local file system to |
| be provided for the user to enable or disable the sending of From and |  | manage the mapping from effective request URI to resource |
| Referer information. |  | representations. Implementors need to be aware that most file |
|  |  | 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, folders, or directories that have special significance to the |
|  |  | system. |
| The User-Agent (Section 6.5.3) or Server (Section 8.4.2) header |  | For example, UNIX, Microsoft Windows, and other operating systems use |
| fields can sometimes be used to determine that a specific client or |  | ".." as a path component to indicate a directory level above the |
| server has a particular security hole which might be exploited. |  | current one, and use specially named paths or file names to send data |
| Unfortunately, this same information is often used for other valuable |  | to system devices. Similar naming conventions might exist within |
| purposes for which HTTP currently has no better mechanism. |  | other types of storage systems. Likewise, local storage systems have |
|  |  | an annoying tendency to prefer user-friendliness over security when |
|  |  | handling invalid or unexpected characters, recomposition of |
|  |  | decomposed characters, and case-normalization of case-insensitive |
|  |  | names. |
| Furthermore, the User-Agent header field might contain enough entropy |  | Attacks based on such special names tend to focus on either denial of |
| to be used, possibly in conjunction with other material, to uniquely |  | service (e.g., telling the server to read from a COM port) or |
| identify the user. |  | disclosure of configuration and source files that are not meant to be |
|  |  | served. |
| Some request methods, like TRACE (Section 5.3.8), expose information |  | 9.2. Personal Information |
| that was sent in request header fields within the body of their |  |  |
| response. Clients SHOULD be careful with sensitive information, like |  |  |
| Cookies, Authorization credentials, and other header fields that |  |  |
| might be used to collect data from the client. |  |  |
| 10.2. Encoding Sensitive Information in URIs |  | Clients are often privy to large amounts of personal information, |
|  |  | including both information provided by the user to interact with |
|  |  | resources (e.g., the user's name, location, mail address, passwords, |
|  |  | encryption keys, etc.) and information about the user's browsing |
|  |  | activity over time (e.g., history, bookmarks, etc.). Implementations |
|  |  | need to prevent unintentional leakage of personal information. |
| Because the source of a link might be private information or might |  | 9.3. Sensitive Information in URIs |
| reveal an otherwise private information source, it is strongly |  |  |
| recommended that the user be able to select whether or not the |  |  |
| Referer field is sent. For example, a browser client could have a |  |  |
| toggle switch for browsing openly/anonymously, which would |  |  |
| respectively enable/disable the sending of Referer and From |  |  |
| information. |  |  |
| Clients SHOULD NOT include a Referer header field in a (non-secure) |  | URIs are intended to be shared, not secured, even when they identify |
| HTTP request if the referring page was transferred with a secure |  | secure resources. URIs are often shown on displays, added to |
| protocol. |  | templates when a page is printed, and stored in a variety of |
|  |  | unprotected bookmark lists. It is therefore unwise to include |
|  |  | information within a URI that is sensitive, personally identifiable, |
|  |  | or a risk to disclose. |
| Authors of services SHOULD NOT use 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- |
| target. Many existing servers, proxies, and user agents log or |  | target. Many existing servers, proxies, and user agents log or |
| display the request-target in places where it might be visible to |  | display the request-target in places where it might be visible to |
| third parties. Such services can use POST-based form submission |  | third parties. Such services ought to use POST-based form submission |
| instead. |  | instead. |
| 10.3. Location Header Fields: Spoofing and Information Leakage |  | Since the Referer header field tells a target site about the context |
|  |  | that resulted in a request, it has the potential to reveal |
|  |  | information about the user's immediate browsing history and any |
|  |  | personal information that might be found in the referring resource's |
|  |  | URI. Limitations on Referer are described in Section 5.5.2 to |
|  |  | address some of its security considerations. |
| If a single server supports multiple organizations that do not trust |  | 9.4. Product Information |
| one another, then it MUST check the values of Location and Content- |  |  |
| Location header fields in responses that are generated under control |  |  |
| of said organizations to make sure that they do not attempt to |  |  |
| invalidate resources over which they have no authority. |  |  |
| Furthermore, appending the fragment identifier from one URI to |  | The User-Agent (Section 5.5.3), Via (Section 5.7.1 of [Part1]), and |
| another one obtained from a Location header field might leak |  | Server (Section 7.4.2) header fields often reveal information about |
| confidential information to the target server -- although the |  | the respective sender's software systems. In theory, this can make |
| fragment identifier is not transmitted in the final request, it might |  | it easier for an attacker to exploit known security holes; in |
| be visible to the user agent through other means, such as scripting. |  | practice, attackers tend to try all potential holes regardless of the |
|  |  | apparent software versions being used. |
| 10.4. Security Considerations for CONNECT |  | Proxies that serve as a portal through a network firewall ought to |
|  |  | take special precautions regarding the transfer of header information |
|  |  | that might identify hosts behind the firewall. The Via header field |
|  |  | allows intermediaries to replace sensitive machine names with |
|  |  | pseudonyms. |
| Since tunneled data is opaque to the proxy, there are additional |  | 9.5. Fragment after Redirects |
| risks to tunneling to other well-known or reserved ports. A HTTP |  |  |
| client CONNECTing to port 25 could relay spam via SMTP, for example. |  |  |
| As such, proxies SHOULD restrict CONNECT access to a small number of |  |  |
| known ports. |  |  |
| 10.5. Privacy Issues Connected to Accept Header Fields |  | 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. |
| Accept header fields can reveal information about the user to all |  | 9.6. Browser Fingerprinting |
| servers which are accessed. The Accept-Language header field in |  |  |
| particular can reveal information the user would consider to be of a |  |  |
| private nature, because the understanding of particular languages is |  |  |
| often strongly correlated to the membership of a particular ethnic |  |  |
| group. User agents which offer the option to configure the contents |  |  |
| of an Accept-Language header field to be sent in every request are |  |  |
| strongly encouraged to let the configuration process include a |  |  |
| message which makes the user aware of the loss of privacy involved. |  |  |
| An approach that limits the loss of privacy would be for a user agent |  | Browser fingerprinting is a set of techniques for identifying a |
| to omit the sending of Accept-Language header fields by default, and |  | specific user agent over time through its unique set of |
| to ask the user whether or not to start sending Accept-Language |  | characteristics. These characteristics might include information |
| header fields to a server if it detects, by looking for any Vary |  | related to its TCP behavior, feature capabilities, and scripting |
| header fields generated by the server, that such sending could |  | environment, though of particular interest here is the set of unique |
| improve the quality of service. |  | characteristics that might be communicated via HTTP. Fingerprinting |
|  |  | is considered a privacy concern because it enables tracking of a user |
|  |  | agent's behavior over time without the corresponding controls that |
|  |  | the user might have over other forms of data collection (e.g., |
|  |  | cookies). Many general-purpose user agents (i.e., Web browsers) have |
|  |  | taken steps to reduce their fingerprints. |
| Elaborate user-customized accept header fields sent in every request, |  | There are a number of request header fields that might reveal |
| in particular if these include quality values, can be used by servers |  | information to servers that is sufficiently unique to enable |
| as relatively reliable and long-lived user identifiers. Such user |  | fingerprinting. The From header field is the most obvious, though it |
| identifiers would allow content providers to do click-trail tracking, |  | is expected that From will only be sent when self-identification is |
| and would allow collaborating content providers to match cross-server |  | desired by the user. Likewise, Cookie header fields are deliberately |
| click-trails or form submissions of individual users. Note that for |  | designed to enable re-identification, so we can assume that |
| many users not behind a proxy, the network address of the host |  | fingerprinting concerns only apply to situations where cookies are |
| running the user agent will also serve as a long-lived user |  | disabled or restricted by browser configuration. |
| identifier. In environments where proxies are used to enhance |  |  |
| privacy, user agents ought to be conservative in offering accept |  |  |
| header field configuration options to end users. As an extreme |  |  |
| privacy measure, proxies could filter the accept header fields in |  |  |
| relayed requests. General purpose user agents which provide a high |  |  |
| degree of header field configurability SHOULD warn users about the |  |  |
| loss of privacy which can be involved. |  |  |
| 11. Acknowledgments |  | The User-Agent header field might contain enough information to |
|  |  | uniquely identify a specific device, usually when combined with other |
|  |  | characteristics, particularly if the user agent sends excessive |
|  |  | details about the user's system or extensions. However, the source |
|  |  | of unique information that is least expected by users is proactive |
|  |  | negotiation (Section 5.3), including the Accept, Accept-Charset, |
|  |  | Accept-Encoding, and Accept-Language header fields. |
|  |  | In addition to the fingerprinting concern, detailed use of the |
|  |  | Accept-Language header field can reveal information the user might |
|  |  | consider to be of a private nature, because the understanding of |
|  |  | particular languages is often strongly correlated to membership in a |
|  |  | particular ethnic group. An approach that limits such loss of |
|  |  | privacy would be for a user agent to omit the sending of Accept- |
|  |  | Language except for sites that have been whitelisted, perhaps via |
|  |  | interaction after detecting a Vary header field that would indicate |
|  |  | language negotiation might be useful. |
|  |  | In environments where proxies are used to enhance privacy, user |
|  |  | agents ought to be conservative in sending proactive negotiation |
|  |  | header fields. General-purpose user agents that provide a high |
|  |  | degree of header field configurability ought to inform users about |
|  |  | the loss of privacy that might result if too much detail is provided. |
|  |  | As an extreme privacy measure, proxies could filter the proactive |
|  |  | negotiation header fields in relayed requests. |
|  |  | 10. Acknowledgments |
| See Section 9 of [Part1]. |  | See Section 9 of [Part1]. |
| 12. References |  | 11. References |
| 12.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-21 (work in |  | Routing", draft-ietf-httpbis-p1-messaging-22 (work in |
| progress), October 2012. |  | progress), February 2013. |
| [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-21 (work in |  | draft-ietf-httpbis-p4-conditional-22 (work in |
| progress), October 2012. |  | progress), February 2013. |
| [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-21 (work in |  | Requests", draft-ietf-httpbis-p5-range-22 (work in |
| progress), October 2012. |  | progress), February 2013. |
| [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-21 (work in progress), |  | draft-ietf-httpbis-p6-cache-22 (work in progress), |
| October 2012. |  | February 2013. |
| [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-21 (work in progress), |  | draft-ietf-httpbis-p7-auth-22 (work in progress), |
| October 2012. |  | February 2013. |
| [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |  | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |
| Format Specification version 3.3", RFC 1950, May 1996. |  | Format Specification version 3.3", RFC 1950, May 1996. |
| [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |  | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |
| Specification version 1.3", RFC 1951, May 1996. |  | Specification version 1.3", RFC 1951, May 1996. |
| [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and |  | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and |
| G. Randers-Pehrson, "GZIP file format specification |  | G. Randers-Pehrson, "GZIP file format specification |
| version 4.3", RFC 1952, May 1996. |  | version 4.3", RFC 1952, May 1996. |
| skipping to change at page 81, line 46 |  | skipping to change at page 84, line 6 |
| Language Tags", BCP 47, RFC 4647, September 2006. |  | Language Tags", BCP 47, RFC 4647, September 2006. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |
| Syntax Specifications: ABNF", STD 68, RFC 5234, |  | Syntax Specifications: ABNF", STD 68, RFC 5234, |
| January 2008. |  | January 2008. |
| [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for |  | [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for |
| Identifying Languages", BCP 47, RFC 5646, |  | Identifying Languages", BCP 47, RFC 5646, |
| September 2009. |  | September 2009. |
| 12.2. Informative References |  | [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in |
|  |  | Internationalization in the IETF", BCP 166, RFC 6365, |
|  |  | September 2011. |
|  |  | 11.2. Informative References |
|  |  | [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type |
|  |  | Specifications and Registration Procedures", BCP 13, |
|  |  | RFC 6838, January 2013. |
|  |  | [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
|  |  | Procedures for Message Header Fields", BCP 90, |
|  |  | RFC 3864, September 2004. |
| [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", Doctoral |
| Dissertation, University of California, Irvine , |  | Dissertation, University of California, Irvine , |
| September 2000, |  | September 2000, |
| <http://roy.gbiv.com/pubs/dissertation/top.htm>. |  | <http://roy.gbiv.com/pubs/dissertation/top.htm>. |
| [RFC1123] Braden, R., "Requirements for Internet Hosts - |  | [RFC1305] Mills, D., "Network Time Protocol (Version 3) |
| Application and Support", STD 3, RFC 1123, |  | Specification, Implementation", RFC 1305, March 1992. |
| October 1989. |  |  |
| [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. |
| [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and |  | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and |
| T. Berners-Lee, "Hypertext Transfer Protocol -- |  | T. Berners-Lee, "Hypertext Transfer Protocol -- |
| HTTP/1.1", RFC 2068, January 1997. |  | HTTP/1.1", RFC 2068, January 1997. |
| [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, |  |  |
| February 1997. |  |  |
| [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and |  |  |
| Languages", BCP 18, RFC 2277, January 1998. |  |  |
| [RFC2295] Holtman, K. and A. Mutz, "Transparent Content |  | [RFC2295] Holtman, K. and A. Mutz, "Transparent Content |
| Negotiation in HTTP", RFC 2295, March 1998. |  | Negotiation in HTTP", RFC 2295, March 1998. |
| [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ |  | [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ |
| form-data", RFC 2388, August 1998. |  | form-data", RFC 2388, August 1998. |
| [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, |  | [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, |
| "MIME Encapsulation of Aggregate Documents, such as |  | "MIME Encapsulation of Aggregate Documents, such as |
| HTML (MHTML)", RFC 2557, March 1999. |  | HTML (MHTML)", RFC 2557, March 1999. |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| [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. |
| [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO |  | [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration |
| 10646", STD 63, RFC 3629, November 2003. |  | Procedures", BCP 19, RFC 2978, October 2000. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  |  |
| Procedures for Message Header Fields", BCP 90, |  |  |
| RFC 3864, September 2004. |  |  |
| [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications |  |  |
| and Registration Procedures", BCP 13, RFC 4288, |  |  |
| December 2005. |  |  |
| [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. |
| [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. |
| [RFC5987] Reschke, J., "Character Set and Language Encoding for |  | [RFC5987] Reschke, J., "Character Set and Language Encoding for |
| Hypertext Transfer Protocol (HTTP) Header Field |  | Hypertext Transfer Protocol (HTTP) Header Field |
| Parameters", RFC 5987, August 2010. |  | Parameters", RFC 5987, August 2010. |
| [RFC6151] Turner, S. and L. Chen, "Updated Security |  | [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. |
| Considerations for the MD5 Message-Digest and the HMAC- |  |  |
| MD5 Algorithms", RFC 6151, March 2011. |  | [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, |
|  |  | April 2011. |
| [RFC6266] Reschke, J., "Use of the Content-Disposition Header |  | [RFC6266] Reschke, J., "Use of the Content-Disposition Header |
| Field in the Hypertext Transfer Protocol (HTTP)", |  | Field in the Hypertext Transfer Protocol (HTTP)", |
| RFC 6266, June 2011. |  | RFC 6266, June 2011. |
| [status-308] Reschke, J., "The Hypertext Transfer Protocol (HTTP) |  | [status-308] Reschke, J., "The Hypertext Transfer Protocol (HTTP) |
| Status Code 308 (Permanent Redirect)", |  | Status Code 308 (Permanent Redirect)", |
| draft-reschke-http-status-308-07 (work in progress), |  | draft-reschke-http-status-308-07 (work in progress), |
| March 2012. |  | March 2012. |
| Appendix A. Differences between HTTP and MIME |  | Appendix A. Differences between HTTP and MIME |
| HTTP/1.1 uses many of the constructs defined for Internet Mail |  | HTTP/1.1 uses many of the constructs defined for the Internet Message |
| ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME |  | Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME) |
| [RFC2045]) to allow a message body to be transmitted in an open |  | [RFC2045] to allow a message body to be transmitted in an open |
| variety of representations and with extensible mechanisms. However, |  | variety of representations and with extensible header fields. |
| RFC 2045 discusses mail, and HTTP has a few features that are |  | However, RFC 2045 is focused only on email; applications of HTTP have |
| different from those described in MIME. These differences were |  | many characteristics that differ from email, and hence HTTP has |
| carefully chosen to optimize performance over binary connections, to |  | features that differ from MIME. These differences were carefully |
| allow greater freedom in the use of new media types, to make date |  | chosen to optimize performance over binary connections, to allow |
|  |  | greater freedom in the use of new media types, to make date |
| comparisons easier, and to acknowledge the practice of some early |  | comparisons easier, and to acknowledge the practice of some early |
| HTTP servers and clients. |  | HTTP servers and clients. |
| This appendix describes specific areas where HTTP differs from MIME. |  | This appendix describes specific areas where HTTP differs from MIME. |
| Proxies and gateways to strict MIME environments SHOULD be aware of |  | Proxies and gateways to and from strict MIME environments need to be |
| these differences and provide the appropriate conversions where |  | aware of these differences and provide the appropriate conversions |
| necessary. Proxies and gateways from MIME environments to HTTP also |  | where necessary. |
| need to be aware of the differences because some conversions might be |  |  |
| required. |  |  |
| A.1. MIME-Version |  | A.1. MIME-Version |
| HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages |  | HTTP is not a MIME-compliant protocol. However, messages can include |
| MAY include a single MIME-Version header field to indicate what |  | a single MIME-Version header field to indicate what version of the |
| version of the MIME protocol was used to construct the message. Use |  | MIME protocol was used to construct the message. Use of the MIME- |
| of the MIME-Version header field indicates that the message is in |  | Version header field indicates that the message is in full |
| full conformance with the MIME protocol (as defined in [RFC2045]). |  | conformance with the MIME protocol (as defined in [RFC2045]). |
| Proxies/gateways are responsible for ensuring full conformance (where |  | Senders are responsible for ensuring full conformance (where |
| possible) when exporting HTTP messages to strict MIME environments. |  | possible) when exporting HTTP messages to strict MIME environments. |
| MIME-Version = 1*DIGIT "." 1*DIGIT |  |  |
| MIME version "1.0" is the default for use in HTTP/1.1. However, |  |  |
| HTTP/1.1 message parsing and semantics are defined by this document |  |  |
| and not the MIME specification. |  |  |
| A.2. Conversion to Canonical Form |  | A.2. Conversion to Canonical Form |
| MIME requires that an Internet mail body-part be converted to |  | MIME requires that an Internet mail body part be converted to |
| canonical form prior to being transferred, as described in Section 4 |  | canonical form prior to being transferred, as described in Section 4 |
| of [RFC2049]. Section 3.1.1.3 of this document describes the forms |  | of [RFC2049]. Section 3.1.1.3 of this document describes the forms |
| allowed for subtypes of the "text" media type when transmitted over |  | allowed for subtypes of the "text" media type when transmitted over |
| HTTP. [RFC2046] requires that content with a type of "text" |  | HTTP. [RFC2046] requires that content with a type of "text" |
| represent line breaks as CRLF and forbids the use of CR or LF outside |  | represent line breaks as CRLF and forbids the use of CR or LF outside |
| of line break sequences. HTTP allows CRLF, bare CR, and bare LF to |  | of line break sequences. HTTP allows CRLF, bare CR, and bare LF to |
| indicate a line break within text content when a message is |  | indicate a line break within text content. |
| transmitted over HTTP. |  |  |
| Where it is possible, a proxy or gateway from HTTP to a strict MIME |  | A proxy or gateway from HTTP to a strict MIME environment ought to |
| environment SHOULD translate all line breaks within the text media |  | translate all line breaks within the text media types described in |
| types described in Section 3.1.1.3 of this document to the RFC 2049 |  | Section 3.1.1.3 of this document to the RFC 2049 canonical form of |
| canonical form of CRLF. Note, however, that this might be |  | CRLF. Note, however, this might be complicated by the presence of a |
| complicated by the presence of a Content-Encoding and by the fact |  | Content-Encoding and by the fact that HTTP allows the use of some |
| that HTTP allows the use of some character encodings which do not use |  | charsets that do not use octets 13 and 10 to represent CR and LF, |
| octets 13 and 10 to represent CR and LF, respectively, as is the case |  | respectively. |
| for some multi-byte character encodings. |  |  |
| Conversion will break any cryptographic checksums applied to the |  | Conversion will break any cryptographic checksums applied to the |
| original content unless the original content is already in canonical |  | original content unless the original content is already in canonical |
| form. Therefore, the canonical form is recommended for any content |  | form. Therefore, the canonical form is recommended for any content |
| that uses such checksums in HTTP. |  | that uses such checksums in HTTP. |
| A.3. Conversion of Date Formats |  | A.3. Conversion of Date Formats |
| HTTP/1.1 uses a restricted set of date formats (Section 8.1.1.1) to |  | HTTP/1.1 uses a restricted set of date formats (Section 7.1.1.1) to |
| simplify the process of date comparison. Proxies and gateways from |  | simplify the process of date comparison. Proxies and gateways from |
| other protocols SHOULD ensure that any Date header field present in a |  | other protocols ought to ensure that any Date header field present in |
| message conforms to one of the HTTP/1.1 formats and rewrite the date |  | a message conforms to one of the HTTP/1.1 formats and rewrite the |
| if necessary. |  | date if necessary. |
| A.4. Introduction of Content-Encoding |  | A.4. Conversion of Content-Encoding |
| MIME does not include any concept equivalent to HTTP/1.1's Content- |  | MIME does not include any concept equivalent to HTTP/1.1's Content- |
| Encoding header field. Since this acts as a modifier on the media |  | Encoding header field. Since this acts as a modifier on the media |
| type, proxies and gateways from HTTP to MIME-compliant protocols MUST |  | type, proxies and gateways from HTTP to MIME-compliant protocols |
| either change the value of the Content-Type header field or decode |  | ought to either change the value of the Content-Type header field or |
| the representation before forwarding the message. (Some experimental |  | decode the representation before forwarding the message. (Some |
| applications of Content-Type for Internet mail have used a media-type |  | experimental applications of Content-Type for Internet mail have used |
| parameter of ";conversions=<content-coding>" to perform a function |  | a media-type parameter of ";conversions=<content-coding>" to perform |
| equivalent to Content-Encoding. However, this parameter is not part |  | a function equivalent to Content-Encoding. However, this parameter |
| of the MIME standards). |  | is not part of the MIME standards). |
| A.5. No Content-Transfer-Encoding |  | A.5. Conversion of Content-Transfer-Encoding |
| HTTP does not use the Content-Transfer-Encoding field of MIME. |  | HTTP does not use the Content-Transfer-Encoding field of MIME. |
| Proxies and gateways from MIME-compliant protocols to HTTP MUST |  | Proxies and gateways from MIME-compliant protocols to HTTP need to |
| remove any Content-Transfer-Encoding prior to delivering the response |  | remove any Content-Transfer-Encoding prior to delivering the response |
| message to an HTTP client. |  | message to an HTTP client. |
| Proxies and gateways from HTTP to MIME-compliant protocols are |  | Proxies and gateways from HTTP to MIME-compliant protocols are |
| responsible for ensuring that the message is in the correct format |  | responsible for ensuring that the message is in the correct format |
| and encoding for safe transport on that protocol, where "safe |  | and encoding for safe transport on that protocol, where "safe |
| transport" is defined by the limitations of the protocol being used. |  | transport" is defined by the limitations of the protocol being used. |
| Such a proxy or gateway SHOULD label the data with an appropriate |  | Such a proxy or gateway ought to transform and label the data with an |
| Content-Transfer-Encoding if doing so will improve the likelihood of |  | appropriate Content-Transfer-Encoding if doing so will improve the |
| safe transport over the destination protocol. |  | likelihood of safe transport over the destination protocol. |
| A.6. MHTML and Line Length Limitations |  | A.6. MHTML and Line Length Limitations |
| HTTP implementations which share code with MHTML [RFC2557] |  | HTTP implementations that share code with MHTML [RFC2557] |
| implementations need to be aware of MIME line length limitations. |  | implementations need to be aware of MIME line length limitations. |
| Since HTTP does not have this limitation, HTTP does not fold long |  | Since HTTP does not have this limitation, HTTP does not fold long |
| lines. MHTML messages being transported by HTTP follow all |  | lines. MHTML messages being transported by HTTP follow all |
| conventions of MHTML, including line length limitations and folding, |  | conventions of MHTML, including line length limitations and folding, |
| canonicalization, etc., since HTTP transports all message-bodies as |  | canonicalization, etc., since HTTP transfers message-bodies as |
| payload (see Section 3.1.1.4) and does not interpret the content or |  | payload and, aside from the "multipart/byteranges" type (Appendix A |
| any MIME header lines that might be contained therein. |  | of [Part5]), does not interpret the content or any MIME header lines |
|  |  | that might be contained therein. |
| Appendix B. Additional Features |  | Appendix B. Changes from RFC 2616 |
| [RFC1945] and [RFC2068] document protocol elements used by some |  | The primary changes in this revision have been editorial in nature: |
| existing HTTP implementations, but not consistently and correctly |  | extracting the messaging syntax and partitioning HTTP semantics into |
| across most HTTP/1.1 applications. Implementers are advised to be |  | separate documents for the core features, conditional requests, |
| aware of these features, but cannot rely upon their presence in, or |  | partial requests, caching, and authentication. The conformance |
| interoperability with, other HTTP/1.1 applications. Some of these |  | language has been revised to clearly target requirements and the |
| describe proposed experimental features, and some describe features |  | terminology has been improved to distinguish payload from |
| that experimental deployment found lacking that are now addressed in |  | representations and representations from resources. An algorithm has |
| the base HTTP/1.1 specification. |  | been added for determining if a payload is associated with a specific |
|  |  | identifier (Section 3.1.4.1). |
| A number of other header fields, such as Content-Disposition and |  | A new requirement has been added that semantics embedded in a URI |
| Title, from SMTP and MIME are also often implemented (see [RFC6266] |  | should be disabled when those semantics are inconsistent with the |
| and [RFC2076]). |  | request method, since this is a common cause of interoperability |
|  |  | failure. |
| Appendix C. Changes from RFC 2616 |  | The default charset of ISO-8859-1 for text media types has been |
|  |  | removed; the default is now whatever the media type definition says |
|  |  | (Section 3.1.1.3). Likewise, special treatment of ISO-8859-1 has |
|  |  | been removed from the Accept-Charset header field (Section 5.3.3). |
| Remove base URI setting semantics for "Content-Location" due to poor |  | The Content-Disposition header field has been removed since it is now |
| implementation support, which was caused by too many broken servers |  | defined by [RFC6266]. |
| emitting bogus Content-Location header fields, and also the |  |  |
| potentially undesirable effect of potentially breaking relative links |  |  |
| in content-negotiated resources. (Section 3.1.4.2) |  |  |
| Clarify definition of POST. (Section 5.3.3) |  | The definition of Content-Location has been changed to no longer |
|  |  | affect the base URI for resolving relative URI references, due to |
|  |  | poor implementation support and the undesirable effect of potentially |
|  |  | breaking relative links in content-negotiated resources |
|  |  | (Section 3.1.4.2). |
| Remove requirement to handle all Content-* header fields; ban use of |  | The Content-MD5 header field has been removed because it was |
| Content-Range with PUT. (Section 5.3.4) |  | inconsistently implemented with respect to partial responses. |
| Take over definition of CONNECT method from [RFC2817]. |  | To be consistent with the method-neutral parsing algorithm of |
| (Section 5.3.6) |  | [Part1], the definition of GET has been relaxed so that requests can |
|  |  | have a body, even though a body has no meaning for GET |
|  |  | (Section 4.3.1). |
| Restrict "Max-Forwards" header field to OPTIONS and TRACE |  | Servers are no longer required to handle all Content-* header fields |
| (previously, extension methods could have used it as well). |  | and use of Content-Range has been explicitly banned in PUT requests |
| (Section 6.1.1) |  | (Section 4.3.4). |
| The ABNF for the "Expect" header field has been both fixed (allowing |  | Definition of the CONNECT method has been moved from [RFC2817] to |
| parameters for value-less expectations as well) and simplified |  | this specification (Section 4.3.6). |
| (allowing trailing semicolons after "100-continue" when they were |  |  |
| invalid before). (Section 6.1.2) |  |  |
| Remove ISO-8859-1 special-casing in Accept-Charset. (Section 6.3.3) |  | The OPTIONS (Section 4.3.7) and TRACE (Section 4.3.8) request methods |
|  |  | have been defined as being safe. |
| Allow "Referer" field value of "about:blank" as alternative to not |  | The definition of Expect has been both fixed to allow parameters for |
| specifying it. (Section 6.5.2) |  | value-less expectations and simplified to allow trailing semicolons |
|  |  | after "100-continue" (Section 5.1.1). |
| Broadened the definition of 203 (Non-Authoritative Information) to |  | The Max-Forwards header field (Section 5.1.2) has been restricted to |
| include cases of payload transformations as well. (Section 7.3.4) |  | the OPTIONS and TRACE methods; previously, extension methods could |
|  |  | have used it as well. |
| Status codes 301, 302, and 307: removed the normative requirements on |  | The "about:blank" URI has been suggested as a value for the Referer |
| both response payloads and user interaction. (Section 7.4) |  | header field when no referring URI is applicable, which distinguishes |
|  |  | that case from others where the Referer field is not sent or has been |
|  |  | removed (Section 5.5.2). |
| Failed to consider that there are many other request methods that are |  | The 201 (Created) status description has been changed to allow for |
| safe to automatically redirect, and further that the user agent is |  | the possibility that more than one resource has been created |
| able to make that determination based on the request method |  | (Section 6.3.2). |
| semantics. Furthermore, allow user agents to rewrite the method from |  |  |
| POST to GET for status codes 301 and 302. (Sections 7.4.2, 7.4.3 and |  |  |
| 7.4.7) |  |  |
| Deprecate 305 (Use Proxy) status code, because user agents did not |  | The definition of 203 (Non-Authoritative Information) has been |
| implement it. It used to indicate that the target resource needs to |  | broadened to include cases of payload transformations as well |
| be accessed through the proxy given by the Location field. The |  | (Section 6.3.4). |
| Location field gave the URI of the proxy. The recipient was expected |  |  |
| to repeat this single request via the proxy. (Section 7.4.5) |  |  |
| Define status 426 (Upgrade Required) (this was incorporated from |  | The redirect status codes 301, 302, and 307 no longer have normative |
| [RFC2817]). (Section 7.5.15) |  | requirements on response payloads and user interaction (Section 6.4). |
| Correct syntax of "Location" header field to allow URI references |  | The request methods that are safe to automatically redirect is no |
| (including relative references and fragments), as referred symbol |  | longer a closed set; user agents are able to make that determination |
| "absoluteURI" wasn't what was expected, and add some clarifications |  | based upon the request method semantics (Section 6.4). |
| as to when use of fragments would not be appropriate. |  |  |
| (Section 8.1.2) |  |  |
| Reclassify "Allow" as response header field, removing the option to |  | The description of 303 (See Other) status code has been changed to |
| specify it in a PUT request. Relax the server requirement on the |  | allow it to be cached if explicit freshness information is given, and |
| contents of the Allow header field and remove requirement on clients |  | a specific definition has been added for a 303 response to GET |
| to always trust the header field value. (Section 8.4.1) |  | (Section 6.4.4). |
| In the description of the "Server" header field, the "Via" field was |  | The status codes 301 and 302 (sections 6.4.2 and 6.4.3) have been |
| described as a SHOULD. The requirement was and is stated correctly |  | changed to allow user agents to rewrite the method from POST to GET. |
| in the description of the Via header field in Section 5.7 of [Part1]. |  |  |
| (Section 8.4.2) |  |  |
| Clarify contexts that charset is used in. (Section 3.1.1.2) |  | The 305 (Use Proxy) status code has been deprecated due to security |
|  |  | concerns regarding in-band configuration of a proxy (Section 6.4.5). |
| Remove the default character encoding of "ISO-8859-1" for text media |  | The 400 (Bad Request) status code has been relaxed so that it isn't |
| types; the default now is whatever the media type definition says. |  | limited to syntax errors (Section 6.5.1). |
| (Section 3.1.1.3) |  |  |
| Registration of Content Codings now requires IETF Review |  | The 426 (Upgrade Required) status code has been incorporated from |
| (Section 9.4) |  | [RFC2817] (Section 6.5.15). |
| Remove definition of "Content-MD5 header" field because it was |  | The following status codes are now cacheable (that is, they can be |
| inconsistently implemented with respect to partial responses, and |  | stored and reused by a cache without explicit freshness information |
| also because of known deficiencies in the hash algorithm itself (see |  | present): 204, 404, 405, 414, 501. |
| [RFC6151] for details). |  |  |
| Introduce Method Registry. (Section 9.1) |  | Allow has been reclassified as a response header field, removing the |
|  |  | option to specify it in a PUT request. Requirements relating to the |
|  |  | content of Allow have been relaxed; correspondingly, clients are not |
|  |  | required to always trust its value (Section 7.4.1). |
| Take over the Status Code Registry, previously defined in Section 7.1 |  | The target of requirements on HTTP-date and the Date header field |
| of [RFC2817]. (Section 9.2) |  | have been reduced to those systems generating the date, rather than |
|  |  | all systems sending a date (Section 7.1.1). |
| Remove reference to non-existant identity transfer-coding value |  | The syntax of the Location header field has been changed to allow all |
| tokens. (Appendix A.5) |  | URI references, including relative references and fragments, along |
| Remove discussion of Content-Disposition header field, it is now |  | with some clarifications as to when use of fragments would not be |
| defined by [RFC6266]. (Appendix B) |  | appropriate (Section 7.1.2). |
| Appendix D. Imported ABNF |  | A Method Registry has been defined (Section 8.1). |
|  |  | The Status Code Registry (Section 8.2) has been redefined by this |
|  |  | specification; previously, it was defined in Section 7.1 of |
|  |  | [RFC2817]. |
|  |  | Registration of Content Codings has been changed to require IETF |
|  |  | Review (Section 8.4). |
|  |  | Appendix C. Imported ABNF |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), |  | Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), |
| CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double |  | CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double |
| quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF |  | quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF |
| (line feed), OCTET (any 8-bit sequence of data), SP (space), and |  | (line feed), OCTET (any 8-bit sequence of data), SP (space), and |
| VCHAR (any visible US-ASCII character). |  | VCHAR (any visible US-ASCII character). |
| The rules below are defined in [Part1]: |  | The rules below are defined in [Part1]: |
| BWS = <BWS, defined in [Part1], Section 3.2.1> |  | BWS = <BWS, defined in [Part1], Section 3.2.3> |
| OWS = <OWS, defined in [Part1], Section 3.2.1> |  | OWS = <OWS, defined in [Part1], Section 3.2.3> |
| RWS = <RWS, defined in [Part1], Section 3.2.1> |  | 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.4> |  | 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.4> |  | quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> |
| token = <token, defined in [Part1], Section 3.2.4> |  | token = <token, defined in [Part1], Section 3.2.6> |
| word = <word, defined in [Part1], Section 3.2.4> |  | word = <word, defined in [Part1], Section 3.2.6> |
| Appendix E. Collected ABNF |  | Appendix D. Collected ABNF |
| 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 ] ) ] ) |
| Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS |  | Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS |
| ( codings [ weight ] ) ] ) ] |  | ( codings [ weight ] ) ] ) ] |
| Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS |  | Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS |
| "," [ OWS ( language-range [ weight ] ) ] ) |  | "," [ OWS ( language-range [ weight ] ) ] ) |
| Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ] |  | Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ] |
| BWS = <BWS, defined in [Part1], Section 3.2.1> |  | BWS = <BWS, defined in [Part1], Section 3.2.3> |
| Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS |  | Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS |
| content-coding ] ) |  | content-coding ] ) |
| Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS |  | Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS |
| language-tag ] ) |  | language-tag ] ) |
| Content-Location = absolute-URI / partial-URI |  | Content-Location = absolute-URI / partial-URI |
| Content-Type = media-type |  | Content-Type = media-type |
| Date = HTTP-date |  | Date = HTTP-date |
| Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) |  | Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) |
| From = mailbox |  | From = mailbox |
| GMT = %x47.4D.54 ; GMT |  | GMT = %x47.4D.54 ; GMT |
| HTTP-date = rfc1123-date / obs-date |  | HTTP-date = IMF-fixdate / obs-date |
|  |  | IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT |
| Location = URI-reference |  | Location = URI-reference |
| MIME-Version = 1*DIGIT "." 1*DIGIT |  |  |
| Max-Forwards = 1*DIGIT |  | Max-Forwards = 1*DIGIT |
| OWS = <OWS, defined in [Part1], Section 3.2.1> |  | OWS = <OWS, defined in [Part1], Section 3.2.3> |
| RWS = <RWS, defined in [Part1], Section 3.2.1> |  | RWS = <RWS, defined in [Part1], Section 3.2.3> |
| Referer = absolute-URI / partial-URI |  | Referer = absolute-URI / partial-URI |
| Retry-After = HTTP-date / delta-seconds |  | Retry-After = HTTP-date / delta-seconds |
| 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 [ "=" word ] |
| 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 |  | attribute = token |
| charset = token |  | charset = token |
| codings = content-coding / "identity" / "*" |  | codings = content-coding / "identity" / "*" |
| comment = <comment, defined in [Part1], Section 3.2.4> |  | 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 |
| skipping to change at page 91, line 12 |  | skipping to change at page 93, line 24 |
| / %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 = attribute "=" value |
| 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.4> |  | quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> |
| qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) |  | qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) |
| rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT |  |  |
| 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.4> |  | token = <token, defined in [Part1], Section 3.2.6> |
| type = token |  | type = token |
| value = word |  | value = word |
| weight = OWS ";" OWS "q=" qvalue |  | weight = OWS ";" OWS "q=" qvalue |
| word = <word, defined in [Part1], Section 3.2.4> |  | word = <word, defined in [Part1], Section 3.2.6> |
| year = 4DIGIT |  | year = 4DIGIT |
| Appendix F. Change Log (to be removed by RFC Editor before publication) |  | Appendix E. Change Log (to be removed by RFC Editor before publication) |
| F.1. Since RFC 2616 |  |  |
| Extracted relevant partitions from [RFC2616]. |  |  |
| F.2. Since draft-ietf-httpbis-p2-semantics-00 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a MUST" |  |  |
| (<http://purl.org/NET/http-errata#via-must>) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/6>: "Fragments |  |  |
| allowed in Location" |  |  |
| (<http://purl.org/NET/http-errata#location-fragments>) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods |  |  |
| vs Redirection" (<http://purl.org/NET/http-errata#saferedirect>) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/17>: "Revise |  |  |
| description of the POST method" |  |  |
| (<http://purl.org/NET/http-errata#post>) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and |  |  |
| Informative references" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606 |  |  |
| Compliance" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative |  |  |
| references" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant |  |  |
| cross-references" |  |  |
| Other changes: |  |  |
| o Move definitions of 304 and 412 condition codes to [Part4] |  |  |
| F.3. Since draft-ietf-httpbis-p3-payload-00 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type |  |  |
| Registrations" (<http://purl.org/NET/http-errata#media-reg>) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/14>: "Clarification |  |  |
| regarding quoting of charset values" |  |  |
| (<http://purl.org/NET/http-errata#charactersets>) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove |  |  |
| 'identity' token references" |  |  |
| (<http://purl.org/NET/http-errata#identity>) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/25>: "Accept- |  |  |
| Encoding BNF" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and |  |  |
| Informative references" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700 |  |  |
| references" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to |  |  |
| RFC4288" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative |  |  |
| references" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1 |  |  |
| Reference" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding |  |  |
| References Normative" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up- |  |  |
| to-date references" |  |  |
| F.4. Since draft-ietf-httpbis-p2-semantics-01 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side |  |  |
| effects" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate Host |  |  |
| header requirements" |  |  |
| Ongoing work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Move "Product Tokens" section (back) into Part 1, as "token" is |  |  |
| used in the definition of the Upgrade header field. |  |  |
| o Add explicit references to BNF syntax and rules imported from |  |  |
| other parts of the specification. |  |  |
| o Copy definition of delta-seconds from Part6 instead of referencing |  |  |
| it. |  |  |
| F.5. Since draft-ietf-httpbis-p3-payload-01 |  |  |
| Ongoing work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Add explicit references to BNF syntax and rules imported from |  |  |
| other parts of the specification. |  |  |
| F.6. Since draft-ietf-httpbis-p2-semantics-02 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring |  |  |
| Allow in 405 responses" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status Code |  |  |
| Registry" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/61>: "Redirection |  |  |
| vs. Location" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/70>: "Cacheability |  |  |
| of 303 response" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use Proxy" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/105>: |  |  |
| "Classification for Allow header field" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store |  |  |
| under' vs 'store at'" |  |  |
| Ongoing work on IANA Message Header Field Registration |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |  |  |
| o Reference RFC 3984, and update header field registrations for |  |  |
| header fields defined in this document. |  |  |
| Ongoing work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Replace string literals when the string really is case-sensitive |  |  |
| (method). |  |  |
| F.7. Since draft-ietf-httpbis-p3-payload-02 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting |  |  |
| Charsets" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/105>: |  |  |
| "Classification for Allow header field" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/115>: "missing |  |  |
| default for qvalue in description of Accept-Encoding" |  |  |
| Ongoing work on IANA Message Header Field Registration |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |  |  |
| o Reference RFC 3984, and update header field registrations for |  |  |
| header fields defined in this document. |  |  |
| F.8. Since draft-ietf-httpbis-p2-semantics-03 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/98>: "OPTIONS |  |  |
| payload bodies" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/119>: "Description |  |  |
| of CONNECT should refer to RFC2817" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/125>: "Location |  |  |
| Content-Location reference request/response mixup" |  |  |
| Ongoing work on Method Registry |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/72>): |  |  |
| o Added initial proposal for registration process, plus initial |  |  |
| content (non-HTTP/1.1 methods to be added by a separate |  |  |
| specification). |  |  |
| F.9. Since draft-ietf-httpbis-p3-payload-03 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting |  |  |
| Charsets" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/113>: "language tag |  |  |
| matching (Accept-Language) vs RFC4647" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/121>: "RFC 1806 has |  |  |
| been replaced by RFC2183" |  |  |
| Other changes: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding |  |  |
| References Normative" -- rephrase the annotation and reference |  |  |
| BCP97. |  |  |
| F.10. Since draft-ietf-httpbis-p2-semantics-04 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is |  |  |
| updated by RFC 5322" |  |  |
| Ongoing work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Use "/" instead of "|" for alternatives. |  |  |
| o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |  |  |
| whitespace ("OWS") and required whitespace ("RWS"). |  |  |
| o Rewrite ABNFs to spell out whitespace rules, factor out header |  |  |
| field value format definitions. |  |  |
| F.11. Since draft-ietf-httpbis-p3-payload-04 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is |  |  |
| updated by RFC 5322" |  |  |
| Ongoing work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Use "/" instead of "|" for alternatives. |  |  |
| o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |  |  |
| whitespace ("OWS") and required whitespace ("RWS"). |  |  |
| o Rewrite ABNFs to spell out whitespace rules, factor out header |  |  |
| field value format definitions. |  |  |
| F.12. Since draft-ietf-httpbis-p2-semantics-05 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "reason-phrase |  |  |
| BNF" |  |  |
| Final work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Add appendix containing collected and expanded ABNF, reorganize |  |  |
| ABNF introduction. |  |  |
| F.13. Since draft-ietf-httpbis-p3-payload-05 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join |  |  |
| "Differences Between HTTP Entities and RFC 2045 Entities"?" |  |  |
| Final work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Add appendix containing collected and expanded ABNF, reorganize |  |  |
| ABNF introduction. |  |  |
| Other changes: |  |  |
| o Move definition of quality values into Part 1. |  |  |
| F.14. Since draft-ietf-httpbis-p2-semantics-06 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/144>: "Clarify when |  |  |
| Referer is sent" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/164>: "status codes |  |  |
| vs methods" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/170>: "Do not |  |  |
| require "updates" relation for specs that register status codes or |  |  |
| method names" |  |  |
| F.15. Since draft-ietf-httpbis-p3-payload-06 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/80>: "Content- |  |  |
| Location isn't special" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content |  |  |
| Sniffing" |  |  |
| F.16. Since draft-ietf-httpbis-p2-semantics-07 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/27>: "Idempotency" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/33>: "TRACE security |  |  |
| considerations" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/110>: "Clarify rules |  |  |
| for determining what entities a response carries" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/140>: "update note |  |  |
| citing RFC 1945 and 2068" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/182>: "update note |  |  |
| about redirect limit" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/191>: "Location |  |  |
| header field ABNF should use 'URI'" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/192>: "fragments in |  |  |
| Location vs status 303" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA |  |  |
| registrations for optional status codes" |  |  |
| Partly resolved issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/171>: "Are OPTIONS |  |  |
| and TRACE safe?" |  |  |
| F.17. Since draft-ietf-httpbis-p3-payload-07 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/13>: "Updated |  |  |
| reference for language tags" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/110>: "Clarify rules |  |  |
| for determining what entities a response carries" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/154>: "Content- |  |  |
| Location base-setting problems" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content |  |  |
| Sniffing" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/188>: "pick IANA |  |  |
| policy (RFC5226) for Transfer Coding / Content Coding" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/189>: "move |  |  |
| definitions of gzip/deflate/compress to part 1" |  |  |
| Partly resolved issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA |  |  |
| requirements wrt Transfer-Coding values" (add the IANA |  |  |
| Considerations subsection) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/149>: "update IANA |  |  |
| requirements wrt Content-Coding values" (add the IANA |  |  |
| Considerations subsection) |  |  |
| F.18. Since draft-ietf-httpbis-p2-semantics-08 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods |  |  |
| vs Redirection" (we missed the introduction to the 3xx status |  |  |
| codes when fixing this previously) |  |  |
| F.19. Since draft-ietf-httpbis-p3-payload-08 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/81>: "Content |  |  |
| Negotiation for media types" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/181>: "Accept- |  |  |
| Language: which RFC4647 filtering?" |  |  |
| F.20. Since draft-ietf-httpbis-p2-semantics-09 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment |  |  |
| combination / precedence during redirects" |  |  |
| Partly resolved issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location |  |  |
| header field payload handling" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |  |  |
| requested resource's URI" |  |  |
| F.21. Since draft-ietf-httpbis-p3-payload-09 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version |  |  |
| not listed in P1, general header fields" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry |  |  |
| for content/transfer encodings" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content |  |  |
| Sniffing" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term |  |  |
| "word" when talking about header field structure" |  |  |
| Partly resolved issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |  |  |
| requested resource's URI" |  |  |
| F.22. Since draft-ietf-httpbis-p2-semantics-10 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify |  |  |
| 'Requested Variant'" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify |  |  |
| entity / representation / variant terminology" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/139>: "Methods and |  |  |
| Caching" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/190>: "OPTIONS vs |  |  |
| Max-Forwards" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: "Status codes |  |  |
| and caching" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |  |  |
| removing the 'changes from 2068' sections" |  |  |
| F.23. Since draft-ietf-httpbis-p3-payload-10 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify |  |  |
| 'Requested Variant'" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/80>: "Content- |  |  |
| Location isn't special" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting |  |  |
| messages with multipart/byteranges" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify |  |  |
| entity / representation / variant terminology" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/136>: "confusing |  |  |
| req. language for Content-Location" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/167>: "Content- |  |  |
| Location on 304 responses" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/183>: "'requested |  |  |
| resource' in content-encoding definition" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |  |  |
| removing the 'changes from 2068' sections" |  |  |
| Partly resolved issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/178>: "Content-MD5 |  |  |
| and partial responses" |  |  |
| F.24. Since draft-ietf-httpbis-p2-semantics-11 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/229>: |  |  |
| "Considerations for new status codes" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/230>: |  |  |
| "Considerations for new methods" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/232>: "User-Agent |  |  |
| guidelines" (relating to the 'User-Agent' header field) |  |  |
| F.25. Since draft-ietf-httpbis-p3-payload-11 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/123>: "Factor out |  |  |
| Content-Disposition" |  |  |
| F.26. Since draft-ietf-httpbis-p2-semantics-12 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment |  |  |
| combination / precedence during redirects" (added warning about |  |  |
| having a fragid on the redirect might cause inconvenience in some |  |  |
| cases) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/79>: "Content-* vs. |  |  |
| PUT" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/102>: "Understanding |  |  |
| Content-* on non-PUT requests" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/104>: "Header field |  |  |
| type defaulting" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store |  |  |
| under' vs 'store at'" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/137>: "duplicate |  |  |
| ABNF for reason-phrase" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/180>: "Note special |  |  |
| status of Content-* prefix in header field registration |  |  |
| procedures" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/203>: "Max-Forwards |  |  |
| vs extension methods" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/213>: "What is the |  |  |
| value space of HTTP status codes?" (actually fixed in |  |  |
| draft-ietf-httpbis-p2-semantics-11) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header Field |  |  |
| Classification" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/225>: "PUT side |  |  |
| effect: invalidation or just stale?" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/226>: "proxies not |  |  |
| supporting certain methods" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/239>: "Migrate |  |  |
| CONNECT from RFC2817 to p2" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate |  |  |
| Upgrade details from RFC2817" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/267>: "clarify PUT |  |  |
| semantics'" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/275>: "duplicate |  |  |
| ABNF for 'Method'" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |  |  |
| ABNFs for header fields" |  |  |
| F.27. Since draft-ietf-httpbis-p3-payload-12 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header Field |  |  |
| Classification" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |  |  |
| ABNFs for header fields" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/277>: "potentially |  |  |
| misleading MAY in media-type def" |  |  |
| F.28. Since draft-ietf-httpbis-p2-semantics-13 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |  |  |
| ABNFs for header fields" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/251>: "message body |  |  |
| in CONNECT request" |  |  |
| F.29. Since draft-ietf-httpbis-p3-payload-13 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/20>: "Default |  |  |
| charsets for text media types" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/178>: "Content-MD5 |  |  |
| and partial responses" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |  |  |
| ABNFs for header fields" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/281>: "confusing |  |  |
| undefined parameter in media range example" |  |  |
| F.30. Since draft-ietf-httpbis-p2-semantics-14 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/255>: "Clarify |  |  |
| status code for rate limiting" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/294>: "clarify 403 |  |  |
| forbidden" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/296>: "Clarify 203 |  |  |
| Non-Authoritative Information" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/298>: "update |  |  |
| default reason phrase for 413" |  |  |
| F.31. Since draft-ietf-httpbis-p3-payload-14 |  |  |
| None. |  |  |
| F.32. Since draft-ietf-httpbis-p2-semantics-15 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/285>: "Strength of |  |  |
| requirements on Accept re: 406" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/303>: "400 response |  |  |
| isn't generic" |  |  |
| F.33. Since draft-ietf-httpbis-p3-payload-15 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/285>: "Strength of |  |  |
| requirements on Accept re: 406" |  |  |
| F.34. Since draft-ietf-httpbis-p2-semantics-16 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/160>: "Redirects and |  |  |
| non-GET methods" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document |  |  |
| HTTP's error-handling philosophy" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/231>: |  |  |
| "Considerations for new header fields" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/310>: "clarify 303 |  |  |
| redirect on HEAD" |  |  |
| F.35. Since draft-ietf-httpbis-p3-payload-16 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document |  |  |
| HTTP's error-handling philosophy" |  |  |
| F.36. Since draft-ietf-httpbis-p2-semantics-17 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location |  |  |
| header field payload handling" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/255>: "Clarify |  |  |
| status code for rate limiting" (change backed out because a new |  |  |
| status code is being defined for this purpose) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/312>: "should there |  |  |
| be a permanent variant of 307" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/325>: "When are |  |  |
| Location's semantics triggered?" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/327>: "'expect' |  |  |
| grammar missing OWS" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/329>: "header field |  |  |
| considerations: quoted-string vs use of double quotes" |  |  |
| F.37. Since draft-ietf-httpbis-p3-payload-17 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended |  |  |
| maturity level vs normative references" |  |  |
| F.38. Since draft-ietf-httpbis-p2-semantics-18 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/227>: "Combining |  |  |
| HEAD responses" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/238>: "Requirements |  |  |
| for user intervention during redirects" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/250>: "message-body |  |  |
| in CONNECT response" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/295>: "Applying |  |  |
| original fragment to 'plain' redirected URI" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/302>: "Misplaced |  |  |
| text on connection handling in p2" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/331>: "clarify that |  |  |
| 201 doesn't require Location header fields" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/332>: "relax |  |  |
| requirements on hypertext in 3/4/5xx error responses" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/333>: "example for |  |  |
| 426 response should have a payload" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/336>: "drop |  |  |
| indirection entries for status codes" |  |  |
| F.39. Since draft-ietf-httpbis-p3-payload-18 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/330>: "is ETag a |  |  |
| representation header field?" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/338>: "Content- |  | E.1. Since RFC 2616 |
| Location doesn't constrain the cardinality of representations" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/346>: "make IANA |  | Changes up to the first Working Group Last Call draft are summarized |
| policy definitions consistent" |  | in <http://trac.tools.ietf.org/html/ |
|  |  | draft-ietf-httpbis-p2-semantics-21#appendix-F>. |
| F.40. Since draft-ietf-httpbis-p2-semantics-19 and |  | E.2. Since draft-ietf-httpbis-p2-semantics-21 |
| draft-ietf-httpbis-p3-payload-19 |  |  |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/312>: "should there |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/22>: "ETag (and |
| be a permanent variant of 307" |  | other metadata) in status messages" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/347>: "clarify that |  |  |
| 201 can imply *multiple* resources were created" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/351>: "merge P2 and |  |  |
| P3" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF |  |  |
| requirements for recipients" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/364>: "Capturing |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/96>: "Conditional |
| more information in the method registry" |  | GET text" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/146>: "Clarify |
| introduction of new IANA registries as normative changes" |  | description of 405 (Not Allowed)" |
| F.41. Since draft-ietf-httpbis-p2-semantics-20 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing |
|  |  | heuristic caching for new status codes" |
| Closed issues: |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/315>: "method |
|  |  | semantics: retrieval/representation" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/378>: "is 'q=' case- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/388>: "User |
| sensitive?" |  | confirmation for unsafe methods" |
| Other changes: |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/404>: "Tentative |
|  |  | Status Codes" |
| o Conformance criteria and considerations regarding error handling |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/418>: "No-Transform" |
| are now defined in Part 1. |  |  |
| o Properly explain what HTTP semantics are and why. Rewrite |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/419>: "p2 editorial |
| introductory description of methods. Rewrite definition of "safe" |  | feedback" |
| to be more operable and weaken the original same-origin |  |  |
| restrictions to be more consistent with modern UAs. Rewrite |  |  |
| definition of "idempotent", add definition of "cacheable". |  |  |
| o Conneg terminology change: "server-driven" => "proactive" (UA |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/424>: "Absence of |
| sends Accept* fields), "agent-driven" => "reactive" (UA waits for |  | Accept-Encoding" |
| 300/Alternatives) |  |  |
| o Move description of "100-continue" from Part 1 over here. |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/428>: "Accept- |
|  |  | Language ordering for identical qvalues" |
| o Move definition of "Vary" header field from Part 6 over here. |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/432>: "Identify |
|  |  | additional status codes as cacheable by default" |
| o Rewrite definition of "representation". |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/434>: "mention in |
|  |  | header field considerations that leading/trailing WS is lossy" |
| Index |  | Index |
| 1 |  | 1 |
| 1xx Informational (status code class) 49 |  | 1xx Informational (status code class) 49 |
| 2 |  | 2 |
| 2xx Successful (status code class) 50 |  | 2xx Successful (status code class) 50 |
| 3 |  | 3 |
| 3xx Redirection (status code class) 52 |  | 3xx Redirection (status code class) 53 |
| 4 |  | 4 |
| 4xx Client Error (status code class) 56 |  | 4xx Client Error (status code class) 57 |
| 5 |  | 5 |
| 5xx Server Error (status code class) 60 |  | 5xx Server Error (status code class) 61 |
| 1 |  | 1 |
| 100 Continue (status code) 49 |  | 100 Continue (status code) 49 |
| 100-continue (expect value) 35 |  | 100-continue (expect value) 33 |
| 101 Switching Protocols (status code) 49 |  | 101 Switching Protocols (status code) 50 |
| 2 |  | 2 |
| 200 OK (status code) 50 |  | 200 OK (status code) 50 |
| 201 Created (status code) 50 |  | 201 Created (status code) 51 |
| 202 Accepted (status code) 51 |  | 202 Accepted (status code) 51 |
| 203 Non-Authoritative Information (status code) 51 |  | 203 Non-Authoritative Information (status code) 51 |
| 204 No Content (status code) 51 |  | 204 No Content (status code) 52 |
| 205 Reset Content (status code) 52 |  | 205 Reset Content (status code) 52 |
| 3 |  | 3 |
| 300 Multiple Choices (status code) 54 |  | 300 Multiple Choices (status code) 54 |
| 301 Moved Permanently (status code) 54 |  | 301 Moved Permanently (status code) 55 |
| 302 Found (status code) 55 |  | 302 Found (status code) 55 |
| 303 See Other (status code) 55 |  | 303 See Other (status code) 56 |
| 305 Use Proxy (status code) 56 |  | 305 Use Proxy (status code) 56 |
| 306 (Unused) (status code) 56 |  | 306 (Unused) (status code) 56 |
| 307 Temporary Redirect (status code) 56 |  | 307 Temporary Redirect (status code) 57 |
| 4 |  | 4 |
| 400 Bad Request (status code) 56 |  | 400 Bad Request (status code) 57 |
| 402 Payment Required (status code) 56 |  | 402 Payment Required (status code) 57 |
| 403 Forbidden (status code) 57 |  | 403 Forbidden (status code) 57 |
| 404 Not Found (status code) 57 |  | 404 Not Found (status code) 58 |
| 405 Method Not Allowed (status code) 57 |  | 405 Method Not Allowed (status code) 58 |
| 406 Not Acceptable (status code) 57 |  | 406 Not Acceptable (status code) 58 |
| 408 Request Timeout (status code) 58 |  | 408 Request Timeout (status code) 59 |
| 409 Conflict (status code) 58 |  | 409 Conflict (status code) 59 |
| 410 Gone (status code) 58 |  | 410 Gone (status code) 59 |
| 411 Length Required (status code) 59 |  | 411 Length Required (status code) 60 |
| 413 Request Representation Too Large (status code) 59 |  | 413 Payload Too Large (status code) 60 |
| 414 URI Too Long (status code) 59 |  | 414 URI Too Long (status code) 60 |
| 415 Unsupported Media Type (status code) 59 |  | 415 Unsupported Media Type (status code) 60 |
| 417 Expectation Failed (status code) 60 |  | 417 Expectation Failed (status code) 61 |
| 426 Upgrade Required (status code) 60 |  | 426 Upgrade Required (status code) 61 |
| 5 |  | 5 |
| 500 Internal Server Error (status code) 60 |  | 500 Internal Server Error (status code) 61 |
| 501 Not Implemented (status code) 60 |  | 501 Not Implemented (status code) 61 |
| 502 Bad Gateway (status code) 61 |  | 502 Bad Gateway (status code) 62 |
| 503 Service Unavailable (status code) 61 |  | 503 Service Unavailable (status code) 62 |
| 504 Gateway Timeout (status code) 61 |  | 504 Gateway Timeout (status code) 62 |
| 505 HTTP Version Not Supported (status code) 61 |  | 505 HTTP Version Not Supported (status code) 62 |
| A |  | A |
| Accept header field 38 |  | Accept header field 38 |
| Accept-Charset header field 41 |  | 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 69 |  | Allow header field 71 |
| C |  | C |
| cacheable 25 |  | cacheable 23 |
| compress (content coding) 12 |  | compress (content coding) 11 |
| CONNECT method 30 |  | conditional request 36 |
| content coding 12 |  | CONNECT method 29 |
| content negotiation 7 |  | content coding 11 |
|  |  | content negotiation 6 |
| Content-Encoding header field 12 |  | Content-Encoding header field 12 |
| Content-Language header field 14 |  | Content-Language header field 13 |
| Content-Location header field 16 |  | Content-Location header field 15 |
| Content-Transfer-Encoding header field 85 |  | Content-Transfer-Encoding header field 87 |
| Content-Type header field 11 |  | Content-Type header field 10 |
| D |  | D |
| Date header field 64 |  | Date header field 66 |
| deflate (content coding) 12 |  | deflate (content coding) 11 |
| DELETE method 30 |  | DELETE method 28 |
| E |  | E |
| Expect header field 34 |  | Expect header field 33 |
| Expect Values |  | Expect Values |
| 100-continue 35 |  | 100-continue 33 |
| F |  | F |
| From header field 44 |  | From header field 44 |
| G |  | G |
| GET method 25 |  | GET method 24 |
| Grammar |  | Grammar |
| Accept 39 |  | Accept 38 |
| Accept-Charset 41 |  | Accept-Charset 40 |
| Accept-Encoding 41 |  | Accept-Encoding 41 |
| accept-ext 39 |  | accept-ext 38 |
| Accept-Language 43 |  | Accept-Language 42 |
| accept-params 39 |  | accept-params 38 |
| Allow 69 |  | Allow 71 |
| asctime-date 64 |  | asctime-date 65 |
| attribute 9 |  | attribute 8 |
| charset 10 |  | charset 9 |
| codings 41 |  | codings 41 |
| content-coding 12 |  | content-coding 11 |
| Content-Encoding 13 |  | Content-Encoding 12 |
| Content-Language 14 |  | Content-Language 13 |
| Content-Location 16 |  | Content-Location 15 |
| Content-Type 11 |  | Content-Type 10 |
| Date 64 |  | Date 66 |
| date1 63 |  | date1 64 |
| day 63 |  | day 64 |
| day-name 63 |  | day-name 64 |
| day-name-l 63 |  | day-name-l 64 |
| delta-seconds 66 |  | delta-seconds 68 |
| Expect 34 |  | Expect 33 |
| expect-name 34 |  | expect-name 33 |
| expect-param 34 |  | expect-param 33 |
| expect-value 34 |  | expect-value 33 |
| expectation 34 |  | expectation 33 |
| From 44 |  | From 44 |
| GMT 63 |  | GMT 64 |
| hour 63 |  | hour 64 |
| HTTP-date 62 |  | HTTP-date 63 |
| language-range 43 |  | IMF-fixdate 64 |
| language-tag 14 |  | language-range 42 |
| Location 65 |  | language-tag 13 |
| Max-Forwards 34 |  | Location 66 |
| media-range 39 |  | Max-Forwards 36 |
| media-type 9 |  | media-range 38 |
| method 22 |  | media-type 8 |
| MIME-Version 84 |  | method 20 |
| minute 63 |  | minute 64 |
| month 63 |  | month 64 |
| obs-date 63 |  | obs-date 65 |
| parameter 9 |  | parameter 8 |
| product 22 |  | product 46 |
| product-version 22 |  | product-version 46 |
| qvalue 38 |  | qvalue 37 |
| Referer 45 |  | Referer 44 |
| Retry-After 66 |  | Retry-After 68 |
| rfc850-date 64 |  | rfc850-date 65 |
| rfc1123-date 63 |  | second 64 |
| second 63 |  | Server 71 |
| Server 69 |  | subtype 8 |
| subtype 9 |  | time-of-day 64 |
| time-of-day 63 |  | type 8 |
| type 9 |  | User-Agent 45 |
| User-Agent 46 |  | value 8 |
| value 9 |  | Vary 68 |
| Vary 67 |  | weight 37 |
| weight 38 |  | year 64 |
| year 63 |  | gzip (content coding) 11 |
| gzip (content coding) 12 |  |  |
| H |  | H |
| HEAD method 26 |  | HEAD method 24 |
| I |  | I |
| idempotent 25 |  | idempotent 23 |
| L |  | L |
| Location header field 65 |  | Location header field 66 |
| M |  | M |
| Max-Forwards header field 34 |  | Max-Forwards header field 36 |
| MIME-Version header field 84 |  | MIME-Version header field 86 |
| O |  | O |
| OPTIONS method 32 |  | OPTIONS method 31 |
| P |  | P |
| payload 18 |  | payload 17 |
| POST method 27 |  | POST method 25 |
| PUT method 28 |  | PUT method 26 |
| R |  | R |
| Referer header field 45 |  | Referer header field 44 |
| representation 8 |  | representation 7 |
| Retry-After header field 66 |  | Retry-After header field 68 |
| S |  | S |
| safe 24 |  | safe 22 |
| selected representation 67 |  | selected representation 7, 69 |
| Server header field 69 |  | Server header field 71 |
| Status Codes Classes |  | Status Codes Classes |
| 1xx Informational 49 |  | 1xx Informational 49 |
| 2xx Successful 50 |  | 2xx Successful 50 |
| 3xx Redirection 52 |  | 3xx Redirection 53 |
| 4xx Client Error 56 |  | 4xx Client Error 57 |
| 5xx Server Error 60 |  | 5xx Server Error 61 |
| T |  | T |
| TRACE method 33 |  | TRACE method 32 |
| U |  | U |
| User-Agent header field 45 |  | User-Agent header field 45 |
| V |  | V |
| Vary header field 67 |  | Vary header field 68 |
| X |  | X |
| x-compress (content coding) 12 |  | x-compress (content coding) 11 |
| x-gzip (content coding) 12 |  | 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 |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| EMail: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
End of changes. 608 change blocks.
| 2951 lines changed or deleted |  | 2397 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/