| p2-semantics.unpg.txt |  | rfc7231.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | Internet Engineering Task Force (IETF) R. Fielding, Ed. |
| Internet-Draft Adobe |  | Request for Comments: 7231 Adobe |
| Obsoletes: 2616 (if approved) J. Reschke, Ed. |  | Obsoletes: 2616 J. Reschke, Ed. |
| Updates: 2817 (if approved) greenbytes |  | Updates: 2817 greenbytes |
| Intended status: Standards Track June 6, 2014 |  | Category: Standards Track June 2014 |
| Expires: December 8, 2014 |  | ISSN: 2070-1721 |
| Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |  | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
| draft-ietf-httpbis-p2-semantics-latest |  |  |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is a stateless application- |  | The Hypertext Transfer Protocol (HTTP) is a stateless application- |
| level protocol for distributed, collaborative, hypertext information |  | level protocol for distributed, collaborative, hypertext information |
| systems. This document defines the semantics of HTTP/1.1 messages, |  | systems. This document defines the semantics of HTTP/1.1 messages, |
| as expressed by request methods, request header fields, response |  | as expressed by request methods, request header fields, response |
| status codes, and response header fields, along with the payload of |  | status codes, and response header fields, along with the payload of |
| messages (metadata and body content) and mechanisms for content |  | messages (metadata and body content) and mechanisms for content |
| negotiation. |  | negotiation. |
| Editorial Note (To be removed by RFC Editor) |  |  |
| Discussion of this draft takes place on the HTTPBIS working group |  |  |
| mailing list (ietf-http-wg@w3.org), which is archived at |  |  |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  |  |
| The current issues list is at |  |  |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  |  |
| documents (including fancy diffs) can be found at |  |  |
| <http://tools.ietf.org/wg/httpbis/>. |  |  |
| _This is a temporary document for the purpose of tracking the |  |  |
| editorial changes made during the AUTH48 (RFC publication) phase._ |  |  |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This is an Internet Standards Track document. |
| provisions of BCP 78 and BCP 79. |  |  |
| Internet-Drafts are working documents of the Internet Engineering |  |  |
| Task Force (IETF). Note that other groups may also distribute |  |  |
| working documents as Internet-Drafts. The list of current Internet- |  |  |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  |  |
| Internet-Drafts are draft documents valid for a maximum of six months |  | This document is a product of the Internet Engineering Task Force |
| and may be updated, replaced, or obsoleted by other documents at any |  | (IETF). It represents the consensus of the IETF community. It has |
| time. It is inappropriate to use Internet-Drafts as reference |  | received public review and has been approved for publication by the |
| material or to cite them other than as "work in progress." |  | Internet Engineering Steering Group (IESG). Further information on |
|  |  | Internet Standards is available in Section 2 of RFC 5741. |
| This Internet-Draft will expire on December 8, 2014. |  | Information about the current status of this document, any errata, |
|  |  | and how to provide feedback on it may be obtained at |
|  |  | http://www.rfc-editor.org/info/rfc7231. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2014 IETF Trust and the persons identified as the |  | Copyright (c) 2014 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| skipping to change at page 2, line 37 |  | skipping to change at page 3, line 7 |
| 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1. Introduction ....................................................6 |
| 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 6 |  | 1.1. Conformance and Error Handling .............................6 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.2. Syntax Notation ............................................6 |
| 2. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 2. Resources .......................................................7 |
| 3. Representations . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 3. Representations .................................................7 |
| 3.1. Representation Metadata . . . . . . . . . . . . . . . . . 8 |  | 3.1. Representation Metadata ....................................8 |
| 3.1.1. Processing Representation Data . . . . . . . . . . . . 8 |  | 3.1.1. Processing Representation Data ......................8 |
| 3.1.2. Encoding for Compression or Integrity . . . . . . . . 11 |  | 3.1.2. Encoding for Compression or Integrity ..............11 |
| 3.1.3. Audience Language . . . . . . . . . . . . . . . . . . 13 |  | 3.1.3. Audience Language ..................................13 |
| 3.1.4. Identification . . . . . . . . . . . . . . . . . . . . 14 |  | 3.1.4. Identification .....................................14 |
| 3.2. Representation Data . . . . . . . . . . . . . . . . . . . 17 |  | 3.2. Representation Data .......................................17 |
| 3.3. Payload Semantics . . . . . . . . . . . . . . . . . . . . 17 |  | 3.3. Payload Semantics .........................................17 |
| 3.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 18 |  | 3.4. Content Negotiation .......................................18 |
| 3.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 19 |  | 3.4.1. Proactive Negotiation ..............................19 |
| 3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . . 20 |  | 3.4.2. Reactive Negotiation ...............................20 |
|  |  | 4. Request Methods ................................................21 |
|  |  | 4.1. Overview ..................................................21 |
|  |  | 4.2. Common Method Properties ..................................22 |
|  |  | 4.2.1. Safe Methods .......................................22 |
|  |  | 4.2.2. Idempotent Methods .................................23 |
|  |  | 4.2.3. Cacheable Methods ..................................24 |
|  |  | 4.3. Method Definitions ........................................24 |
|  |  | 4.3.1. GET ................................................24 |
|  |  | 4.3.2. HEAD ...............................................25 |
|  |  | 4.3.3. POST ...............................................25 |
|  |  | 4.3.4. PUT ................................................26 |
|  |  | 4.3.5. DELETE .............................................29 |
|  |  | 4.3.6. CONNECT ............................................30 |
|  |  | 4.3.7. OPTIONS ............................................31 |
|  |  | 4.3.8. TRACE ..............................................32 |
|  |  | 5. Request Header Fields ..........................................33 |
|  |  | 5.1. Controls ..................................................33 |
|  |  | 5.1.1. Expect .............................................34 |
|  |  | 5.1.2. Max-Forwards .......................................36 |
|  |  | 5.2. Conditionals ..............................................36 |
|  |  | 5.3. Content Negotiation .......................................37 |
|  |  | 5.3.1. Quality Values .....................................37 |
|  |  | 5.3.2. Accept .............................................38 |
|  |  | 5.3.3. Accept-Charset .....................................40 |
|  |  | 5.3.4. Accept-Encoding ....................................41 |
|  |  | 5.3.5. Accept-Language ....................................42 |
|  |  | 5.4. Authentication Credentials ................................44 |
|  |  | 5.5. Request Context ...........................................44 |
|  |  | 5.5.1. From ...............................................44 |
|  |  | 5.5.2. Referer ............................................45 |
|  |  | 5.5.3. User-Agent .........................................46 |
| 4. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 21 |  | 6. Response Status Codes ..........................................47 |
| 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21 |  | 6.1. Overview of Status Codes ..................................48 |
| 4.2. Common Method Properties . . . . . . . . . . . . . . . . . 22 |  | 6.2. Informational 1xx .........................................50 |
| 4.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 22 |  | 6.2.1. 100 Continue .......................................50 |
| 4.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 23 |  | 6.2.2. 101 Switching Protocols ............................50 |
| 4.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 24 |  | 6.3. Successful 2xx ............................................51 |
| 4.3. Method Definitions . . . . . . . . . . . . . . . . . . . . 24 |  | 6.3.1. 200 OK .............................................51 |
| 4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24 |  | 6.3.2. 201 Created ........................................52 |
| 4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 6.3.3. 202 Accepted .......................................52 |
| 4.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 6.3.4. 203 Non-Authoritative Information ..................52 |
| 4.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 26 |  | 6.3.5. 204 No Content .....................................53 |
| 4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29 |  | 6.3.6. 205 Reset Content ..................................53 |
| 4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 30 |  | 6.4. Redirection 3xx ...........................................54 |
| 4.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 31 |  | 6.4.1. 300 Multiple Choices ...............................55 |
| 4.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 6.4.2. 301 Moved Permanently ..............................56 |
| 5. Request Header Fields . . . . . . . . . . . . . . . . . . . . 33 |  | 6.4.3. 302 Found ..........................................56 |
| 5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 6.4.4. 303 See Other ......................................57 |
| 5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 34 |  | 6.4.5. 305 Use Proxy ......................................58 |
| 5.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36 |  | 6.4.6. 306 (Unused) .......................................58 |
| 5.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36 |  | 6.4.7. 307 Temporary Redirect .............................58 |
| 5.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 37 |  | 6.5. Client Error 4xx ..........................................58 |
| 5.3.1. Quality Values . . . . . . . . . . . . . . . . . . . . 37 |  | 6.5.1. 400 Bad Request ....................................58 |
| 5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38 |  | 6.5.2. 402 Payment Required ...............................59 |
| 5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40 |  | 6.5.3. 403 Forbidden ......................................59 |
| 5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41 |  | 6.5.4. 404 Not Found ......................................59 |
| 5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42 |  | 6.5.5. 405 Method Not Allowed .............................59 |
| 5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43 |  | 6.5.6. 406 Not Acceptable .................................60 |
| 5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 44 |  | 6.5.7. 408 Request Timeout ................................60 |
| 5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44 |  | 6.5.8. 409 Conflict .......................................60 |
| 5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 45 |  | 6.5.9. 410 Gone ...........................................60 |
| 5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 46 |  | 6.5.10. 411 Length Required ...............................61 |
| 6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47 |  | 6.5.11. 413 Payload Too Large .............................61 |
| 6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 48 |  | 6.5.12. 414 URI Too Long ..................................61 |
| 6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 50 |  | 6.5.13. 415 Unsupported Media Type ........................62 |
| 6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 50 |  | 6.5.14. 417 Expectation Failed ............................62 |
| 6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50 |  | 6.5.15. 426 Upgrade Required ..............................62 |
| 6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.6. Server Error 5xx ..........................................62 |
| 6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.6.1. 500 Internal Server Error ..........................63 |
| 6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 51 |  | 6.6.2. 501 Not Implemented ................................63 |
| 6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 52 |  | 6.6.3. 502 Bad Gateway ....................................63 |
| 6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 52 |  | 6.6.4. 503 Service Unavailable ............................63 |
| 6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 53 |  | 6.6.5. 504 Gateway Timeout ................................63 |
| 6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 53 |  | 6.6.6. 505 HTTP Version Not Supported .....................64 |
| 6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 54 |  | 7. Response Header Fields .........................................64 |
| 6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 55 |  | 7.1. Control Data ..............................................64 |
| 6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 56 |  | 7.1.1. Origination Date ...................................65 |
| 6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 56 |  | 7.1.2. Location ...........................................68 |
| 6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 57 |  | 7.1.3. Retry-After ........................................69 |
| 6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 57 |  | 7.1.4. Vary ...............................................70 |
| 6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 57 |  | 7.2. Validator Header Fields ...................................71 |
| 6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 58 |  | 7.3. Authentication Challenges .................................72 |
| 6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58 |  | 7.4. Response Context ..........................................72 |
| 6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 58 |  | 7.4.1. Allow ..............................................72 |
| 6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 58 |  | 7.4.2. Server .............................................73 |
| 6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 58 |  | 8. IANA Considerations ............................................73 |
| 6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 59 |  | 8.1. Method Registry ...........................................73 |
| 6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 59 |  | 8.1.1. Procedure ..........................................74 |
| 6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 59 |  | 8.1.2. Considerations for New Methods .....................74 |
| 6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 60 |  | 8.1.3. Registrations ......................................75 |
| 6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 60 |  | 8.2. Status Code Registry ......................................75 |
| 6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60 |  | 8.2.1. Procedure ..........................................75 |
| 6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 61 |  | 8.2.2. Considerations for New Status Codes ................76 |
| 6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 61 |  | 8.2.3. Registrations ......................................76 |
| 6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61 |  | 8.3. Header Field Registry .....................................77 |
| 6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 61 |  | 8.3.1. Considerations for New Header Fields ...............78 |
| 6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62 |  | 8.3.2. Registrations ......................................80 |
| 6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62 |  | 8.4. Content Coding Registry ...................................81 |
| 6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62 |  | 8.4.1. Procedure ..........................................81 |
| 6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 62 |  | 8.4.2. Registrations ......................................81 |
| 6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 63 |  | 9. Security Considerations ........................................81 |
| 6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 63 |  | 9.1. Attacks Based on File and Path Names ......................82 |
| 6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 63 |  | 9.2. Attacks Based on Command, Code, or Query Injection ........82 |
| 6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 63 |  | 9.3. Disclosure of Personal Information ........................83 |
| 6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 63 |  | 9.4. Disclosure of Sensitive Information in URIs ...............83 |
| 7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 64 |  | 9.5. Disclosure of Fragment after Redirects ....................84 |
| 7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 64 |  | 9.6. Disclosure of Product Information .........................84 |
| 7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 64 |  | 9.7. Browser Fingerprinting ....................................84 |
| 7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 68 |  | 10. Acknowledgments ...............................................85 |
| 7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69 |  | 11. References ....................................................85 |
| 7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70 |  | 11.1. Normative References .....................................85 |
| 7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71 |  | 11.2. Informative References ...................................86 |
| 7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72 |  | Appendix A. Differences between HTTP and MIME .....................89 |
| 7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 72 |  | A.1. MIME-Version ..............................................89 |
| 7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72 |  | A.2. Conversion to Canonical Form ..............................89 |
| 7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 73 |  | A.3. Conversion of Date Formats ................................90 |
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 |  | A.4. Conversion of Content-Encoding ..........................90 |
| 8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 74 |  | A.5. Conversion of Content-Transfer-Encoding .................90 |
| 8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 74 |  | A.6. MHTML and Line Length Limitations .........................90 |
| 8.1.2. Considerations for New Methods . . . . . . . . . . . . 74 |  | Appendix B. Changes from RFC 2616 .................................91 |
| 8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 75 |  | Appendix C. Imported ABNF .........................................93 |
| 8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 75 |  | Appendix D. Collected ABNF ........................................94 |
| 8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 75 |  | Index .............................................................97 |
| 8.2.2. Considerations for New Status Codes . . . . . . . . . 76 |  |  |
| 8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 76 |  |  |
| 8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77 |  |  |
| 8.3.1. Considerations for New Header Fields . . . . . . . . . 78 |  |  |
| 8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80 |  |  |
| 8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80 |  |  |
| 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 81 |  |  |
| 8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81 |  |  |
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 81 |  |  |
| 9.1. Attacks Based on File and Path Names . . . . . . . . . . . 82 |  |  |
| 9.2. Attacks Based on Command, Code, or Query Injection . . . . 82 |  |  |
| 9.3. Disclosure of Personal Information . . . . . . . . . . . . 83 |  |  |
| 9.4. Disclosure of Sensitive Information in URIs . . . . . . . 83 |  |  |
| 9.5. Disclosure of Fragment after Redirects . . . . . . . . . . 83 |  |  |
| 9.6. Disclosure of Product Information . . . . . . . . . . . . 84 |  |  |
| 9.7. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 84 |  |  |
| 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85 |  |  |
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85 |  |  |
| 11.1. Normative References . . . . . . . . . . . . . . . . . . . 85 |  |  |
| 11.2. Informative References . . . . . . . . . . . . . . . . . . 86 |  |  |
| Appendix A. Differences between HTTP and MIME . . . . . . . . . . 88 |  |  |
| A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 89 |  |  |
| A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 89 |  |  |
| A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 89 |  |  |
| A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 89 |  |  |
| A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 90 |  |  |
| A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 90 |  |  |
| Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 90 |  |  |
| Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 93 |  |  |
| Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 93 |  |  |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 |  |  |
| 1. Introduction |  | 1. Introduction |
| Each Hypertext Transfer Protocol (HTTP) message is either a request |  | Each Hypertext Transfer Protocol (HTTP) message is either a request |
| or a response. A server listens on a connection for a request, |  | or a response. A server listens on a connection for a request, |
| parses each message received, interprets the message semantics in |  | parses each message received, interprets the message semantics in |
| relation to the identified request target, and responds to that |  | relation to the identified request target, and responds to that |
| request with one or more response messages. A client constructs |  | request with one or more response messages. A client constructs |
| request messages to communicate specific intentions, examines |  | request messages to communicate specific intentions, examines |
| received responses to see if the intentions were carried out, and |  | received responses to see if the intentions were carried out, and |
| skipping to change at page 7, line 25 |  | skipping to change at page 7, line 25 |
| Section 2.7 of [RFC7230]. |  | Section 2.7 of [RFC7230]. |
| 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 |
| [RFC7230]). When a request is received, the server reconstructs an |  | [RFC7230]). 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 |
| [RFC7230]). |  | [RFC7230]). |
| One design goal of HTTP is to separate resource identification from |  | One design goal of HTTP is to separate resource identification from |
| request semantics, which is made possible by vesting the request |  | request semantics, which is made possible by vesting the request |
| semantics in the request method (Section 4) and a few request- |  | semantics in the request method (Section 4) and a few |
| modifying header fields (Section 5). If there is a conflict between |  | request-modifying header fields (Section 5). If there is a conflict |
| the method semantics and any semantic implied by the URI itself, as |  | between the method semantics and any semantic implied by the URI |
| described in Section 4.2.1, the method semantics take precedence. |  | itself, as described in Section 4.2.1, the method semantics take |
|  |  | precedence. |
| 3. Representations |  | 3. Representations |
| Considering that a resource could be anything, and that the uniform |  | Considering that a resource could be anything, and that the uniform |
| interface provided by HTTP is similar to a window through which one |  | interface provided by HTTP is similar to a window through which one |
| can observe and act upon such a thing only through the communication |  | can observe and act upon such a thing only through the communication |
| of messages to some independent actor on the other side, an |  | of messages to some independent actor on the other side, an |
| abstraction is needed to represent ("take the place of") the current |  | abstraction is needed to represent ("take the place of") the current |
| or desired state of that thing in our communications. That |  | or desired state of that thing in our communications. That |
| abstraction is called a representation [REST]. |  | abstraction is called a representation [REST]. |
| skipping to change at page 13, line 14 |  | skipping to change at page 13, line 21 |
| 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. |  | languages are explicitly excluded. |
| HTTP uses language tags within the Accept-Language and Content- |  | HTTP uses language tags within the Accept-Language and |
| Language header fields. Accept-Language uses the broader language- |  | Content-Language header fields. Accept-Language uses the broader |
| range production defined in Section 5.3.5, whereas Content-Language |  | language-range production defined in Section 5.3.5, whereas |
| uses the language-tag production defined below. |  | Content-Language uses the language-tag production defined below. |
| language-tag = <Language-Tag, see [RFC5646], Section 2.1> |  | language-tag = <Language-Tag, see [RFC5646], Section 2.1> |
| A language tag is a sequence of one or more case-insensitive subtags, |  | A language tag is a sequence of one or more case-insensitive subtags, |
| each separated by a hyphen character ("-", %x2D). In most cases, a |  | each separated by a hyphen character ("-", %x2D). In most cases, a |
| language tag consists of a primary language subtag that identifies a |  | language tag consists of a primary language subtag that identifies a |
| broad family of related languages (e.g., "en" = English), which is |  | broad family of related languages (e.g., "en" = English), which is |
| optionally followed by a series of subtags that refine or narrow that |  | optionally followed by a series of subtags that refine or narrow that |
| language's range (e.g., "en-CA" = the variety of English as |  | language's range (e.g., "en-CA" = the variety of English as |
| communicated in Canada). Whitespace is not allowed within a language |  | communicated in Canada). Whitespace is not allowed within a language |
| skipping to change at page 16, line 18 |  | skipping to change at page 16, line 29 |
| If Content-Location is included in a 2xx (Successful) response |  | If Content-Location is included in a 2xx (Successful) response |
| message and its field-value refers to a URI that differs from the |  | message and its field-value refers to a URI that differs from the |
| effective request URI, then the origin server claims that the URI is |  | effective request URI, then the origin server claims that the URI is |
| an identifier for a different resource corresponding to the enclosed |  | an identifier for a different resource corresponding to the enclosed |
| representation. Such a claim can only be trusted if both identifiers |  | representation. Such a claim can only be trusted if both identifiers |
| share the same resource owner, which cannot be programmatically |  | share the same resource owner, which cannot be programmatically |
| determined via HTTP. |  | determined via HTTP. |
| o For a response to a GET or HEAD request, this is an indication |  | o For a response to a GET or HEAD request, this is an indication |
| that the effective request URI refers to 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 |
| value is a more specific identifier for the selected |  | field-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 |
| skipping to change at page 21, line 39 |  | skipping to change at page 21, line 47 |
| 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 ought to 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 US- |  | convention, standardized methods are defined in all-uppercase |
| ASCII letters. |  | US-ASCII letters. |
| +---------+-------------------------------------------------+-------+ |  | +---------+-------------------------------------------------+-------+ |
| | Method | Description | Sec. | |  | | Method | Description | Sec. | |
| +---------+-------------------------------------------------+-------+ |  | +---------+-------------------------------------------------+-------+ |
| | GET | Transfer a current representation of the target | 4.3.1 | |  | | GET | Transfer a current representation of the target | 4.3.1 | |
| | | resource. | | |  | | | resource. | | |
| | HEAD | Same as GET, but only transfer the status line | 4.3.2 | |  | | HEAD | Same as GET, but only transfer the status line | 4.3.2 | |
| | | and header section. | | |  | | | and header section. | | |
| | POST | Perform resource-specific processing on the | 4.3.3 | |  | | POST | Perform resource-specific processing on the | 4.3.3 | |
| | | request payload. | | |  | | | request payload. | | |
| skipping to change at page 26, line 29 |  | skipping to change at page 26, line 32 |
| SHOULD send a 201 (Created) response containing a Location header |  | SHOULD send a 201 (Created) response containing a Location header |
| field that provides an identifier for the primary resource created |  | field that provides an identifier for the primary resource created |
| (Section 7.1.2) and a representation that describes the status of the |  | (Section 7.1.2) and a representation that describes the status of the |
| request while referring to the new resource(s). |  | 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.2.1 of [RFC7234]). |  | explicit freshness information (see Section 4.2.1 of [RFC7234]). |
| However, POST caching is not widely implemented. For cases where an |  | However, POST caching is not widely implemented. For cases where an |
| origin server wishes the client to be able to cache the result of a |  | origin server wishes the client to be able to cache the result of a |
| POST in a way that can be reused by a later GET, the origin server |  | 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- |  | MAY send a 200 (OK) response containing the result and a |
| Location header field that has the same value as the POST's effective |  | Content-Location header field that has the same value as the POST's |
| request URI (Section 3.1.4.2). |  | effective request URI (Section 3.1.4.2). |
| If the result of processing a POST would be equivalent to a |  | If the result of processing a POST would be equivalent to a |
| representation of an existing resource, an origin server MAY redirect |  | representation of an existing resource, an origin server MAY redirect |
| the user agent to that resource by sending a 303 (See Other) response |  | the user agent to that resource by sending a 303 (See Other) response |
| with the existing resource's identifier in the Location field. This |  | with the existing resource's identifier in the Location field. This |
| has the benefits of providing the user agent a resource identifier |  | has the benefits of providing the user agent a resource identifier |
| and transferring the representation via a method more amenable to |  | and transferring the representation via a method more amenable to |
| shared caching, though at the cost of an extra request if the user |  | shared caching, though at the cost of an extra request if the user |
| agent does not already have the representation cached. |  | agent does not already have the representation cached. |
| skipping to change at page 34, line 22 |  | skipping to change at page 34, line 22 |
| Expect = "100-continue" |  | Expect = "100-continue" |
| The Expect field-value is case-insensitive. |  | The Expect field-value is case-insensitive. |
| A server that receives an Expect field-value other than 100-continue |  | A server that receives an Expect field-value other than 100-continue |
| MAY respond with a 417 (Expectation Failed) status code to indicate |  | MAY respond with a 417 (Expectation Failed) status code to indicate |
| that the unexpected expectation cannot be met. |  | that the unexpected expectation cannot be met. |
| A 100-continue expectation informs recipients that the client is |  | A 100-continue expectation informs recipients that the client is |
| about to send a (presumably large) message body in this request and |  | about to send a (presumably large) message body in this request and |
| wishes to receive a 100 (Continue) interim response if the request- |  | wishes to receive a 100 (Continue) interim response if the |
| line and header fields are not sufficient to cause an immediate |  | request-line and header fields are not sufficient to cause an |
| success, redirect, or error response. This allows the client to wait |  | immediate success, redirect, or error response. This allows the |
| for an indication that it is worthwhile to send the message body |  | client to wait for an indication that it is worthwhile to send the |
| before actually doing so, which can improve efficiency when the |  | message body before actually doing so, which can improve efficiency |
| message body is huge or when the client anticipates that an error is |  | when the message body is huge or when the client anticipates that an |
| likely (e.g., when sending a state-changing method, for the first |  | error is likely (e.g., when sending a state-changing method, for the |
| time, without previously verified authentication credentials). |  | first time, without previously verified authentication credentials). |
| For example, a request that begins with |  | For example, a request that begins with |
| PUT /somewhere/fun HTTP/1.1 |  | PUT /somewhere/fun HTTP/1.1 |
| Host: origin.example.com |  | Host: origin.example.com |
| Content-Type: video/h264 |  | Content-Type: video/h264 |
| Content-Length: 1234567890987 |  | Content-Length: 1234567890987 |
| Expect: 100-continue |  | Expect: 100-continue |
| allows the origin server to immediately respond with an error |  | allows the origin server to immediately respond with an error |
| skipping to change at page 35, line 37 |  | skipping to change at page 35, line 37 |
| o A server that sends a 100 (Continue) response MUST ultimately send |  | o A server that sends a 100 (Continue) response MUST ultimately send |
| a final status code, once the message body is received and |  | a final status code, once the message body is received and |
| processed, unless the connection is closed prematurely. |  | processed, unless the connection is closed prematurely. |
| o A server that responds with a final status code before reading the |  | o A server that responds with a final status code before reading the |
| entire message body SHOULD indicate in that response whether it |  | entire message body SHOULD indicate in that response whether it |
| intends to close the connection or continue reading and discarding |  | intends to close the connection or continue reading and discarding |
| the request message (see Section 6.6 of [RFC7230]). |  | the request message (see Section 6.6 of [RFC7230]). |
| An origin server MUST, upon receiving an HTTP/1.1 (or later) request- |  | An origin server MUST, upon receiving an HTTP/1.1 (or later) |
| line and a complete header section that contains a 100-continue |  | request-line and a complete header section that contains a |
| expectation and indicates a request message body will follow, either |  | 100-continue expectation and indicates a request message body will |
| send an immediate response with a final status code, if that status |  | follow, either send an immediate response with a final status code, |
| can be determined by examining just the request-line and header |  | if that status can be determined by examining just the request-line |
| fields, or send an immediate 100 (Continue) response to encourage the |  | and header fields, or send an immediate 100 (Continue) response to |
| client to send the request's message body. The origin server MUST |  | encourage the client to send the request's message body. The origin |
| NOT wait for the message body before sending the 100 (Continue) |  | server MUST NOT wait for the message body before sending the 100 |
| response. |  | (Continue) response. |
| A proxy MUST, upon receiving an HTTP/1.1 (or later) request-line and |  | A proxy MUST, upon receiving an HTTP/1.1 (or later) request-line and |
| a complete header section that contains a 100-continue expectation |  | a complete header section that contains a 100-continue expectation |
| and indicates a request message body will follow, either send an |  | and indicates a request message body will follow, either send an |
| immediate response with a final status code, if that status can be |  | immediate response with a final status code, if that status can be |
| determined by examining just the request-line and header fields, or |  | determined by examining just the request-line and header fields, or |
| begin forwarding the request toward the origin server by sending a |  | begin forwarding the request toward the origin server by sending a |
| corresponding request-line and header section to the next inbound |  | corresponding request-line and header section to the next inbound |
| server. If the proxy believes (from configuration or past |  | server. If the proxy believes (from configuration or past |
| interaction) that the next inbound server only supports HTTP/1.0, the |  | interaction) that the next inbound server only supports HTTP/1.0, the |
| skipping to change at page 38, line 23 |  | skipping to change at page 38, line 23 |
| 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. |
| 5.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 |
| line image. |  | in-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 [ "=" ( token / quoted-string ) ] |  | accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] |
| skipping to change at page 40, line 44 |  | skipping to change at page 40, line 44 |
| Accept-Charset = 1#( ( charset / "*" ) [ weight ] ) |  | Accept-Charset = 1#( ( charset / "*" ) [ weight ] ) |
| Charset names are defined in Section 3.1.1.2. A user agent MAY |  | Charset names are defined in Section 3.1.1.2. A user agent MAY |
| associate a quality value with each charset to indicate the user's |  | associate a quality value with each charset to indicate the user's |
| relative preference for that charset, as defined in Section 5.3.1. |  | relative preference for that charset, as defined in Section 5.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 charset that is not mentioned elsewhere in the Accept- |  | matches every charset that is not mentioned elsewhere in the |
| Charset field. If no "*" is present in an Accept-Charset field, then |  | Accept-Charset field. If no "*" is present in an Accept-Charset |
| any charsets not explicitly mentioned in the field are considered |  | field, then any charsets not explicitly mentioned in the field are |
| "not acceptable" to the client. |  | considered "not acceptable" to the client. |
| A request without any Accept-Charset header field implies that the |  | A request without any Accept-Charset header field implies that the |
| user agent will accept any charset in response. Most general-purpose |  | user agent will accept any charset in response. Most general-purpose |
| user agents do not send Accept-Charset, unless specifically |  | user agents do not send Accept-Charset, unless specifically |
| configured to do so, because a detailed list of supported charsets |  | configured to do so, because a detailed list of supported charsets |
| makes it easier for a server to identify an individual by virtue of |  | makes it easier for a server to identify an individual by virtue of |
| the user agent's request characteristics (Section 9.7). |  | the user agent's request characteristics (Section 9.7). |
| If an Accept-Charset header field is present in a request and none of |  | If an Accept-Charset header field is present in a request and none of |
| the available representations for the response has a charset that is |  | the available representations for the response has a charset that is |
| skipping to change at page 42, line 6 |  | skipping to change at page 42, line 6 |
| does not imply that the user agent will be able to correctly process |  | does not imply that the user agent will be able to correctly process |
| all encodings. |  | 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 using these rules: |  | acceptable using these rules: |
| 1. If no Accept-Encoding field is in the request, any content-coding |  | 1. If no Accept-Encoding field is in the request, any content-coding |
| is considered acceptable by the user agent. |  | is considered acceptable by the user agent. |
| 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 |
| Encoding field stating either "identity;q=0" or "*;q=0" without a |  | Accept-Encoding field stating either "identity;q=0" or "*;q=0" |
| more specific entry for "identity". |  | without a 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 |
| codings listed in the Accept-Encoding field, then it is |  | content-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 5.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 |
| skipping to change at page 43, line 32 |  | skipping to change at page 43, line 32 |
| was previously defined for HTTP in Section 14.4 of [RFC2616]. |  | was previously defined for HTTP in Section 14.4 of [RFC2616]. |
| It might be contrary to the privacy expectations of the user to send |  | It might be contrary to the privacy expectations of the user to send |
| an Accept-Language header field with the complete linguistic |  | an Accept-Language header field with the complete linguistic |
| preferences of the user in every request (Section 9.7). |  | preferences of the user in every request (Section 9.7). |
| Since intelligibility is highly dependent on the individual user, |  | Since intelligibility is highly dependent on the individual user, |
| user agents need to allow user control over the linguistic preference |  | user agents need to allow user control over the linguistic preference |
| (either through configuration of the user agent itself or by |  | (either through configuration of the user agent itself or by |
| defaulting to a user controllable system setting). A user agent that |  | defaulting to a user controllable system setting). A user agent that |
| does not provide such control to the user MUST NOT send an Accept- |  | does not provide such control to the user MUST NOT send an |
| Language header field. |  | Accept-Language header field. |
| Note: User agents ought to provide guidance to users when setting |  | Note: User agents ought to provide guidance to users when setting |
| a preference, since users are rarely familiar with the details of |  | a preference, since users are rarely familiar with the details of |
| language matching as described above. For example, users might |  | language matching as described above. For example, users might |
| assume that on selecting "en-gb", they will be served any kind of |  | assume that on selecting "en-gb", they will be served any kind of |
| English document if British English is not available. A user |  | English document if British English is not available. A user |
| agent might suggest, in such a case, to add "en" to the list for |  | agent might suggest, in such a case, to add "en" to the list for |
| better matching behavior. |  | better matching behavior. |
| 5.4. Authentication Credentials |  | 5.4. Authentication Credentials |
| skipping to change at page 46, line 36 |  | skipping to change at page 46, line 43 |
| listed in decreasing order of their significance for identifying the |  | listed in decreasing order of their significance for identifying the |
| user agent software. Each product identifier consists of a name and |  | user agent software. Each product identifier consists of a name and |
| optional version. |  | optional version. |
| product = token ["/" product-version] |  | product = token ["/" product-version] |
| product-version = token |  | product-version = token |
| A sender SHOULD limit generated product identifiers to what is |  | A sender SHOULD limit generated product identifiers to what is |
| necessary to identify the product; a sender MUST NOT generate |  | necessary to identify the product; a sender MUST NOT generate |
| advertising or other nonessential information within the product |  | advertising or other nonessential information within the product |
| identifier. A sender SHOULD NOT generate information in product- |  | identifier. A sender SHOULD NOT generate information in |
| version that is not a version identifier (i.e., successive versions |  | product-version that is not a version identifier (i.e., successive |
| of the same product name ought to differ only in the product-version |  | versions of the same product name ought to differ only in the |
| portion of the product identifier). |  | 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 |
| A user agent SHOULD NOT generate a User-Agent field containing |  | A user agent SHOULD NOT generate a User-Agent field containing |
| needlessly fine-grained detail and SHOULD limit the addition of |  | needlessly fine-grained detail and SHOULD limit the addition of |
| subproducts by third parties. Overly long and detailed User-Agent |  | subproducts by third parties. Overly long and detailed User-Agent |
| field values increase request latency and the risk of a user being |  | field values increase request latency and the risk of a user being |
| identified against their wishes ("fingerprinting"). |  | identified against their wishes ("fingerprinting"). |
| skipping to change at page 50, line 33 |  | skipping to change at page 50, line 35 |
| "Expect: 100-continue" field when it forwards a request, then it need |  | "Expect: 100-continue" field when it forwards a request, then it need |
| not forward the corresponding 100 (Continue) response(s). |  | not forward the corresponding 100 (Continue) response(s). |
| 6.2.1. 100 Continue |  | 6.2.1. 100 Continue |
| The 100 (Continue) status code indicates that the initial part of a |  | The 100 (Continue) status code indicates that the initial part of a |
| request has been received and has not yet been rejected by the |  | request has been received and has not yet been rejected by the |
| server. The server intends to send a final response after the |  | server. The server intends to send a final response after the |
| request has been fully received and acted upon. |  | request has been fully received and acted upon. |
| When the request contains an Expect header field that includes a 100- |  | When the request contains an Expect header field that includes a |
| continue expectation, the 100 response indicates that the server |  | 100-continue expectation, the 100 response indicates that the server |
| wishes to receive the request payload body, as described in |  | wishes to receive the request payload body, as described in |
| Section 5.1.1. The client ought to continue sending the request and |  | Section 5.1.1. The client ought to continue sending the request and |
| discard the 100 response. |  | discard the 100 response. |
| If the request did not contain an Expect header field containing the |  | If the request did not contain an Expect header field containing the |
| 100-continue expectation, the client can simply discard this interim |  | 100-continue expectation, the client can simply discard this interim |
| response. |  | response. |
| 6.2.2. 101 Switching Protocols |  | 6.2.2. 101 Switching Protocols |
| skipping to change at page 52, line 10 |  | skipping to change at page 52, line 15 |
| 6.3.2. 201 Created |  | 6.3.2. 201 Created |
| The 201 (Created) status code indicates that the request has been |  | The 201 (Created) status code indicates that the request has been |
| fulfilled and has resulted in one or more new resources being |  | fulfilled and has resulted in one or more new resources being |
| created. The primary resource created by the request is identified |  | created. The primary resource created by the request is identified |
| by either a Location header field in the response or, if no Location |  | by either a Location header field in the response or, if no Location |
| field is received, by the effective request URI. |  | field is received, by the effective request URI. |
| The 201 response payload typically describes and links to the |  | The 201 response payload typically describes and links to the |
| resource(s) created. See Section 7.2 for a discussion of the meaning |  | resource(s) created. See Section 7.2 for a discussion of the meaning |
| and purpose of validator header fields, such as ETag and Last- |  | and purpose of validator header fields, such as ETag and |
| Modified, in a 201 response. |  | Last-Modified, in a 201 response. |
| 6.3.3. 202 Accepted |  | 6.3.3. 202 Accepted |
| The 202 (Accepted) status code indicates that the request has been |  | The 202 (Accepted) status code indicates that the request has been |
| accepted for processing, but the processing has not been completed. |  | accepted for processing, but the processing has not been completed. |
| The request might or might not eventually be acted upon, as it might |  | The request might or might not eventually be acted upon, as it might |
| be disallowed when processing actually takes place. There is no |  | be disallowed when processing actually takes place. There is no |
| facility in HTTP for re-sending a status code from an asynchronous |  | facility in HTTP for re-sending a status code from an asynchronous |
| operation. |  | operation. |
| skipping to change at page 61, line 26 |  | skipping to change at page 61, line 37 |
| it adds a valid Content-Length header field containing the length of |  | it adds a valid Content-Length header field containing the length of |
| the message body in the request message. |  | the message body in the request message. |
| 6.5.11. 413 Payload Too Large |  | 6.5.11. 413 Payload Too Large |
| The 413 (Payload Too Large) status code indicates that the server is |  | The 413 (Payload Too Large) status code indicates that the server is |
| refusing to process a request because the request payload is larger |  | refusing to process a request because the request payload is larger |
| than the server is willing or able to process. The server MAY close |  | than the server is willing or able to process. The server MAY close |
| the connection to prevent the client from continuing the request. |  | the connection to prevent the client from continuing the request. |
| If the condition is temporary, the server SHOULD generate a Retry- |  | If the condition is temporary, the server SHOULD generate a |
| After header field to indicate that it is temporary and after what |  | Retry-After header field to indicate that it is temporary and after |
| time the client MAY try again. |  | what time the client MAY try again. |
| 6.5.12. 414 URI Too Long |  | 6.5.12. 414 URI Too Long |
| The 414 (URI Too Long) status code indicates that the server is |  | The 414 (URI Too Long) status code indicates that the server is |
| refusing to service the request because the request-target (Section |  | refusing to service the request because the request-target (Section |
| 5.3 of [RFC7230]) is longer than the server is willing to interpret. |  | 5.3 of [RFC7230]) is longer than the server is willing to interpret. |
| This rare condition is only likely to occur when a client has |  | This rare condition is only likely to occur when a client has |
| improperly converted a POST request to a GET request with long query |  | improperly converted a POST request to a GET request with long query |
| information, when the client has descended into a "black hole" of |  | 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 |
| skipping to change at page 61, line 51 |  | skipping to change at page 62, line 14 |
| A 414 response is cacheable by default; i.e., unless otherwise |  | A 414 response is cacheable by default; i.e., unless otherwise |
| indicated by the method definition or explicit cache controls (see |  | indicated by the method definition or explicit cache controls (see |
| Section 4.2.2 of [RFC7234]). |  | Section 4.2.2 of [RFC7234]). |
| 6.5.13. 415 Unsupported Media Type |  | 6.5.13. 415 Unsupported Media Type |
| The 415 (Unsupported Media Type) status code indicates that the |  | The 415 (Unsupported Media Type) status code indicates that the |
| origin server is refusing to service the request because the payload |  | origin server is refusing to service the request because the payload |
| is in a format not supported by this method on the target resource. |  | is in a format not supported by this method on the target resource. |
| The format problem might be due to the request's indicated Content- |  | The format problem might be due to the request's indicated |
| Type or Content-Encoding, or as a result of inspecting the data |  | Content-Type or Content-Encoding, or as a result of inspecting the |
| directly. |  | data directly. |
| 6.5.14. 417 Expectation Failed |  | 6.5.14. 417 Expectation Failed |
| The 417 (Expectation Failed) status code indicates that the |  | The 417 (Expectation Failed) status code indicates that the |
| expectation given in the request's Expect header field |  | expectation given in the request's Expect header field |
| (Section 5.1.1) could not be met by at least one of the inbound |  | (Section 5.1.1) could not be met by at least one of the inbound |
| servers. |  | servers. |
| 6.5.15. 426 Upgrade Required |  | 6.5.15. 426 Upgrade Required |
| skipping to change at page 64, line 8 |  | skipping to change at page 64, line 20 |
| that it is unable or unwilling to complete the request using the same |  | that it is unable or unwilling to complete the request using the same |
| major version as the client, as described in Section 2.6 of |  | major version as the client, as described in Section 2.6 of |
| [RFC7230], other than with this error message. The server SHOULD |  | [RFC7230], other than with this error message. The server SHOULD |
| generate a representation for the 505 response that describes why |  | generate a representation for the 505 response that describes why |
| that version is not supported and what other protocols are supported |  | that version is not supported and what other protocols are supported |
| by that server. |  | by that server. |
| 7. 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 beyond what is placed in the status- |  | information about the response beyond what is placed in the |
| line. These header fields give information about the server, about |  | status-line. These header fields give information about the server, |
| further access to the target resource, or about related resources. |  | about further access to the target resource, or about related |
|  |  | resources. |
| Although each response header field has a defined meaning, in |  | Although each response header field has a defined meaning, in |
| general, the precise semantics might be further refined by the |  | general, the precise semantics might be further refined by the |
| semantics of the request method and/or response status code. |  | semantics of the request method and/or response status code. |
| 7.1. Control Data |  | 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, directs caching, or instructs the client where to go |  | status code, directs caching, or instructs the client where to go |
| next. |  | next. |
| skipping to change at page 65, line 12 |  | skipping to change at page 65, line 28 |
| Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate |  | Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate |
| Examples of the two obsolete formats are |  | Examples of the two obsolete formats are |
| Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format |  | Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format |
| Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |  | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |
| A recipient that parses a timestamp value in an HTTP header field |  | A recipient that parses a timestamp value in an HTTP header field |
| MUST accept all three HTTP-date formats. When a sender generates a |  | MUST accept all three HTTP-date formats. When a sender generates a |
| header field that contains one or more timestamps defined as HTTP- |  | header field that contains one or more timestamps defined as |
| date, the sender MUST generate those timestamps in the IMF-fixdate |  | HTTP-date, the sender MUST generate those timestamps in the |
| format. |  | IMF-fixdate format. |
| An HTTP-date value represents time as an instance of Coordinated |  | An HTTP-date value represents time as an instance of Coordinated |
| Universal Time (UTC). The first two formats indicate UTC by the |  | Universal Time (UTC). The first two formats indicate UTC by the |
| three-letter abbreviation for Greenwich Mean Time, "GMT", a |  | three-letter abbreviation for Greenwich Mean Time, "GMT", a |
| predecessor of the UTC name; values in the asctime format are assumed |  | predecessor of the UTC name; values in the asctime format are assumed |
| to be in UTC. A sender that generates HTTP-date values from a local |  | to be in UTC. A sender that generates HTTP-date values from a local |
| clock ought to use NTP ([RFC5905]) or some similar protocol to |  | clock ought to use NTP ([RFC5905]) or some similar protocol to |
| synchronize its clock to UTC. |  | synchronize its clock to UTC. |
| Preferred format: |  | Preferred format: |
| skipping to change at page 67, line 22 |  | skipping to change at page 67, line 7 |
| / %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 )) |
| ; e.g., Jun 2 |  | ; e.g., Jun 2 |
| HTTP-date is case sensitive. A sender MUST NOT generate additional |  | HTTP-date is case sensitive. A sender MUST NOT generate additional |
| whitespace in an HTTP-date beyond that specifically included as SP in |  | whitespace in an HTTP-date beyond that specifically included as SP in |
| the grammar. The semantics of day-name, day, month, year, and time- |  | the grammar. The semantics of day-name, day, month, year, and |
| of-day are the same as those defined for the Internet Message Format |  | time-of-day are the same as those defined for the Internet Message |
| constructs with the corresponding name ([RFC5322], Section 3.3). |  | Format constructs with the corresponding name ([RFC5322], Section |
|  |  | 3.3). |
| Recipients of a timestamp value in rfc850-date format, which uses a |  | Recipients of a timestamp value in rfc850-date format, which uses a |
| two-digit year, MUST interpret a timestamp that appears to be more |  | two-digit year, MUST interpret a timestamp that appears to be more |
| than 50 years in the future as representing the most recent year in |  | than 50 years in the future as representing the most recent year in |
| the past that had the same last two digits. |  | the past that had the same last two digits. |
| Recipients of timestamp values are encouraged to be robust in parsing |  | Recipients of timestamp values are encouraged to be robust in parsing |
| timestamps unless otherwise restricted by the field definition. For |  | timestamps unless otherwise restricted by the field definition. For |
| example, messages are occasionally forwarded over HTTP from a non- |  | example, messages are occasionally forwarded over HTTP from a |
| HTTP source that might generate any of the date and time |  | non-HTTP source that might generate any of the date and time |
| specifications defined by the Internet Message Format. |  | 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. Implementations are |  | to their usage within the protocol stream. Implementations are |
| not required to use these formats for user presentation, request |  | not required to use these formats for user presentation, request |
| logging, etc. |  | logging, etc. |
| 7.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 |
| skipping to change at page 70, line 30 |  | skipping to change at page 70, line 18 |
| Retry-After: 120 |  | Retry-After: 120 |
| In the latter example, the delay is 2 minutes. |  | In the latter example, the delay is 2 minutes. |
| 7.1.4. Vary |  | 7.1.4. Vary |
| The "Vary" header field in a response describes what parts of a |  | The "Vary" header field in a response describes what parts of a |
| request message, aside from the method, Host header field, and |  | request message, aside from the method, Host header field, and |
| request target, might influence the origin server's process for |  | request target, might influence the origin server's process for |
| selecting and representing this response. The value consists of |  | selecting and representing this response. The value consists of |
| either a single asterisk ("*") or a list of header field names (case- |  | either a single asterisk ("*") or a list of header field names |
| insensitive). |  | (case-insensitive). |
| Vary = "*" / 1#field-name |  | Vary = "*" / 1#field-name |
| A Vary field value of "*" signals that anything about the request |  | A Vary field value of "*" signals that anything about the request |
| might play a role in selecting the response representation, possibly |  | might play a role in selecting the response representation, possibly |
| including elements outside the message syntax (e.g., the client's |  | including elements outside the message syntax (e.g., the client's |
| network address). A recipient will not be able to determine whether |  | network address). A recipient will not be able to determine whether |
| this response is appropriate for a later request without forwarding |  | this response is appropriate for a later request without forwarding |
| the request to the origin server. A proxy MUST NOT generate a Vary |  | the request to the origin server. A proxy MUST NOT generate a Vary |
| field with a "*" value. |  | field with a "*" value. |
| skipping to change at page 78, line 35 |  | skipping to change at page 78, line 35 |
| [RFC7230] as necessary, and are usually constrained to the range of |  | [RFC7230] as necessary, and are usually constrained to the range of |
| US-ASCII characters. Header fields needing a greater range of |  | US-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 |  | Leading and trailing whitespace in raw field values is removed upon |
| field parsing (Section 3.2.4 of [RFC7230]). Field definitions where |  | field parsing (Section 3.2.4 of [RFC7230]). Field definitions where |
| leading or trailing whitespace in values is significant will have to |  | leading or trailing whitespace in values is significant will have to |
| use a container syntax such as quoted-string (Section 3.2.6 of |  | use a container syntax such as quoted-string (Section 3.2.6 of |
| [RFC7230]). |  | [RFC7230]). |
| Because commas (",") are used as a generic delimiter between field- |  | Because commas (",") are used as a generic delimiter between |
| values, they need to be treated with care if they are allowed in the |  | field-values, they need to be treated with care if they are allowed |
| field-value. Typically, components that might contain a comma are |  | in the field-value. Typically, components that might contain a comma |
| protected with double-quotes using the quoted-string ABNF production. |  | are protected with double-quotes using the quoted-string ABNF |
|  |  | production. |
| 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 |
| quotes will likely cause unnecessary confusion. |  | double-quotes will likely cause unnecessary confusion. |
| Many header fields use a format including (case-insensitively) named |  | Many header fields use a format including (case-insensitively) named |
| parameters (for instance, Content-Type, defined in Section 3.1.1.5). |  | parameters (for instance, Content-Type, defined in Section 3.1.1.5). |
| Allowing both unquoted (token) and quoted (quoted-string) syntax for |  | Allowing both unquoted (token) and quoted (quoted-string) syntax for |
| the parameter value enables recipients to use existing parser |  | the parameter value enables recipients to use existing parser |
| components. When allowing both forms, the meaning of a parameter |  | components. When allowing both forms, the meaning of a parameter |
| value ought to be independent of the syntax used for it (for an |  | value ought to be independent of the syntax used for it (for an |
| 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: |
| skipping to change at page 83, line 31 |  | skipping to change at page 83, line 36 |
| 9.4. Disclosure of Sensitive Information in URIs |  | 9.4. Disclosure of Sensitive Information in URIs |
| URIs are intended to be shared, not secured, even when they identify |  | URIs are intended to be shared, not secured, even when they identify |
| secure resources. URIs are often shown on displays, added to |  | secure resources. URIs are often shown on displays, added to |
| templates when a page is printed, and stored in a variety of |  | templates when a page is printed, and stored in a variety of |
| unprotected bookmark lists. It is therefore unwise to include |  | unprotected bookmark lists. It is therefore unwise to include |
| information within a URI that is sensitive, personally identifiable, |  | information within a URI that is sensitive, personally identifiable, |
| or a risk to disclose. |  | or a risk to disclose. |
| Authors of services ought to avoid GET-based forms for the submission |  | Authors of services ought to avoid GET-based forms for the submission |
| of sensitive data because that data will be placed in the request- |  | of sensitive data because that data will be placed in the |
| target. Many existing servers, proxies, and user agents log or |  | request-target. Many existing servers, proxies, and user agents log |
| display the request-target in places where it might be visible to |  | or display the request-target in places where it might be visible to |
| third parties. Such services ought to use POST-based form submission |  | third parties. Such services ought to use POST-based form submission |
| instead. |  | instead. |
| Since the Referer header field tells a target site about the context |  | Since the Referer header field tells a target site about the context |
| that resulted in a request, it has the potential to reveal |  | that resulted in a request, it has the potential to reveal |
| information about the user's immediate browsing history and any |  | information about the user's immediate browsing history and any |
| personal information that might be found in the referring resource's |  | personal information that might be found in the referring resource's |
| URI. Limitations on the Referer header field are described in |  | URI. Limitations on the Referer header field are described in |
| Section 5.5.2 to address some of its security considerations. |  | Section 5.5.2 to address some of its security considerations. |
| skipping to change at page 85, line 12 |  | skipping to change at page 85, line 21 |
| details about the user's system or extensions. However, the source |  | details about the user's system or extensions. However, the source |
| of unique information that is least expected by users is proactive |  | of unique information that is least expected by users is proactive |
| negotiation (Section 5.3), including the Accept, Accept-Charset, |  | negotiation (Section 5.3), including the Accept, Accept-Charset, |
| Accept-Encoding, and Accept-Language header fields. |  | Accept-Encoding, and Accept-Language header fields. |
| In addition to the fingerprinting concern, detailed use of the |  | In addition to the fingerprinting concern, detailed use of the |
| Accept-Language header field can reveal information the user might |  | Accept-Language header field can reveal information the user might |
| consider to be of a private nature. For example, understanding a |  | consider to be of a private nature. For example, understanding a |
| given language set might be strongly correlated to membership in a |  | given language set might be strongly correlated to membership in a |
| particular ethnic group. An approach that limits such loss of |  | particular ethnic group. An approach that limits such loss of |
| privacy would be for a user agent to omit the sending of Accept- |  | privacy would be for a user agent to omit the sending of |
| Language except for sites that have been whitelisted, perhaps via |  | Accept-Language except for sites that have been whitelisted, perhaps |
| interaction after detecting a Vary header field that indicates |  | via interaction after detecting a Vary header field that indicates |
| language negotiation might be useful. |  | language negotiation might be useful. |
| In environments where proxies are used to enhance privacy, user |  | In environments where proxies are used to enhance privacy, user |
| agents ought to be conservative in sending proactive negotiation |  | agents ought to be conservative in sending proactive negotiation |
| header fields. General-purpose user agents that provide a high |  | header fields. General-purpose user agents that provide a high |
| degree of header field configurability ought to inform users about |  | degree of header field configurability ought to inform users about |
| the loss of privacy that might result if too much detail is provided. |  | the loss of privacy that might result if too much detail is provided. |
| As an extreme privacy measure, proxies could filter the proactive |  | As an extreme privacy measure, proxies could filter the proactive |
| negotiation header fields in relayed requests. |  | negotiation header fields in relayed requests. |
| skipping to change at page 86, line 15 |  | skipping to change at page 86, line 24 |
| [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying |  | [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying |
| Languages", BCP 47, RFC 5646, September 2009. |  | Languages", BCP 47, RFC 5646, September 2009. |
| [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in |  | [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in |
| Internationalization in the IETF", BCP 166, RFC 6365, |  | Internationalization in the IETF", BCP 166, RFC 6365, |
| September 2011. |  | September 2011. |
| [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Message Syntax and Routing", |  | Protocol (HTTP/1.1): Message Syntax and Routing", |
| draft-ietf-httpbis-p1-messaging-latest (work in progress), |  | RFC 7230, June 2014. |
| June 2014. |  |  |
| [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Conditional Requests", |  | Protocol (HTTP/1.1): Conditional Requests", RFC 7232, |
| draft-ietf-httpbis-p4-conditional-latest (work in |  | June 2014. |
| progress), June 2014. |  |  |
| [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", |  | "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", |
| draft-ietf-httpbis-p5-range-latest (work in progress), |  | RFC 7233, June 2014. |
| June 2014. |  |  |
| [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |  | [RFC7234] 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-latest (work in progress), |  | RFC 7234, June 2014. |
| June 2014. |  |  |
| [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Authentication", |  | Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014. |
| draft-ietf-httpbis-p7-auth-latest (work in progress), |  |  |
| June 2014. |  |  |
| 11.2. Informative References |  | 11.2. Informative References |
| [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type |  | [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type |
| Specifications and Registration Procedures", BCP 13, |  | Specifications and Registration Procedures", BCP 13, |
| RFC 6838, January 2013. |  | RFC 6838, January 2013. |
| [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, |  | [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, |
| "Deprecating the "X-" Prefix and Similar Constructs in |  | "Deprecating the "X-" Prefix and Similar Constructs in |
| Application Protocols", BCP 178, RFC 6648, June 2012. |  | Application Protocols", BCP 178, RFC 6648, June 2012. |
| skipping to change at page 88, line 32 |  | skipping to change at page 88, line 36 |
| [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. |  | [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. |
| [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, |  | [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, |
| April 2011. |  | April 2011. |
| [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field |  | [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field |
| in the Hypertext Transfer Protocol (HTTP)", RFC 6266, |  | in the Hypertext Transfer Protocol (HTTP)", RFC 6266, |
| June 2011. |  | June 2011. |
| [RFC7238] Reschke, J., "The Hypertext Transfer Protocol (HTTP) |  | [RFC7238] Reschke, J., "The Hypertext Transfer Protocol (HTTP) |
| Status Code 308 (Permanent Redirect)", |  | Status Code 308 (Permanent Redirect)", RFC 7238, |
| draft-reschke-http-status-308-07 (work in progress), |  | June 2014. |
| 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 the Internet Message |  | HTTP/1.1 uses many of the constructs defined for the Internet Message |
| Format [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 header fields. |  | variety of representations and with extensible header fields. |
| However, RFC 2045 is focused only on email; applications of HTTP have |  | However, RFC 2045 is focused only on email; applications of HTTP have |
| many characteristics that differ from email; hence, HTTP has features |  | many characteristics that differ from email; hence, HTTP has features |
| that differ from MIME. These differences were carefully chosen to |  | that differ from MIME. These differences were carefully chosen to |
| skipping to change at page 89, line 10 |  | skipping to change at page 89, line 28 |
| This appendix describes specific areas where HTTP differs from MIME. |  | This appendix describes specific areas where HTTP differs from MIME. |
| Proxies and gateways to and from strict MIME environments need to be |  | Proxies and gateways to and from strict MIME environments need to be |
| aware of these differences and provide the appropriate conversions |  | aware of these differences and provide the appropriate conversions |
| where necessary. |  | where necessary. |
| A.1. MIME-Version |  | A.1. MIME-Version |
| HTTP is not a MIME-compliant protocol. However, messages can include |  | HTTP is not a MIME-compliant protocol. However, messages can include |
| a single MIME-Version header field to indicate what version of the |  | a single MIME-Version header field to indicate what version of the |
| MIME protocol was used to construct the message. Use of the MIME- |  | MIME protocol was used to construct the message. Use of the |
| Version header field indicates that the message is in full |  | MIME-Version header field indicates that the message is in full |
| conformance with the MIME protocol (as defined in [RFC2045]). |  | conformance with the MIME protocol (as defined in [RFC2045]). |
| Senders 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. |
| 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 |
| skipping to change at page 89, line 50 |  | skipping to change at page 90, line 20 |
| A.3. Conversion of Date Formats |  | A.3. Conversion of Date Formats |
| HTTP/1.1 uses a restricted set of date formats (Section 7.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 ought to ensure that any Date header field present in |  | other protocols ought to ensure that any Date header field present in |
| a message conforms to one of the HTTP/1.1 formats and rewrite the |  | a message conforms to one of the HTTP/1.1 formats and rewrite the |
| date if necessary. |  | date if necessary. |
| A.4. Conversion 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 |
| Encoding header field. Since this acts as a modifier on the media |  | Content-Encoding header field. Since this acts as a modifier on the |
| type, proxies and gateways from HTTP to MIME-compliant protocols |  | media type, proxies and gateways from HTTP to MIME-compliant |
| ought to either change the value of the Content-Type header field or |  | protocols ought to either change the value of the Content-Type header |
| decode the representation before forwarding the message. (Some |  | field or decode the representation before forwarding the message. |
| experimental applications of Content-Type for Internet mail have used |  | (Some experimental applications of Content-Type for Internet mail |
| a media-type parameter of ";conversions=<content-coding>" to perform |  | have used a media-type parameter of ";conversions=<content-coding>" |
| a function equivalent to Content-Encoding. However, this parameter |  | to perform a function equivalent to Content-Encoding. However, this |
| is not part of the MIME standards). |  | parameter is not part of the MIME standards). |
| A.5. Conversion of 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 need to |  | 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 |
| skipping to change at page 96, line 49 |  | skipping to change at page 97, line 29 |
| 5 |  | 5 |
| 5xx Server Error (status code class) 62 |  | 5xx Server Error (status code class) 62 |
| 1 |  | 1 |
| 100 Continue (status code) 50 |  | 100 Continue (status code) 50 |
| 100-continue (expect value) 34 |  | 100-continue (expect value) 34 |
| 101 Switching Protocols (status code) 50 |  | 101 Switching Protocols (status code) 50 |
| 2 |  | 2 |
| 200 OK (status code) 51 |  | 200 OK (status code) 51 |
| 201 Created (status code) 51 |  | 201 Created (status code) 52 |
| 202 Accepted (status code) 52 |  | 202 Accepted (status code) 52 |
| 203 Non-Authoritative Information (status code) 52 |  | 203 Non-Authoritative Information (status code) 52 |
| 204 No Content (status code) 53 |  | 204 No Content (status code) 53 |
| 205 Reset Content (status code) 53 |  | 205 Reset Content (status code) 53 |
| 3 |  | 3 |
| 300 Multiple Choices (status code) 55 |  | 300 Multiple Choices (status code) 55 |
| 301 Moved Permanently (status code) 56 |  | 301 Moved Permanently (status code) 56 |
| 302 Found (status code) 56 |  | 302 Found (status code) 56 |
| 303 See Other (status code) 57 |  | 303 See Other (status code) 57 |
| 305 Use Proxy (status code) 57 |  | 305 Use Proxy (status code) 58 |
| 306 (Unused) (status code) 57 |  | 306 (Unused) (status code) 58 |
| 307 Temporary Redirect (status code) 58 |  | 307 Temporary Redirect (status code) 58 |
| 4 |  | 4 |
| 400 Bad Request (status code) 58 |  | 400 Bad Request (status code) 58 |
| 402 Payment Required (status code) 58 |  | 402 Payment Required (status code) 59 |
| 403 Forbidden (status code) 58 |  | 403 Forbidden (status code) 59 |
| 404 Not Found (status code) 59 |  | 404 Not Found (status code) 59 |
| 405 Method Not Allowed (status code) 59 |  | 405 Method Not Allowed (status code) 59 |
| 406 Not Acceptable (status code) 59 |  | 406 Not Acceptable (status code) 59 |
| 408 Request Timeout (status code) 60 |  | 408 Request Timeout (status code) 60 |
| 409 Conflict (status code) 60 |  | 409 Conflict (status code) 60 |
| 410 Gone (status code) 60 |  | 410 Gone (status code) 60 |
| 411 Length Required (status code) 61 |  | 411 Length Required (status code) 61 |
| 413 Payload Too Large (status code) 61 |  | 413 Payload Too Large (status code) 61 |
| 414 URI Too Long (status code) 61 |  | 414 URI Too Long (status code) 61 |
| 415 Unsupported Media Type (status code) 61 |  | 415 Unsupported Media Type (status code) 62 |
| 417 Expectation Failed (status code) 62 |  | 417 Expectation Failed (status code) 62 |
| 426 Upgrade Required (status code) 62 |  | 426 Upgrade Required (status code) 62 |
| 5 |  | 5 |
| 500 Internal Server Error (status code) 62 |  | 500 Internal Server Error (status code) 63 |
| 501 Not Implemented (status code) 63 |  | 501 Not Implemented (status code) 63 |
| 502 Bad Gateway (status code) 63 |  | 502 Bad Gateway (status code) 63 |
| 503 Service Unavailable (status code) 63 |  | 503 Service Unavailable (status code) 63 |
| 504 Gateway Timeout (status code) 63 |  | 504 Gateway Timeout (status code) 63 |
| 505 HTTP Version Not Supported (status code) 63 |  | 505 HTTP Version Not Supported (status code) 64 |
| A |  | A |
| Accept header field 38 |  | Accept header field 38 |
| Accept-Charset header field 40 |  | Accept-Charset header field 40 |
| Accept-Encoding header field 41 |  | Accept-Encoding header field 41 |
| Accept-Language header field 42 |  | Accept-Language header field 42 |
| Allow header field 72 |  | Allow header field 72 |
| C |  | C |
| cacheable 24 |  | cacheable 24 |
| compress (content coding) 11 |  | compress (content coding) 11 |
| conditional request 36 |  | conditional request 36 |
| CONNECT method 30 |  | CONNECT method 30 |
| content coding 11 |  | content coding 11 |
| content negotiation 6 |  | content negotiation 6 |
| Content-Encoding header field 12 |  | Content-Encoding header field 12 |
| Content-Language header field 13 |  | Content-Language header field 13 |
| Content-Location header field 15 |  | Content-Location header field 15 |
| Content-Transfer-Encoding header field 90 |  | Content-Transfer-Encoding header field 89 |
| Content-Type header field 10 |  | Content-Type header field 10 |
| D |  | D |
| Date header field 67 |  | Date header field 67 |
| deflate (content coding) 11 |  | deflate (content coding) 11 |
| DELETE method 29 |  | DELETE method 29 |
| E |  | E |
| Expect header field 34 |  | Expect header field 34 |
| skipping to change at page 98, line 34 |  | skipping to change at page 99, line 15 |
| G |  | G |
| GET method 24 |  | GET method 24 |
| Grammar |  | Grammar |
| Accept 38 |  | Accept 38 |
| Accept-Charset 40 |  | Accept-Charset 40 |
| Accept-Encoding 41 |  | Accept-Encoding 41 |
| accept-ext 38 |  | accept-ext 38 |
| Accept-Language 42 |  | Accept-Language 42 |
| accept-params 38 |  | accept-params 38 |
| Allow 72 |  | Allow 72 |
| asctime-date 67 |  | asctime-date 66 |
| charset 9 |  | charset 9 |
| codings 41 |  | codings 41 |
| content-coding 11 |  | content-coding 11 |
| Content-Encoding 12 |  | Content-Encoding 12 |
| Content-Language 13 |  | Content-Language 13 |
| Content-Location 15 |  | Content-Location 15 |
| Content-Type 10 |  | Content-Type 10 |
| Date 67 |  | Date 67 |
| date1 66 |  | date1 65 |
| day 66 |  | day 65 |
| day-name 66 |  | day-name 65 |
| day-name-l 66 |  | day-name-l 65 |
| delay-seconds 70 |  | delay-seconds 69 |
| Expect 34 |  | Expect 34 |
| From 44 |  | From 44 |
| GMT 66 |  | GMT 65 |
| hour 66 |  | hour 65 |
| HTTP-date 64 |  | HTTP-date 65 |
| IMF-fixdate 66 |  | IMF-fixdate 65 |
| language-range 42 |  | language-range 42 |
| language-tag 13 |  | language-tag 13 |
| Location 68 |  | Location 68 |
| Max-Forwards 36 |  | Max-Forwards 36 |
| media-range 38 |  | media-range 38 |
| media-type 8 |  | media-type 8 |
| method 21 |  | method 21 |
| minute 66 |  | minute 65 |
| month 66 |  | month 65 |
| obs-date 66 |  | obs-date 66 |
| parameter 8 |  | parameter 8 |
| product 46 |  | product 46 |
| product-version 46 |  | product-version 46 |
| qvalue 38 |  | qvalue 38 |
| Referer 45 |  | Referer 45 |
| Retry-After 70 |  | Retry-After 69 |
| rfc850-date 67 |  | rfc850-date 66 |
| second 66 |  | second 65 |
| Server 73 |  | Server 73 |
| subtype 8 |  | subtype 8 |
| time-of-day 66 |  | time-of-day 65 |
| type 8 |  | type 8 |
| User-Agent 46 |  | User-Agent 46 |
| Vary 70 |  | Vary 70 |
| weight 38 |  | weight 38 |
| year 66 |  | year 65 |
| gzip (content coding) 11 |  | gzip (content coding) 11 |
| H |  | H |
| HEAD method 25 |  | HEAD method 25 |
| I |  | I |
| idempotent 23 |  | idempotent 23 |
| L |  | L |
| Location header field 68 |  | Location header field 68 |
End of changes. 57 change blocks.
| 308 lines changed or deleted |  | 286 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/