idnits 2.17.1 draft-ietf-httpbis-p2-semantics-21.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC2616, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2817, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2817, updated by this document, for RFC5378 checks: 1998-11-18) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 4, 2012) is 4193 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-21 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-21 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-21 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-21 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-21 ** Downref: Normative reference to an Informational RFC: RFC 1950 ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Downref: Normative reference to an Informational RFC: RFC 1952 -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2388 (Obsoleted by RFC 7578) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5987 (Obsoleted by RFC 8187) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group R. Fielding, Ed. 3 Internet-Draft Adobe 4 Obsoletes: 2616 (if approved) J. Reschke, Ed. 5 Updates: 2817 (if approved) greenbytes 6 Intended status: Standards Track October 4, 2012 7 Expires: April 7, 2013 9 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content 10 draft-ietf-httpbis-p2-semantics-21 12 Abstract 14 The Hypertext Transfer Protocol (HTTP) is an application-level 15 protocol for distributed, collaborative, hypertext information 16 systems. This document defines the semantics of HTTP/1.1 messages, 17 as expressed by request methods, request header fields, response 18 status codes, and response header fields, along with the payload of 19 messages (metadata and body content) and mechanisms for content 20 negotiation. 22 Editorial Note (To be removed by RFC Editor) 24 Discussion of this draft takes place on the HTTPBIS working group 25 mailing list (ietf-http-wg@w3.org), which is archived at 26 . 28 The current issues list is at 29 and related 30 documents (including fancy diffs) can be found at 31 . 33 The changes in this draft are summarized in Appendix F.41. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 7, 2013. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 This document may contain material from IETF Documents or IETF 67 Contributions published or made publicly available before November 68 10, 2008. The person(s) controlling the copyright in some of this 69 material may not have granted the IETF Trust the right to allow 70 modifications of such material outside the IETF Standards Process. 71 Without obtaining an adequate license from the person(s) controlling 72 the copyright in such materials, this document may not be modified 73 outside the IETF Standards Process, and derivative works of it may 74 not be created outside the IETF Standards Process, except to format 75 it for publication as an RFC or to translate it into languages other 76 than English. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 81 1.1. Conformance and Error Handling . . . . . . . . . . . . . 7 82 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 83 2. Resource . . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 3. Representation . . . . . . . . . . . . . . . . . . . . . . . 8 85 3.1. Representation Metadata . . . . . . . . . . . . . . . . . 8 86 3.1.1. Data Type . . . . . . . . . . . . . . . . . . . . . . 9 87 3.1.2. Data Encoding . . . . . . . . . . . . . . . . . . . . 12 88 3.1.3. Audience Language . . . . . . . . . . . . . . . . . . 14 89 3.1.4. Identification . . . . . . . . . . . . . . . . . . . 15 90 3.2. Representation Data . . . . . . . . . . . . . . . . . . . 18 91 3.3. Payload Semantics . . . . . . . . . . . . . . . . . . . . 18 92 3.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 19 93 3.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 20 94 3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 21 95 4. Product Tokens . . . . . . . . . . . . . . . . . . . . . . . 22 96 5. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 22 97 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 22 98 5.2. Common Method Properties . . . . . . . . . . . . . . . . 24 99 5.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 24 100 5.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 25 101 5.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 25 102 5.3. Method Definitions . . . . . . . . . . . . . . . . . . . 25 103 5.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 25 104 5.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 26 105 5.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 27 106 5.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 28 107 5.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 30 108 5.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 30 109 5.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 32 110 5.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 33 111 6. Request Header Fields . . . . . . . . . . . . . . . . . . . . 33 112 6.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 33 113 6.1.1. Max-Forwards . . . . . . . . . . . . . . . . . . . . 34 114 6.1.2. Expect . . . . . . . . . . . . . . . . . . . . . . . 34 115 6.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . 37 116 6.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 38 117 6.3.1. Quality Values . . . . . . . . . . . . . . . . . . . 38 118 6.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 38 119 6.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 41 120 6.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41 121 6.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42 122 6.4. Authentication Credentials . . . . . . . . . . . . . . . 44 123 6.5. Context . . . . . . . . . . . . . . . . . . . . . . . . . 44 124 6.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . 44 125 6.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 45 126 6.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 45 127 7. Response Status Codes . . . . . . . . . . . . . . . . . . . . 46 128 7.1. Overview of Status Codes . . . . . . . . . . . . . . . . 47 129 7.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 49 130 7.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 49 131 7.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 49 132 7.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 50 133 7.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 50 134 7.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 50 135 7.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 51 136 7.3.4. 203 Non-Authoritative Information . . . . . . . . . . 51 137 7.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 51 138 7.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 52 139 7.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 52 140 7.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 54 141 7.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 54 142 7.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 55 143 7.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 55 144 7.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 56 145 7.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 56 146 7.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . 56 147 7.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 56 148 7.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 56 149 7.5.2. 402 Payment Required . . . . . . . . . . . . . . . . 56 150 7.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 57 151 7.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 57 152 7.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . 57 153 7.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . 57 154 7.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 58 155 7.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . 58 156 7.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 58 157 7.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 59 158 7.5.11. 413 Request Representation Too Large . . . . . . . . 59 159 7.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . 59 160 7.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . 59 161 7.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . 60 162 7.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . 60 163 7.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 60 164 7.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 60 165 7.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 60 166 7.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 61 167 7.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 61 168 7.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 61 169 7.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 61 170 8. Response Header Fields . . . . . . . . . . . . . . . . . . . 61 171 8.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 62 172 8.1.1. Origination Date . . . . . . . . . . . . . . . . . . 62 173 8.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 65 174 8.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 66 175 8.2. Selected Representation Header Fields . . . . . . . . . . 67 176 8.2.1. Vary . . . . . . . . . . . . . . . . . . . . . . . . 67 177 8.3. Authentication Challenges . . . . . . . . . . . . . . . . 68 178 8.4. Informative . . . . . . . . . . . . . . . . . . . . . . . 68 179 8.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 69 180 8.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . 69 181 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 182 9.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 70 183 9.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 70 184 9.1.2. Considerations for New Methods . . . . . . . . . . . 70 185 9.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 71 186 9.2. Status Code Registry . . . . . . . . . . . . . . . . . . 71 187 9.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 71 188 9.2.2. Considerations for New Status Codes . . . . . . . . . 71 189 9.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 72 190 9.3. Header Field Registry . . . . . . . . . . . . . . . . . . 73 191 9.3.1. Considerations for New Header Fields . . . . . . . . 74 192 9.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 75 194 9.4. Content Coding Registry . . . . . . . . . . . . . . . . . 76 195 9.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 76 196 9.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 77 197 10. Security Considerations . . . . . . . . . . . . . . . . . . . 77 198 10.1. Transfer of Sensitive Information . . . . . . . . . . . . 77 199 10.2. Encoding Sensitive Information in URIs . . . . . . . . . 78 200 10.3. Location Header Fields: Spoofing and Information 201 Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 79 202 10.4. Security Considerations for CONNECT . . . . . . . . . . . 79 203 10.5. Privacy Issues Connected to Accept Header Fields . . . . 79 204 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80 205 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 206 12.1. Normative References . . . . . . . . . . . . . . . . . . 80 207 12.2. Informative References . . . . . . . . . . . . . . . . . 81 208 Appendix A. Differences between HTTP and MIME . . . . . . . . . 83 209 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 84 210 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . 84 211 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . 84 212 A.4. Introduction of Content-Encoding . . . . . . . . . . . . 85 213 A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . 85 214 A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 85 215 Appendix B. Additional Features . . . . . . . . . . . . . . . . 85 216 Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . 86 217 Appendix D. Imported ABNF . . . . . . . . . . . . . . . . . . . 88 218 Appendix E. Collected ABNF . . . . . . . . . . . . . . . . . . . 88 219 Appendix F. Change Log (to be removed by RFC Editor before 220 publication) . . . . . . . . . . . . . . . . . . . . 91 221 F.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . 91 222 F.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . 91 223 F.3. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . 92 224 F.4. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . 93 225 F.5. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . 93 226 F.6. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . 93 227 F.7. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . 94 228 F.8. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . 95 229 F.9. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . 95 230 F.10. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . 95 231 F.11. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . 96 232 F.12. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . 96 233 F.13. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . 96 234 F.14. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . 97 235 F.15. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . 97 236 F.16. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . 97 237 F.17. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . 98 238 F.18. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . 99 239 F.19. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . 99 240 F.20. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . 99 241 F.21. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . 99 242 F.22. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . 100 243 F.23. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . 100 244 F.24. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . 101 245 F.25. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . 101 246 F.26. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . 101 247 F.27. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . 103 248 F.28. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . 103 249 F.29. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . 103 250 F.30. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . 103 251 F.31. Since draft-ietf-httpbis-p3-payload-14 . . . . . . . . . 104 252 F.32. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . 104 253 F.33. Since draft-ietf-httpbis-p3-payload-15 . . . . . . . . . 104 254 F.34. Since draft-ietf-httpbis-p2-semantics-16 . . . . . . . . 104 255 F.35. Since draft-ietf-httpbis-p3-payload-16 . . . . . . . . . 104 256 F.36. Since draft-ietf-httpbis-p2-semantics-17 . . . . . . . . 105 257 F.37. Since draft-ietf-httpbis-p3-payload-17 . . . . . . . . . 105 258 F.38. Since draft-ietf-httpbis-p2-semantics-18 . . . . . . . . 105 259 F.39. Since draft-ietf-httpbis-p3-payload-18 . . . . . . . . . 106 260 F.40. Since draft-ietf-httpbis-p2-semantics-19 and 261 draft-ietf-httpbis-p3-payload-19 . . . . . . . . . . . . 106 262 F.41. Since draft-ietf-httpbis-p2-semantics-20 . . . . . . . . 107 263 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 265 1. Introduction 267 Each Hypertext Transfer Protocol (HTTP) message is either a request 268 or a response. A server listens on a connection for a request, 269 parses each message received, interprets the message semantics in 270 relation to the identified request target, and responds to that 271 request with one or more response messages. A client constructs 272 request messages to communicate specific intentions, and examines 273 received responses to see if the intentions were carried out and 274 determine how to interpret the results. This document defines 275 HTTP/1.1 request and response semantics in terms of the architecture 276 defined in [Part1]. 278 HTTP provides a uniform interface for interacting with a resource 279 (Section 2), regardless of its type, nature, or implementation, and 280 for transferring content in message payloads in the form of a 281 representation (Section 3). 283 HTTP semantics include the intentions defined by each request method 284 (Section 5), extensions to those semantics that might be described in 285 request header fields (Section 6), the meaning of status codes to 286 indicate a machine-readable response (Section 7), and the meaning of 287 other control data and resource metadata that might be given in 288 response header fields (Section 8). 290 This document also defines representation metadata that describe how 291 a payload is intended to be interpreted by a recipient, the request 292 header fields that might influence content selection, and the various 293 selection algorithms that are collectively referred to as "content 294 negotiation" (Section 3.4). 296 1.1. Conformance and Error Handling 298 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 299 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 300 document are to be interpreted as described in [RFC2119]. 302 Conformance criteria and considerations regarding error handling are 303 defined in Section 2.5 of [Part1]. 305 1.2. Syntax Notation 307 This specification uses the Augmented Backus-Naur Form (ABNF) 308 notation of [RFC5234] with the list rule extension defined in Section 309 1.2 of [Part1]. Appendix D describes rules imported from other 310 documents. Appendix E shows the collected ABNF with the list rule 311 expanded. 313 2. Resource 315 The target of each HTTP request is called a resource. HTTP does not 316 limit the nature of a resource; it merely defines an interface that 317 might be used to interact with resources. Each resource is 318 identified by a Uniform Resource Identifier (URI), as described in 319 Section 2.7 of [Part1]. 321 When a client constructs an HTTP/1.1 request message, it sends the 322 "target URI" in one of various forms, as defined in (Section 5.3 of 323 [Part1]). When a request is received, the server reconstructs an 324 "effective request URI" for the target resource (Section 5.5 of 325 [Part1]). 327 One design goal of HTTP is to separate resource identification from 328 request semantics, which is made possible by vesting the request 329 semantics in the request method (Section 5) and a few request- 330 modifying header fields (Section 6). Resource owners SHOULD NOT 331 include request semantics within a URI, such as by specifying an 332 action to invoke within the path or query components of the effective 333 request URI, unless those semantics are disabled when they are 334 inconsistent with the request method. 336 3. Representation 338 If we consider that a resource could be anything, and that the 339 uniform interface provided by HTTP is similar to a window through 340 which one can observe and act upon such a thing only through the 341 communication of messages to some independent actor on the other 342 side, then we need an abstraction to represent ("take the place of") 343 the current or desired state of that thing in our communications. We 344 call that abstraction a "representation" [REST]. 346 For the purposes of HTTP, a representation is information that 347 reflects the current or desired state of a given resource, in a 348 format that can be readily communicated via the protocol, consisting 349 of a set of representation metadata and a potentially unbounded 350 stream of representation data. 352 3.1. Representation Metadata 354 Representation header fields provide metadata about the 355 representation. When a message includes a payload body, the 356 representation header fields describe how to interpret the 357 representation data enclosed in the payload body. In a response to a 358 HEAD request, the representation header fields describe the 359 representation data that would have been enclosed in the payload body 360 if the same request had been a GET. 362 The following header fields are defined to convey representation 363 metadata: 365 +-------------------+------------------------+ 366 | Header Field Name | Defined in... | 367 +-------------------+------------------------+ 368 | Content-Type | Section 3.1.1.5 | 369 | Content-Encoding | Section 3.1.2.2 | 370 | Content-Language | Section 3.1.3.2 | 371 | Content-Location | Section 3.1.4.2 | 372 | Expires | Section 7.3 of [Part6] | 373 +-------------------+------------------------+ 375 3.1.1. Data Type 377 3.1.1.1. Media Types 379 HTTP uses Internet Media Types [RFC2046] in the Content-Type 380 (Section 3.1.1.5) and Accept (Section 6.3.2) header fields in order 381 to provide open and extensible data typing and type negotiation. 383 media-type = type "/" subtype *( OWS ";" OWS parameter ) 384 type = token 385 subtype = token 387 The type/subtype MAY be followed by parameters in the form of 388 attribute/value pairs. 390 parameter = attribute "=" value 391 attribute = token 392 value = word 394 The type, subtype, and parameter attribute names are case- 395 insensitive. Parameter values might or might not be case-sensitive, 396 depending on the semantics of the parameter name. The presence or 397 absence of a parameter might be significant to the processing of a 398 media-type, depending on its definition within the media type 399 registry. 401 A parameter value that matches the token production can be 402 transmitted as either a token or within a quoted-string. The quoted 403 and unquoted values are equivalent. 405 Media-type values are registered with the Internet Assigned Number 406 Authority (IANA). The media type registration process is outlined in 407 [RFC4288]. Use of non-registered media types is discouraged. 409 3.1.1.2. Character Encodings (charset) 411 HTTP uses charset names to indicate the character encoding of a 412 textual representation. 414 A character encoding is identified by a case-insensitive token. The 415 complete set of tokens is defined by the IANA Character Set registry 416 (). 418 charset = token 420 Although HTTP allows an arbitrary token to be used as a charset 421 value, any token that has a predefined value within the IANA 422 Character Set registry MUST represent the character encoding defined 423 by that registry. Applications SHOULD limit their use of character 424 encodings to those defined within the IANA registry. 426 HTTP uses charset in two contexts: within an Accept-Charset request 427 header field (in which the charset value is an unquoted token) and as 428 the value of a parameter in a Content-Type header field (within a 429 request or response), in which case the parameter value of the 430 charset parameter can be quoted. 432 Implementers need to be aware of IETF character set requirements 433 [RFC3629] [RFC2277]. 435 3.1.1.3. Canonicalization and Text Defaults 437 Internet media types are registered with a canonical form. A 438 representation transferred via HTTP messages MUST be in the 439 appropriate canonical form prior to its transmission except for 440 "text" types, as defined in the next paragraph. 442 When in canonical form, media subtypes of the "text" type use CRLF as 443 the text line break. HTTP relaxes this requirement and allows the 444 transport of text media with plain CR or LF alone representing a line 445 break when it is done consistently for an entire representation. 446 HTTP applications MUST accept CRLF, bare CR, and bare LF as 447 indicating a line break in text media received via HTTP. In 448 addition, if the text is in a character encoding that does not use 449 octets 13 and 10 for CR and LF respectively, as is the case for some 450 multi-byte character encodings, HTTP allows the use of whatever octet 451 sequences are defined by that character encoding to represent the 452 equivalent of CR and LF for line breaks. This flexibility regarding 453 line breaks applies only to text media in the payload body; a bare CR 454 or LF MUST NOT be substituted for CRLF within any of the HTTP control 455 structures (such as header fields and multipart boundaries). 457 If a representation is encoded with a content-coding, the underlying 458 data MUST be in a form defined above prior to being encoded. 460 3.1.1.4. Multipart Types 462 MIME provides for a number of "multipart" types -- encapsulations of 463 one or more representations within a single message body. All 464 multipart types share a common syntax, as defined in Section 5.1.1 of 465 [RFC2046], and include a boundary parameter as part of the media type 466 value. The message body is itself a protocol element; a sender MUST 467 generate only CRLF to represent line breaks between body-parts. 469 In general, HTTP treats a multipart message body no differently than 470 any other media type: strictly as payload. HTTP does not use the 471 multipart boundary as an indicator of message body length. In all 472 other respects, an HTTP user agent SHOULD follow the same or similar 473 behavior as a MIME user agent would upon receipt of a multipart type. 474 The MIME header fields within each body-part of a multipart message 475 body do not have any significance to HTTP beyond that defined by 476 their MIME semantics. 478 A recipient MUST treat an unrecognized multipart subtype as being 479 equivalent to "multipart/mixed". 481 Note: The "multipart/form-data" type has been specifically defined 482 for carrying form data suitable for processing via the POST 483 request method, as described in [RFC2388]. 485 3.1.1.5. Content-Type 487 The "Content-Type" header field indicates the media type of the 488 representation, which defines both the data format and how that data 489 SHOULD be processed by the recipient (within the scope of the request 490 method semantics) after any Content-Encoding is decoded. For 491 responses to the HEAD method, the media type is that which would have 492 been sent had the request been a GET. 494 Content-Type = media-type 496 Media types are defined in Section 3.1.1.1. An example of the field 497 is 499 Content-Type: text/html; charset=ISO-8859-4 501 A sender SHOULD include a Content-Type header field in a message 502 containing a payload body, defining the media type of the enclosed 503 representation, unless the intended media type is unknown to the 504 sender. If a Content-Type header field is not present, recipients 505 MAY either assume a media type of "application/octet-stream" 506 ([RFC2046], Section 4.5.1) or examine the representation data to 507 determine its type. 509 In practice, resource owners do not always properly configure their 510 origin server to provide the correct Content-Type for a given 511 representation, with the result that some clients will examine a 512 payload's content and override the specified type. Clients that do 513 so risk drawing incorrect conclusions, which might expose additional 514 security risks (e.g., "privilege escalation"). Furthermore, it is 515 impossible to determine the sender's intent by examining the data 516 format: many data formats match multiple media types that differ only 517 in processing semantics. Implementers are encouraged to provide a 518 means of disabling such "content sniffing" when it is used. 520 3.1.2. Data Encoding 522 3.1.2.1. Content Codings 524 Content coding values indicate an encoding transformation that has 525 been or can be applied to a representation. Content codings are 526 primarily used to allow a representation to be compressed or 527 otherwise usefully transformed without losing the identity of its 528 underlying media type and without loss of information. Frequently, 529 the representation is stored in coded form, transmitted directly, and 530 only decoded by the recipient. 532 content-coding = token 534 All content-coding values are case-insensitive and SHOULD be 535 registered within the HTTP Content Coding registry, as defined in 536 Section 9.4. They are used in the Accept-Encoding (Section 6.3.4) 537 and Content-Encoding (Section 3.1.2.2) header fields. 539 The following content-coding values are defined by this 540 specification: 542 compress (and x-compress): See Section 4.2.1 of [Part1]. 544 deflate: See Section 4.2.2 of [Part1]. 546 gzip (and x-gzip): See Section 4.2.3 of [Part1]. 548 3.1.2.2. Content-Encoding 550 The "Content-Encoding" header field indicates what content codings 551 have been applied to the representation, beyond those inherent in the 552 media type, and thus what decoding mechanisms have to be applied in 553 order to obtain data in the media type referenced by the Content-Type 554 header field. Content-Encoding is primarily used to allow a 555 representation's data to be compressed without losing the identity of 556 its underlying media type. 558 Content-Encoding = 1#content-coding 560 An example of its use is 562 Content-Encoding: gzip 564 If multiple encodings have been applied to a representation, the 565 content codings MUST be listed in the order in which they were 566 applied. Additional information about the encoding parameters MAY be 567 provided by other header fields not defined by this specification. 569 Unlike Transfer-Encoding (Section 3.3.1 of [Part1]), the codings 570 listed in Content-Encoding are a characteristic of the 571 representation; the representation is defined in terms of the coded 572 form, and all other metadata about the representation is about the 573 coded form unless otherwise noted in the metadata definition. 574 Typically, the representation is only decoded just prior to rendering 575 or analogous usage. 577 A transforming proxy MAY modify the content coding if the new coding 578 is known to be acceptable to the recipient, unless the "no-transform" 579 cache-control directive is present in the message. 581 If the media type includes an inherent encoding, such as a data 582 format that is always compressed, then that encoding would not be 583 restated as a Content-Encoding even if it happens to be the same 584 algorithm as one of the content codings. Such a content coding would 585 only be listed if, for some bizarre reason, it is applied a second 586 time to form the representation. Likewise, an origin server might 587 choose to publish the same payload data as multiple representations 588 that differ only in whether the coding is defined as part of Content- 589 Type or Content-Encoding, since some user agents will behave 590 differently in their handling of each response (e.g., open a "Save as 591 ..." dialog instead of automatic decompression and rendering of 592 content). 594 If the content-coding of a representation in a request message is not 595 acceptable to the origin server, the server SHOULD respond with a 596 status code of 415 (Unsupported Media Type). 598 3.1.3. Audience Language 600 3.1.3.1. Language Tags 602 A language tag, as defined in [RFC5646], identifies a natural 603 language spoken, written, or otherwise conveyed by human beings for 604 communication of information to other human beings. Computer 605 languages are explicitly excluded. HTTP uses language tags within 606 the Accept-Language and Content-Language fields. 608 In summary, a language tag is composed of one or more parts: A 609 primary language subtag followed by a possibly empty series of 610 subtags: 612 language-tag = 614 White space is not allowed within the tag and all tags are case- 615 insensitive. The name space of language subtags is administered by 616 the IANA (see 617 ). 619 Example tags include: 621 en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN 623 See [RFC5646] for further information. 625 3.1.3.2. Content-Language 627 The "Content-Language" header field describes the natural language(s) 628 of the intended audience for the representation. Note that this 629 might not be equivalent to all the languages used within the 630 representation. 632 Content-Language = 1#language-tag 634 Language tags are defined in Section 3.1.3.1. The primary purpose of 635 Content-Language is to allow a user to identify and differentiate 636 representations according to the user's own preferred language. 637 Thus, if the content is intended only for a Danish-literate audience, 638 the appropriate field is 640 Content-Language: da 642 If no Content-Language is specified, the default is that the content 643 is intended for all language audiences. This might mean that the 644 sender does not consider it to be specific to any natural language, 645 or that the sender does not know for which language it is intended. 647 Multiple languages MAY be listed for content that is intended for 648 multiple audiences. For example, a rendition of the "Treaty of 649 Waitangi", presented simultaneously in the original Maori and English 650 versions, would call for 652 Content-Language: mi, en 654 However, just because multiple languages are present within a 655 representation does not mean that it is intended for multiple 656 linguistic audiences. An example would be a beginner's language 657 primer, such as "A First Lesson in Latin", which is clearly intended 658 to be used by an English-literate audience. In this case, the 659 Content-Language would properly only include "en". 661 Content-Language MAY be applied to any media type -- it is not 662 limited to textual documents. 664 3.1.4. Identification 666 3.1.4.1. Identifying a Representation 668 When a complete or partial representation is transferred in a message 669 payload, it is often desirable for the sender to supply, or the 670 recipient to determine, an identifier for a resource corresponding to 671 that representation. 673 The following rules are used to determine such a URI for the payload 674 of a request message: 676 o If the request has a Content-Location header field, then the 677 sender asserts that the payload is a representation of the 678 resource identified by the Content-Location field-value. However, 679 such an assertion cannot be trusted unless it can be verified by 680 other means (not defined by HTTP). The information might still be 681 useful for revision history links. 683 o Otherwise, the payload is unidentified. 685 The following rules, to be applied in order until a match is found, 686 are used to determine such a URI for the payload of a response 687 message: 689 1. If the request is GET or HEAD and the response status code is 200 690 (OK), 204 (No Content), 206 (Partial Content), or 304 (Not 691 Modified), the payload's identifier is the effective request URI 692 (Section 5.5 of [Part1]). 694 2. If the request is GET or HEAD and the response status code is 203 695 (Non-Authoritative Information), the payload is a potentially 696 modified representation of the target resource; as such, the 697 effective request URI might only act as an identifier for the 698 payload's representation when a request is made via the same 699 chain of intermediaries. 701 3. If the response has a Content-Location header field and its 702 field-value is a reference to the same URI as the effective 703 request URI, the payload's identifier is the effective request 704 URI. 706 4. If the response has a Content-Location header field and its 707 field-value is a reference to a URI different from the effective 708 request URI, then the sender asserts that the payload is a 709 representation of the resource identified by the Content-Location 710 field-value. However, such an assertion cannot be trusted unless 711 it can be verified by other means (not defined by HTTP). 713 5. Otherwise, the payload is unidentified. 715 3.1.4.2. Content-Location 717 The "Content-Location" header field references a URI that can be used 718 as a specific identifier for the representation in this message 719 payload. In other words, if one were to perform a GET on this URI at 720 the time of this message's generation, then a 200 (OK) response would 721 contain the same representation that is enclosed as payload in this 722 message. 724 Content-Location = absolute-URI / partial-URI 726 The Content-Location value is not a replacement for the effective 727 Request URI (Section 5.5 of [Part1]). It is representation metadata. 728 It has the same syntax and semantics as the header field of the same 729 name defined for MIME body parts in Section 4 of [RFC2557]. However, 730 its appearance in an HTTP message has some special implications for 731 HTTP recipients. 733 If Content-Location is included in a 2xx (Successful) response 734 message and its value refers (after conversion to absolute form) to a 735 URI that is the same as the effective request URI, then the response 736 payload SHOULD be considered a current representation of that 737 resource. For a GET or HEAD request, this is the same as the default 738 semantics when no Content-Location is provided by the server. For a 739 state-changing request like PUT or POST, it implies that the server's 740 response contains the new representation of that resource, thereby 741 distinguishing it from representations that might only report about 742 the action (e.g., "It worked!"). This allows authoring applications 743 to update their local copies without the need for a subsequent GET 744 request. 746 If Content-Location is included in a 2xx (Successful) response 747 message and its field-value refers to a URI that differs from the 748 effective request URI, then the origin server claims that the field- 749 value is an identifier for the payload's representation. Such a 750 claim can only be trusted if both identifiers share the same resource 751 owner, which cannot be programmatically determined via HTTP. 753 o For a response to a GET or HEAD request, this is an indication 754 that the effective request URI identifies a resource that is 755 subject to content negotiation and the Content-Location field- 756 value is a more specific identifier for the selected 757 representation. 759 o For a 201 (Created) response to a state-changing method, a 760 Content-Location field-value that is identical to the Location 761 field-value indicates that this payload is a current 762 representation of the newly created resource. 764 o Otherwise, such a Content-Location indicates that this payload is 765 a representation reporting on the requested action's status and 766 that the same report is available (for future access with GET) at 767 the given URI. For example, a purchase transaction made via a 768 POST request might include a receipt document as the payload of 769 the 200 (OK) response; the Content-Location field-value provides 770 an identifier for retrieving a copy of that same receipt in the 771 future. 773 If Content-Location is included in a request message, then it MAY be 774 interpreted by the origin server as an indication of where the user 775 agent originally obtained the content of the enclosed representation 776 (prior to any subsequent modification of the content by that user 777 agent). In other words, the user agent is providing the same 778 representation metadata that it received with the original 779 representation. However, such interpretation MUST NOT be used to 780 alter the semantics of the method requested by the client. For 781 example, if a client makes a PUT request on a negotiated resource and 782 the origin server accepts that PUT (without redirection), then the 783 new set of values for that resource is expected to be consistent with 784 the one representation supplied in that PUT; the Content-Location 785 cannot be used as a form of reverse content selection that identifies 786 only one of the negotiated representations to be updated. If the 787 user agent had wanted the latter semantics, it would have applied the 788 PUT directly to the Content-Location URI. 790 A Content-Location field received in a request message is transitory 791 information that SHOULD NOT be saved with other representation 792 metadata for use in later responses. The Content-Location's value 793 might be saved for use in other contexts, such as within source links 794 or other metadata. 796 A cache cannot assume that a representation with a Content-Location 797 different from the URI used to retrieve it can be used to respond to 798 later requests on that Content-Location URI. 800 3.2. Representation Data 802 The representation data associated with an HTTP message is either 803 provided as the payload body of the message or referred to by the 804 message semantics and the effective request URI. The representation 805 data is in a format and encoding defined by the representation 806 metadata header fields. 808 The data type of the representation data is determined via the header 809 fields Content-Type and Content-Encoding. These define a two-layer, 810 ordered encoding model: 812 representation-data := Content-Encoding( Content-Type( bits ) ) 814 3.3. Payload Semantics 816 Some HTTP messages transfer a complete or partial representation as 817 the message "payload". In some cases, a payload might only contain 818 the associated representation's header fields (e.g., responses to 819 HEAD) or only some part(s) of the representation data (e.g., the 206 820 (Partial Content) status code). 822 The purpose of a payload in a request is defined by the method 823 semantics. In a response, the payload's purpose is defined by both 824 the request method and the response status code. 826 For example, a representation in the payload of a PUT request 827 (Section 5.3.4) represents the desired state of the target resource 828 if the request is successfully applied, whereas a representation in 829 the payload of a POST request (Section 5.3.3) represents an anonymous 830 resource for providing data to be processed, such as the information 831 that a user entered within an HTML form. 833 Likewise, the payload of a 200 (OK) response to GET (Section 5.3.1) 834 contains a representation of the target resource, as observed at the 835 time of the message origination date (Section 8.1.1.2), whereas the 836 same status code in a response to POST might contain either a 837 representation of the processing result or a current representation 838 of the target resource after applying the processing. Response 839 messages with an error status code usually contain a representation 840 that describes the error and what next steps are suggested for 841 resolving it. 843 Header fields that specifically describe the payload, rather than the 844 associated representation, are referred to as "payload header 845 fields". Payload header fields are defined in other parts of this 846 specification, due to their impact on message parsing. 848 +-------------------+--------------------------+ 849 | Header Field Name | Defined in... | 850 +-------------------+--------------------------+ 851 | Content-Length | Section 3.3.2 of [Part1] | 852 | Content-Range | Section 5.2 of [Part5] | 853 | Transfer-Encoding | Section 3.3.1 of [Part1] | 854 +-------------------+--------------------------+ 856 3.4. Content Negotiation 858 HTTP responses include a representation which contains information 859 for interpretation, whether by a human user or for further 860 processing. Often, the server has different ways of representing the 861 same information; for example, in different formats, languages, or 862 using different character encodings. 864 HTTP clients and their users might have different or variable 865 capabilities, characteristics or preferences which would influence 866 which representation, among those available from the server, would be 867 best for the server to deliver. For this reason, HTTP provides 868 mechanisms for "content negotiation" -- a process of allowing 869 selection of a representation of a given resource, when more than one 870 is available. 872 This specification defines two patterns of content negotiation; 873 "proactive", where the server selects the representation based upon 874 the client's stated preferences, and "reactive" negotiation, where 875 the server provides a list of representations for the client to 876 choose from, based upon their metadata. In addition, there are other 877 patterns: some applications use an "active content" pattern, where 878 the server returns active content which runs on the client and, based 879 on client available parameters, selects additional resources to 880 invoke. "Transparent Content Negotiation" ([RFC2295]) has also been 881 proposed. 883 These patterns are all widely used, and have trade-offs in 884 applicability and practicality. In particular, when the number of 885 preferences or capabilities to be expressed by a client are large 886 (such as when many different formats are supported by a user-agent), 887 proactive negotiation becomes unwieldy, and might not be appropriate. 888 Conversely, when the number of representations to choose from is very 889 large, reactive negotiation might not be appropriate. 891 Note that, in all cases, the supplier of representations has the 892 responsibility for determining which representations might be 893 considered to be the "same information". 895 3.4.1. Proactive Negotiation 897 If the selection of the best representation for a response is made by 898 an algorithm located at the server, it is called proactive 899 negotiation. Selection is based on the available representations of 900 the response (the dimensions over which it can vary; e.g., language, 901 content-coding, etc.) and the contents of particular header fields in 902 the request message or on other information pertaining to the request 903 (such as the network address of the client). 905 Proactive negotiation is advantageous when the algorithm for 906 selecting from among the available representations is difficult to 907 describe to the user agent, or when the server desires to send its 908 "best guess" to the client along with the first response (hoping to 909 avoid the round-trip delay of a subsequent request if the "best 910 guess" is good enough for the user). In order to improve the 911 server's guess, the user agent MAY include request header fields 912 (Accept, Accept-Language, Accept-Encoding, etc.) which describe its 913 preferences for such a response. 915 Proactive negotiation has disadvantages: 917 1. It is impossible for the server to accurately determine what 918 might be "best" for any given user, since that would require 919 complete knowledge of both the capabilities of the user agent and 920 the intended use for the response (e.g., does the user want to 921 view it on screen or print it on paper?). 923 2. Having the user agent describe its capabilities in every request 924 can be both very inefficient (given that only a small percentage 925 of responses have multiple representations) and a potential 926 violation of the user's privacy. 928 3. It complicates the implementation of an origin server and the 929 algorithms for generating responses to a request. 931 4. It might limit a public cache's ability to use the same response 932 for multiple user's requests. 934 Proactive negotiation allows the user agent to specify its 935 preferences, but it cannot expect responses to always honor them. 936 For example, the origin server might not implement proactive 937 negotiation, or it might decide that sending a response that doesn't 938 conform to them is better than sending a 406 (Not Acceptable) 939 response. 941 HTTP/1.1 includes the following header fields for enabling proactive 942 negotiation through description of user agent capabilities and user 943 preferences: Accept (Section 6.3.2), Accept-Charset (Section 6.3.3), 944 Accept-Encoding (Section 6.3.4), Accept-Language (Section 6.3.5), and 945 User-Agent (Section 6.5.3). However, an origin server is not limited 946 to these dimensions and MAY vary the response based on any aspect of 947 the request, including aspects of the connection (e.g., IP address) 948 or information within extension header fields not defined by this 949 specification. 951 Note: In practice, User-Agent based negotiation is fragile, 952 because new clients might not be recognized. 954 The Vary header field (Section 8.2.1) can be used to express the 955 parameters the server uses to select a representation that is subject 956 to proactive negotiation. 958 3.4.2. Reactive Negotiation 960 With reactive negotiation, selection of the best representation for a 961 response is performed by the user agent after receiving an initial 962 response from the origin server. Selection is based on a list of the 963 available representations of the response included within the header 964 fields or body of the initial response, with each representation 965 identified by its own URI. Selection from among the representations 966 can be performed automatically (if the user agent is capable of doing 967 so) or manually by the user selecting from a generated (possibly 968 hypertext) menu. 970 Reactive negotiation is advantageous when the response would vary 971 over commonly-used dimensions (such as type, language, or encoding), 972 when the origin server is unable to determine a user agent's 973 capabilities from examining the request, and generally when public 974 caches are used to distribute server load and reduce network usage. 976 Reactive negotiation suffers from the disadvantage of needing a 977 second request to obtain the best alternate representation. This 978 second request is only efficient when caching is used. In addition, 979 this specification does not define any mechanism for supporting 980 automatic selection, though it also does not prevent any such 981 mechanism from being developed as an extension and used within 982 HTTP/1.1. 984 This specification defines the 300 (Multiple Choices) and 406 (Not 985 Acceptable) status codes for enabling reactive negotiation when the 986 server is unwilling or unable to provide a varying response using 987 proactive negotiation. 989 4. Product Tokens 991 Product tokens are used to allow communicating applications to 992 identify themselves by software name and version. Most fields using 993 product tokens also allow sub-products which form a significant part 994 of the application to be listed, separated by whitespace. By 995 convention, the products are listed in order of their significance 996 for identifying the application. 998 product = token ["/" product-version] 999 product-version = token 1001 Examples: 1003 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1004 Server: Apache/0.8.4 1006 Product tokens SHOULD be short and to the point. They MUST NOT be 1007 used for advertising or other non-essential information. Although 1008 any token octet MAY appear in a product-version, this token SHOULD 1009 only be used for a version identifier (i.e., successive versions of 1010 the same product SHOULD only differ in the product-version portion of 1011 the product value). 1013 5. Request Methods 1015 5.1. Overview 1017 The request method token is the primary source of request semantics; 1018 it indicates the purpose for which the client has made this request 1019 and what is expected by the client as a successful result. The 1020 request semantics MAY be further specialized by the semantics of some 1021 header fields when present in a request (Section 6) if those 1022 additional semantics do not conflict with the method. 1024 method = token 1026 HTTP was originally designed to be usable as an interface to 1027 distributed object systems. The request method was envisioned as 1028 applying semantics to a target resource in much the same way as 1029 invoking a defined method on an identified object would apply 1030 semantics. The method token is case-sensitive because it might be 1031 used as a gateway to object-based systems with case-sensitive method 1032 names. 1034 Unlike distributed objects, the standardized request methods in HTTP 1035 are not resource-specific, since uniform interfaces provide for 1036 better visibility and reuse in network-based systems [REST]. Once 1037 defined, a standardized method MUST have the same semantics when 1038 applied to any resource, though each resource determines for itself 1039 whether those semantics are implemented or allowed. 1041 This specification defines a number of standardized methods that are 1042 commonly used in HTTP, as outlined by the following table. By 1043 convention, standardized methods are defined in all-uppercase ASCII 1044 letters. 1046 +---------+-------------------------------------------------+-------+ 1047 | Method | Description | Sec. | 1048 +---------+-------------------------------------------------+-------+ 1049 | GET | Transfer a current representation of the target | 5.3.1 | 1050 | | resource. | | 1051 | HEAD | Same as GET, but do not include a message body | 5.3.2 | 1052 | | in the response. | | 1053 | POST | Perform resource-specific processing on the | 5.3.3 | 1054 | | request payload. | | 1055 | PUT | Replace all current representations of the | 5.3.4 | 1056 | | target resource with the request payload. | | 1057 | DELETE | Remove all current representations of the | 5.3.5 | 1058 | | target resource. | | 1059 | CONNECT | Establish a tunnel to the server identified by | 5.3.6 | 1060 | | the target resource. | | 1061 | OPTIONS | Describe the communication options for the | 5.3.7 | 1062 | | target resource. | | 1063 | TRACE | Perform a message loop-back test along the path | 5.3.8 | 1064 | | to the target resource. | | 1065 +---------+-------------------------------------------------+-------+ 1067 The methods GET and HEAD MUST be supported by all general-purpose 1068 servers. All other methods are OPTIONAL. When implemented, a server 1069 MUST implement the above methods according to the semantics defined 1070 for them in Section 5.3. 1072 Additional methods MAY be used in HTTP; many have already been 1073 standardized outside the scope of this specification and registered 1074 within the HTTP Method Registry maintained by IANA, as defined in 1075 Section 9.1. 1077 The set of methods allowed by a target resource can be listed in an 1078 Allow header field (Section 8.4.1). However, the set of allowed 1079 methods can change dynamically. When a request message is received 1080 that is unrecognized or not implemented by an origin server, the 1081 origin server SHOULD respond with the 501 (Not Implemented) status 1082 code. When a request message is received that is known by an origin 1083 server but not allowed for the target resource, the origin server 1084 SHOULD respond with the 405 (Method Not Allowed) status code. 1086 5.2. Common Method Properties 1088 5.2.1. Safe Methods 1090 Request methods are considered "safe" if their defined semantics are 1091 essentially read-only; i.e., the client does not request, and does 1092 not expect, any state change on the origin server as a result of 1093 applying a safe method to a target resource. Likewise, reasonable 1094 use of a safe method is not expected to cause any harm, loss of 1095 property, or unusual burden on the origin server. 1097 This definition of safe methods does not prevent an implementation 1098 from including behavior that is potentially harmful, not entirely 1099 read-only, or which causes side-effects while invoking a safe method. 1100 What is important, however, is that the client did not request that 1101 additional behavior and cannot be held accountable for it. For 1102 example, most servers append request information to access log files 1103 at the completion of every response, regardless of the method, and 1104 that is considered safe even though the log storage might become full 1105 and crash the server. Likewise, a safe request initiated by 1106 selecting an advertisement on the Web will often have the side-effect 1107 of charging an advertising account. 1109 The GET, HEAD, OPTIONS, and TRACE request methods are defined to be 1110 safe. 1112 The purpose of distinguishing between safe and unsafe methods is to 1113 allow automated retrieval processes (spiders) and cache performance 1114 optimization (pre-fetching) to work without fear of causing harm. In 1115 addition, it allows a user agent to apply appropriate constraints on 1116 the automated use of unsafe methods when processing potentially 1117 untrusted content. 1119 A user agent SHOULD distinguish between safe and unsafe methods when 1120 presenting potential actions to a user, such that the user can be 1121 made aware of an unsafe action before it is requested. 1123 When a resource is constructed such that parameters within the 1124 effective request URI have the effect of selecting an action, it is 1125 the resource owner's responsibility to ensure that the action is 1126 consistent with the request method semantics. For example, it is 1127 common for Web-based content editing software to use actions within 1128 query parameters, such as "page?do=delete". If the purpose of such a 1129 resource is to perform an unsafe action, then the resource MUST 1130 disable or disallow that action when it is accessed using a safe 1131 request method. Failure to do so will result in unfortunate side- 1132 effects when automated processes perform a GET on every URI reference 1133 for the sake of link maintenance, pre-fetching, building a search 1134 index, etc. 1136 5.2.2. Idempotent Methods 1138 Request methods are considered "idempotent" if the intended effect of 1139 multiple identical requests is the same as for a single request. 1140 PUT, DELETE, and all safe request methods are idempotent. 1142 Like the definition of safe, the idempotent property only applies to 1143 what has been requested by the user; a server is free to log each 1144 request separately, retain a revision control history, or implement 1145 other non-idempotent side-effects for each idempotent request. 1147 Idempotent methods are distinguished because the request can be 1148 repeated automatically if a communication failure occurs before the 1149 client is able to read the server's response. For example, if a 1150 client sends a PUT request and the underlying connection is closed 1151 before any response is received, then it can establish a new 1152 connection and retry the idempotent request because it knows that 1153 repeating the request will have the same effect even if the original 1154 request succeeded. Note, however, that repeated failures would 1155 indicate a problem within the server. 1157 5.2.3. Cacheable Methods 1159 Request methods are considered "cacheable" if it is possible and 1160 useful to answer a current client request with a stored response from 1161 a prior request. GET and HEAD are defined to be cacheable. In 1162 general, safe methods that do not depend on a current or 1163 authoritative response are cacheable, though the overwhelming 1164 majority of caches only support GET and HEAD. HTTP requirements for 1165 cache behavior and cacheable responses are defined in [Part6]. 1167 5.3. Method Definitions 1169 5.3.1. GET 1171 The GET method requests transfer of a current representation of the 1172 target resource. 1174 If the target resource is a data-producing process, it is the 1175 produced data which shall be returned as the representation in the 1176 response and not the source text of the process, unless that text 1177 happens to be the output of the process. 1179 The semantics of the GET method change to a "conditional GET" if the 1180 request message includes an If-Modified-Since, If-Unmodified-Since, 1181 If-Match, If-None-Match, or If-Range header field ([Part4]). A 1182 conditional GET requests that the representation be transferred only 1183 under the circumstances described by the conditional header field(s). 1184 The conditional GET request is intended to reduce unnecessary network 1185 usage by allowing cached representations to be refreshed without 1186 requiring multiple requests or transferring data already held by the 1187 client. 1189 The semantics of the GET method change to a "partial GET" if the 1190 request message includes a Range header field ([Part5]). A partial 1191 GET requests that only part of the representation be transferred, as 1192 described in Section 5.4 of [Part5]. The partial GET request is 1193 intended to reduce unnecessary network usage by allowing partially- 1194 retrieved representations to be completed without transferring data 1195 already held by the client. 1197 A payload within a GET request message has no defined semantics; 1198 sending a payload body on a GET request might cause some existing 1199 implementations to reject the request. 1201 The response to a GET request is cacheable and MAY be used to satisfy 1202 subsequent GET and HEAD requests (see [Part6]). 1204 See Section 10.2 for security considerations when used for forms. 1206 5.3.2. HEAD 1208 The HEAD method is identical to GET except that the server MUST NOT 1209 return a message body in the response. The metadata contained in the 1210 HTTP header fields in response to a HEAD request SHOULD be identical 1211 to the information sent in response to a GET request. This method 1212 can be used for obtaining metadata about the representation implied 1213 by the request without transferring the representation data. This 1214 method is often used for testing hypertext links for validity, 1215 accessibility, and recent modification. 1217 The response to a HEAD request is cacheable and MAY be used to 1218 satisfy a subsequent HEAD request. It also has potential side 1219 effects on previously stored responses to GET; see Section 5 of 1220 [Part6]. 1222 A payload within a HEAD request message has no defined semantics; 1223 sending a payload body on a HEAD request might cause some existing 1224 implementations to reject the request. 1226 5.3.3. POST 1228 The POST method requests that the origin server accept the 1229 representation enclosed in the request as data to be processed by the 1230 target resource. POST is designed to allow a uniform method to cover 1231 the following functions: 1233 o Annotation of existing resources; 1235 o Posting a message to a bulletin board, newsgroup, mailing list, or 1236 similar group of articles; 1238 o Providing a block of data, such as the result of submitting a 1239 form, to a data-handling process; 1241 o Extending a database through an append operation. 1243 The actual function performed by the POST method is determined by the 1244 server and is usually dependent on the effective request URI. 1246 The action performed by the POST method might not result in a 1247 resource that can be identified by a URI. In this case, either 200 1248 (OK) or 204 (No Content) is the appropriate response status code, 1249 depending on whether or not the response includes a representation 1250 that describes the result. 1252 If a resource has been created on the origin server, the response 1253 SHOULD be 201 (Created) and contain a representation which describes 1254 the status of the request and refers to the new resource, and a 1255 Location header field (see Section 8.1.2). 1257 Responses to POST requests are only cacheable when they include 1258 explicit freshness information (see Section 4.1.1 of [Part6]). A 1259 cached POST response with a Content-Location header field (see 1260 Section 3.1.4.2) whose value is the effective Request URI MAY be used 1261 to satisfy subsequent GET and HEAD (not POST) requests. 1263 Note that POST caching is not widely implemented. However, the 303 1264 (See Other) response can be used to direct the user agent to retrieve 1265 a cacheable representation of the resource. 1267 5.3.4. PUT 1269 The PUT method requests that the state of the target resource be 1270 created or replaced with the state defined by the representation 1271 enclosed in the request message payload. A successful PUT of a given 1272 representation would suggest that a subsequent GET on that same 1273 target resource will result in an equivalent representation being 1274 returned in a 200 (OK) response. However, there is no guarantee that 1275 such a state change will be observable, since the target resource 1276 might be acted upon by other user agents in parallel, or might be 1277 subject to dynamic processing by the origin server, before any 1278 subsequent GET is received. A successful response only implies that 1279 the user agent's intent was achieved at the time of its processing by 1280 the origin server. 1282 If the target resource does not have a current representation and the 1283 PUT successfully creates one, then the origin server MUST inform the 1284 user agent by sending a 201 (Created) response. If the target 1285 resource does have a current representation and that representation 1286 is successfully modified in accordance with the state of the enclosed 1287 representation, then either a 200 (OK) or 204 (No Content) response 1288 SHOULD be sent to indicate successful completion of the request. 1290 Unrecognized header fields SHOULD be ignored (i.e., not saved as part 1291 of the resource state). 1293 An origin server SHOULD verify that the PUT representation is 1294 consistent with any constraints which the server has for the target 1295 resource that cannot or will not be changed by the PUT. This is 1296 particularly important when the origin server uses internal 1297 configuration information related to the URI in order to set the 1298 values for representation metadata on GET responses. When a PUT 1299 representation is inconsistent with the target resource, the origin 1300 server SHOULD either make them consistent, by transforming the 1301 representation or changing the resource configuration, or respond 1302 with an appropriate error message containing sufficient information 1303 to explain why the representation is unsuitable. The 409 (Conflict) 1304 or 415 (Unsupported Media Type) status codes are suggested, with the 1305 latter being specific to constraints on Content-Type values. 1307 For example, if the target resource is configured to always have a 1308 Content-Type of "text/html" and the representation being PUT has a 1309 Content-Type of "image/jpeg", then the origin server SHOULD do one 1310 of: 1312 a. reconfigure the target resource to reflect the new media type; 1313 b. transform the PUT representation to a format consistent with that 1314 of the resource before saving it as the new resource state; or, 1316 c. reject the request with a 415 (Unsupported Media Type) response 1317 indicating that the target resource is limited to "text/html", 1318 perhaps including a link to a different resource that would be a 1319 suitable target for the new representation. 1321 HTTP does not define exactly how a PUT method affects the state of an 1322 origin server beyond what can be expressed by the intent of the user 1323 agent request and the semantics of the origin server response. It 1324 does not define what a resource might be, in any sense of that word, 1325 beyond the interface provided via HTTP. It does not define how 1326 resource state is "stored", nor how such storage might change as a 1327 result of a change in resource state, nor how the origin server 1328 translates resource state into representations. Generally speaking, 1329 all implementation details behind the resource interface are 1330 intentionally hidden by the server. 1332 The fundamental difference between the POST and PUT methods is 1333 highlighted by the different intent for the target resource. The 1334 target resource in a POST request is intended to handle the enclosed 1335 representation as a data-accepting process, such as for a gateway to 1336 some other protocol or a document that accepts annotations. In 1337 contrast, the target resource in a PUT request is intended to take 1338 the enclosed representation as a new or replacement value. Hence, 1339 the intent of PUT is idempotent and visible to intermediaries, even 1340 though the exact effect is only known by the origin server. 1342 Proper interpretation of a PUT request presumes that the user agent 1343 knows what target resource is desired. A service that is intended to 1344 select a proper URI on behalf of the client, after receiving a state- 1345 changing request, SHOULD be implemented using the POST method rather 1346 than PUT. If the origin server will not make the requested PUT state 1347 change to the target resource and instead wishes to have it applied 1348 to a different resource, such as when the resource has been moved to 1349 a different URI, then the origin server MUST send a 301 (Moved 1350 Permanently) response; the user agent MAY then make its own decision 1351 regarding whether or not to redirect the request. 1353 A PUT request applied to the target resource MAY have side-effects on 1354 other resources. For example, an article might have a URI for 1355 identifying "the current version" (a resource) which is separate from 1356 the URIs identifying each particular version (different resources 1357 that at one point shared the same state as the current version 1358 resource). A successful PUT request on "the current version" URI 1359 might therefore create a new version resource in addition to changing 1360 the state of the target resource, and might also cause links to be 1361 added between the related resources. 1363 An origin server SHOULD reject any PUT request that contains a 1364 Content-Range header field (Section 5.2 of [Part5]), since it might 1365 be misinterpreted as partial content (or might be partial content 1366 that is being mistakenly PUT as a full representation). Partial 1367 content updates are possible by targeting a separately identified 1368 resource with state that overlaps a portion of the larger resource, 1369 or by using a different method that has been specifically defined for 1370 partial updates (for example, the PATCH method defined in [RFC5789]). 1372 Responses to the PUT method are not cacheable. If a PUT request 1373 passes through a cache that has one or more stored responses for the 1374 effective request URI, those stored responses will be invalidated 1375 (see Section 6 of [Part6]). 1377 5.3.5. DELETE 1379 The DELETE method requests that the origin server delete the target 1380 resource. This method MAY be overridden by human intervention (or 1381 other means) on the origin server. The client cannot be guaranteed 1382 that the operation has been carried out, even if the status code 1383 returned from the origin server indicates that the action has been 1384 completed successfully. However, the server SHOULD NOT indicate 1385 success unless, at the time the response is given, it intends to 1386 delete the resource or move it to an inaccessible location. 1388 A successful response SHOULD be 200 (OK) if the response includes a 1389 representation describing the status, 202 (Accepted) if the action 1390 has not yet been enacted, or 204 (No Content) if the action has been 1391 enacted but the response does not include a representation. 1393 A payload within a DELETE request message has no defined semantics; 1394 sending a payload body on a DELETE request might cause some existing 1395 implementations to reject the request. 1397 Responses to the DELETE method are not cacheable. If a DELETE 1398 request passes through a cache that has one or more stored responses 1399 for the effective request URI, those stored responses will be 1400 invalidated (see Section 6 of [Part6]). 1402 5.3.6. CONNECT 1404 The CONNECT method requests that the proxy establish a tunnel to the 1405 request-target and, if successful, thereafter restrict its behavior 1406 to blind forwarding of packets until the connection is closed. 1408 When using CONNECT, the request-target MUST use the authority form 1409 (Section 5.3 of [Part1]); i.e., the request-target consists of only 1410 the host name and port number of the tunnel destination, separated by 1411 a colon. For example, 1413 CONNECT server.example.com:80 HTTP/1.1 1414 Host: server.example.com:80 1416 Any 2xx (Successful) response to a CONNECT request indicates that the 1417 proxy has established a connection to the requested host and port, 1418 and has switched to tunneling the current connection to that server 1419 connection. The tunneled data from the server begins immediately 1420 after the blank line that concludes the successful response's header 1421 block. 1423 A server SHOULD NOT send any Transfer-Encoding or Content-Length 1424 header fields in a successful response. A client MUST ignore any 1425 Content-Length or Transfer-Encoding header fields received in a 1426 successful response. 1428 Any response other than a successful response indicates that the 1429 tunnel has not yet been formed and that the connection remains 1430 governed by HTTP. 1432 Proxy authentication might be used to establish the authority to 1433 create a tunnel: 1435 CONNECT server.example.com:80 HTTP/1.1 1436 Host: server.example.com:80 1437 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1439 A payload within a CONNECT request message has no defined semantics; 1440 sending a payload body on a CONNECT request might cause some existing 1441 implementations to reject the request. 1443 Similar to a pipelined HTTP/1.1 request, data to be tunneled from 1444 client to server MAY be sent immediately after the request (before a 1445 response is received). The usual caveats also apply: data can be 1446 discarded if the eventual response is negative, and the connection 1447 can be reset with no response if more than one TCP segment is 1448 outstanding. 1450 It might be the case that the proxy itself can only reach the 1451 requested origin server through another proxy. In this case, the 1452 first proxy SHOULD make a CONNECT request of that next proxy, 1453 requesting a tunnel to the authority. A proxy MUST NOT respond with 1454 any 2xx status code unless it has either a direct or tunnel 1455 connection established to the authority. 1457 If at any point either one of the peers gets disconnected, any 1458 outstanding data that came from that peer will be passed to the other 1459 one, and after that also the other connection will be terminated by 1460 the proxy. If there is outstanding data to that peer undelivered, 1461 that data will be discarded. 1463 An origin server which receives a CONNECT request for itself MAY 1464 respond with a 2xx status code to indicate that a connection is 1465 established. However, most origin servers do not implement CONNECT. 1467 5.3.7. OPTIONS 1469 The OPTIONS method requests information about the communication 1470 options available on the request/response chain identified by the 1471 effective request URI. This method allows a client to determine the 1472 options and/or requirements associated with a resource, or the 1473 capabilities of a server, without implying a resource action or 1474 initiating a resource retrieval. 1476 Responses to the OPTIONS method are not cacheable. 1478 If the OPTIONS request includes a payload, then the media type MUST 1479 be indicated by a Content-Type field. Although this specification 1480 does not define any use for such a body, future extensions to HTTP 1481 might use the OPTIONS body to make more detailed queries on the 1482 server. 1484 If the request-target (Section 5.3 of [Part1]) is an asterisk ("*"), 1485 the OPTIONS request is intended to apply to the server in general 1486 rather than to a specific resource. Since a server's communication 1487 options typically depend on the resource, the "*" request is only 1488 useful as a "ping" or "no-op" type of method; it does nothing beyond 1489 allowing the client to test the capabilities of the server. For 1490 example, this can be used to test a proxy for HTTP/1.1 conformance 1491 (or lack thereof). 1493 If the request-target is not an asterisk, the OPTIONS request applies 1494 only to the options that are available when communicating with that 1495 resource. 1497 A 200 (OK) response SHOULD include any header fields that indicate 1498 optional features implemented by the server and applicable to that 1499 resource (e.g., Allow), possibly including extensions not defined by 1500 this specification. The response payload, if any, SHOULD also 1501 include information about the communication options. The format for 1502 such a payload is not defined by this specification, but might be 1503 defined by future extensions to HTTP. Content negotiation MAY be 1504 used to select the appropriate representation. If no payload body is 1505 included, the response MUST include a Content-Length field with a 1506 field-value of "0". 1508 The Max-Forwards header field MAY be used to target a specific proxy 1509 in the request chain (see Section 6.1.1). If no Max-Forwards field 1510 is present in the request, then the forwarded request MUST NOT 1511 include a Max-Forwards field. 1513 5.3.8. TRACE 1515 The TRACE method requests a remote, application-level loop-back of 1516 the request message. The final recipient of the request SHOULD 1517 reflect the message received back to the client as the message body 1518 of a 200 (OK) response. The final recipient is either the origin 1519 server or the first proxy to receive a Max-Forwards value of zero (0) 1520 in the request (see Section 6.1.1). A TRACE request MUST NOT include 1521 a message body. 1523 TRACE allows the client to see what is being received at the other 1524 end of the request chain and use that data for testing or diagnostic 1525 information. The value of the Via header field (Section 5.7 of 1526 [Part1]) is of particular interest, since it acts as a trace of the 1527 request chain. Use of the Max-Forwards header field allows the 1528 client to limit the length of the request chain, which is useful for 1529 testing a chain of proxies forwarding messages in an infinite loop. 1531 If the request is valid, the response SHOULD have a Content-Type of 1532 "message/http" (see Section 7.3.1 of [Part1]) and contain a message 1533 body that encloses a copy of the entire request message. Responses 1534 to the TRACE method are not cacheable. 1536 6. Request Header Fields 1538 A client sends request header fields to provide more information 1539 about the request context, make the request conditional based on the 1540 target resource state, suggest preferred formats for the response, 1541 supply authentication credentials, or modify the expected request 1542 processing. These fields act as request modifiers, similar to the 1543 parameters on a programming language method invocation. 1545 6.1. Controls 1547 Controls are request header fields that direct specific handling of 1548 the request. 1550 +-------------------+------------------------+ 1551 | Header Field Name | Defined in... | 1552 +-------------------+------------------------+ 1553 | Host | Section 5.4 of [Part1] | 1554 | Max-Forwards | Section 6.1.1 | 1555 | Expect | Section 6.1.2 | 1556 | Range | Section 5.4 of [Part5] | 1557 +-------------------+------------------------+ 1559 6.1.1. Max-Forwards 1561 The "Max-Forwards" header field provides a mechanism with the TRACE 1562 (Section 5.3.8) and OPTIONS (Section 5.3.7) methods to limit the 1563 number of times that the request is forwarded by proxies. This can 1564 be useful when the client is attempting to trace a request which 1565 appears to be failing or looping mid-chain. 1567 Max-Forwards = 1*DIGIT 1569 The Max-Forwards value is a decimal integer indicating the remaining 1570 number of times this request message can be forwarded. 1572 Each recipient of a TRACE or OPTIONS request containing a Max- 1573 Forwards header field MUST check and update its value prior to 1574 forwarding the request. If the received value is zero (0), the 1575 recipient MUST NOT forward the request; instead, it MUST respond as 1576 the final recipient. If the received Max-Forwards value is greater 1577 than zero, then the forwarded message MUST contain an updated Max- 1578 Forwards field with a value decremented by one (1). 1580 The Max-Forwards header field MAY be ignored for all other request 1581 methods. 1583 6.1.2. Expect 1585 The "Expect" header field is used to indicate that particular server 1586 behaviors are required by the client. 1588 Expect = 1#expectation 1590 expectation = expect-name [ BWS "=" BWS expect-value ] 1591 *( OWS ";" [ OWS expect-param ] ) 1592 expect-param = expect-name [ BWS "=" BWS expect-value ] 1594 expect-name = token 1595 expect-value = token / quoted-string 1597 If all received Expect header field(s) are syntactically valid but 1598 contain an expectation that the recipient does not understand or 1599 cannot comply with, the recipient MUST respond with a 417 1600 (Expectation Failed) status code. A recipient of a syntactically 1601 invalid Expectation header field MUST respond with a 4xx status code 1602 other than 417. 1604 The only expectation defined by this specification is: 1606 100-continue 1608 The "100-continue" expectation is defined below. It does not 1609 support any expect-params. 1611 Comparison is case-insensitive for names (expect-name), and case- 1612 sensitive for values (expect-value). 1614 The Expect mechanism is hop-by-hop: the above requirements apply to 1615 any server, including proxies. However, the Expect header field 1616 itself is end-to-end; it MUST be forwarded if the request is 1617 forwarded. 1619 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the 1620 Expect header field. 1622 6.1.2.1. Use of the 100 (Continue) Status 1624 The purpose of the 100 (Continue) status code (Section 7.2.1) is to 1625 allow a client that is sending a request message with a payload to 1626 determine if the origin server is willing to accept the request 1627 (based on the request header fields) before the client sends the 1628 payload body. In some cases, it might either be inappropriate or 1629 highly inefficient for the client to send the payload body if the 1630 server will reject the message without looking at the body. 1632 Requirements for HTTP/1.1 clients: 1634 o If a client will wait for a 100 (Continue) response before sending 1635 the payload body, it MUST send an Expect header field with the 1636 "100-continue" expectation. 1638 o A client MUST NOT send an Expect header field with the "100- 1639 continue" expectation if it does not intend to send a payload 1640 body. 1642 Because of the presence of older implementations, the protocol allows 1643 ambiguous situations in which a client might send "Expect: 100- 1644 continue" without receiving either a 417 (Expectation Failed) or a 1645 100 (Continue) status code. Therefore, when a client sends this 1646 header field to an origin server (possibly via a proxy) from which it 1647 has never seen a 100 (Continue) status code, the client SHOULD NOT 1648 wait for an indefinite period before sending the payload body. 1650 Requirements for HTTP/1.1 origin servers: 1652 o Upon receiving a request which includes an Expect header field 1653 with the "100-continue" expectation, an origin server MUST either 1654 respond with 100 (Continue) status code and continue to read from 1655 the input stream, or respond with a final status code. The origin 1656 server MUST NOT wait for the payload body before sending the 100 1657 (Continue) response. If it responds with a final status code, it 1658 MAY close the transport connection or it MAY continue to read and 1659 discard the rest of the request. It MUST NOT perform the request 1660 method if it returns a final status code. 1662 o An origin server SHOULD NOT send a 100 (Continue) response if the 1663 request message does not include an Expect header field with the 1664 "100-continue" expectation, and MUST NOT send a 100 (Continue) 1665 response if such a request comes from an HTTP/1.0 (or earlier) 1666 client. There is an exception to this rule: for compatibility 1667 with [RFC2068], a server MAY send a 100 (Continue) status code in 1668 response to an HTTP/1.1 PUT or POST request that does not include 1669 an Expect header field with the "100-continue" expectation. This 1670 exception, the purpose of which is to minimize any client 1671 processing delays associated with an undeclared wait for 100 1672 (Continue) status code, applies only to HTTP/1.1 requests, and not 1673 to requests with any other HTTP-version value. 1675 o An origin server MAY omit a 100 (Continue) response if it has 1676 already received some or all of the payload body for the 1677 corresponding request. 1679 o An origin server that sends a 100 (Continue) response MUST 1680 ultimately send a final status code, once the payload body is 1681 received and processed, unless it terminates the transport 1682 connection prematurely. 1684 o If an origin server receives a request that does not include an 1685 Expect header field with the "100-continue" expectation, the 1686 request includes a payload body, and the server responds with a 1687 final status code before reading the entire payload body from the 1688 transport connection, then the server SHOULD NOT close the 1689 transport connection until it has read the entire request, or 1690 until the client closes the connection. Otherwise, the client 1691 might not reliably receive the response message. However, this 1692 requirement ought not be construed as preventing a server from 1693 defending itself against denial-of-service attacks, or from badly 1694 broken client implementations. 1696 Requirements for HTTP/1.1 proxies: 1698 o If a proxy receives a request that includes an Expect header field 1699 with the "100-continue" expectation, and the proxy either knows 1700 that the next-hop server complies with HTTP/1.1 or higher, or does 1701 not know the HTTP version of the next-hop server, it MUST forward 1702 the request, including the Expect header field. 1704 o If the proxy knows that the version of the next-hop server is 1705 HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST 1706 respond with a 417 (Expectation Failed) status code. 1708 o Proxies SHOULD maintain a record of the HTTP version numbers 1709 received from recently-referenced next-hop servers. 1711 o A proxy MUST NOT forward a 100 (Continue) response if the request 1712 message was received from an HTTP/1.0 (or earlier) client and did 1713 not include an Expect header field with the "100-continue" 1714 expectation. This requirement overrides the general rule for 1715 forwarding of 1xx responses (see Section 7.2.1). 1717 6.2. Conditionals 1719 Conditionals are request header fields that indicate a precondition 1720 to be tested before applying the method semantics to the target 1721 resource. Each precondition is based on metadata that is expected to 1722 change if the selected representation of the target resource is 1723 changed. The HTTP/1.1 conditional request mechanisms are defined in 1724 [Part4]. 1726 +---------------------+------------------------+ 1727 | Header Field Name | Defined in... | 1728 +---------------------+------------------------+ 1729 | If-Match | Section 3.1 of [Part4] | 1730 | If-None-Match | Section 3.2 of [Part4] | 1731 | If-Modified-Since | Section 3.3 of [Part4] | 1732 | If-Unmodified-Since | Section 3.4 of [Part4] | 1733 | If-Range | Section 5.3 of [Part5] | 1734 +---------------------+------------------------+ 1736 6.3. Content Negotiation 1738 +-------------------+---------------+ 1739 | Header Field Name | Defined in... | 1740 +-------------------+---------------+ 1741 | Accept | Section 6.3.2 | 1742 | Accept-Charset | Section 6.3.3 | 1743 | Accept-Encoding | Section 6.3.4 | 1744 | Accept-Language | Section 6.3.5 | 1745 +-------------------+---------------+ 1747 6.3.1. Quality Values 1749 Many of the request header fields for proactive content negotiation 1750 use a common parameter, named "q" (case-insensitive), to assign a 1751 relative "weight" to the preference for that associated kind of 1752 content. This weight is referred to as a "quality value" (or 1753 "qvalue") because the same parameter name is often used within server 1754 configurations to assign a weight to the relative quality of the 1755 various representations that can be selected for a resource. 1757 The weight is normalized to a real number in the range 0 through 1, 1758 where 0.001 is the least preferred and 1 is the most preferred; a 1759 value of 0 means "not acceptable". If no "q" parameter is present, 1760 the default weight is 1. 1762 weight = OWS ";" OWS "q=" qvalue 1763 qvalue = ( "0" [ "." 0*3DIGIT ] ) 1764 / ( "1" [ "." 0*3("0") ] ) 1766 A sender of qvalue MUST NOT generate more than three digits after the 1767 decimal point. User configuration of these values ought to be 1768 limited in the same fashion. 1770 6.3.2. Accept 1772 The "Accept" header field can be used by user agents to specify 1773 response media types that are acceptable. Accept header fields can 1774 be used to indicate that the request is specifically limited to a 1775 small set of desired types, as in the case of a request for an in- 1776 line image. 1778 Accept = #( media-range [ accept-params ] ) 1780 media-range = ( "*/*" 1781 / ( type "/" "*" ) 1782 / ( type "/" subtype ) 1783 ) *( OWS ";" OWS parameter ) 1784 accept-params = weight *( accept-ext ) 1785 accept-ext = OWS ";" OWS token [ "=" word ] 1787 The asterisk "*" character is used to group media types into ranges, 1788 with "*/*" indicating all media types and "type/*" indicating all 1789 subtypes of that type. The media-range MAY include media type 1790 parameters that are applicable to that range. 1792 Each media-range MAY be followed by one or more accept-params, 1793 beginning with the "q" parameter for indicating a relative weight, as 1794 defined in Section 6.3.1. The first "q" parameter (if any) separates 1795 the media-range parameter(s) from the accept-params. 1797 Note: Use of the "q" parameter name to separate media type 1798 parameters from Accept extension parameters is due to historical 1799 practice. Although this prevents any media type parameter named 1800 "q" from being used with a media range, such an event is believed 1801 to be unlikely given the lack of any "q" parameters in the IANA 1802 media type registry and the rare usage of any media type 1803 parameters in Accept. Future media types are discouraged from 1804 registering any parameter named "q". 1806 The example 1808 Accept: audio/*; q=0.2, audio/basic 1810 SHOULD be interpreted as "I prefer audio/basic, but send me any audio 1811 type if it is the best available after an 80% mark-down in quality". 1813 A request without any Accept header field implies that the user agent 1814 will accept any media type in response. If an Accept header field is 1815 present in a request and none of the available representations for 1816 the response have a media type that is listed as acceptable, the 1817 origin server MAY either honor the Accept header field by sending a 1818 406 (Not Acceptable) response or disregard the Accept header field by 1819 treating the response as if it is not subject to content negotiation. 1821 A more elaborate example is 1823 Accept: text/plain; q=0.5, text/html, 1824 text/x-dvi; q=0.8, text/x-c 1826 Verbally, this would be interpreted as "text/html and text/x-c are 1827 the preferred media types, but if they do not exist, then send the 1828 text/x-dvi representation, and if that does not exist, send the text/ 1829 plain representation". 1831 Media ranges can be overridden by more specific media ranges or 1832 specific media types. If more than one media range applies to a 1833 given type, the most specific reference has precedence. For example, 1835 Accept: text/*, text/plain, text/plain;format=flowed, */* 1837 have the following precedence: 1839 1. text/plain;format=flowed 1841 2. text/plain 1843 3. text/* 1845 4. */* 1847 The media type quality factor associated with a given type is 1848 determined by finding the media range with the highest precedence 1849 which matches that type. For example, 1851 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 1852 text/html;level=2;q=0.4, */*;q=0.5 1854 would cause the following values to be associated: 1856 +-------------------+---------------+ 1857 | Media Type | Quality Value | 1858 +-------------------+---------------+ 1859 | text/html;level=1 | 1 | 1860 | text/html | 0.7 | 1861 | text/plain | 0.3 | 1862 | image/jpeg | 0.5 | 1863 | text/html;level=2 | 0.4 | 1864 | text/html;level=3 | 0.7 | 1865 +-------------------+---------------+ 1867 Note: A user agent might be provided with a default set of quality 1868 values for certain media ranges. However, unless the user agent is a 1869 closed system which cannot interact with other rendering agents, this 1870 default set ought to be configurable by the user. 1872 6.3.3. Accept-Charset 1874 The "Accept-Charset" header field can be used by user agents to 1875 indicate what character encodings are acceptable in a response 1876 payload. This field allows clients capable of understanding more 1877 comprehensive or special-purpose character encodings to signal that 1878 capability to a server which is capable of representing documents in 1879 those character encodings. 1881 Accept-Charset = 1#( ( charset / "*" ) [ weight ] ) 1883 Character encoding values (a.k.a., charsets) are described in 1884 Section 3.1.1.2. Each charset MAY be given an associated quality 1885 value which represents the user's preference for that charset, as 1886 defined in Section 6.3.1. An example is 1888 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 1890 The special value "*", if present in the Accept-Charset field, 1891 matches every character encoding which is not mentioned elsewhere in 1892 the Accept-Charset field. If no "*" is present in an Accept-Charset 1893 field, then any character encodings not explicitly mentioned in the 1894 field are considered "not acceptable" to the client. 1896 A request without any Accept-Charset header field implies that the 1897 user agent will accept any character encoding in response. 1899 If an Accept-Charset header field is present in a request and none of 1900 the available representations for the response have a character 1901 encoding that is listed as acceptable, the origin server MAY either 1902 honor the Accept-Charset header field by sending a 406 (Not 1903 Acceptable) response or disregard the Accept-Charset header field by 1904 treating the response as if it is not subject to content negotiation. 1906 6.3.4. Accept-Encoding 1908 The "Accept-Encoding" header field can be used by user agents to 1909 indicate what response content-codings (Section 3.1.2.1) are 1910 acceptable in the response. An "identity" token is used as a synonym 1911 for "no encoding" in order to communicate when no encoding is 1912 preferred. 1914 Accept-Encoding = #( codings [ weight ] ) 1915 codings = content-coding / "identity" / "*" 1917 Each codings value MAY be given an associated quality value which 1918 represents the preference for that encoding, as defined in 1919 Section 6.3.1. 1921 For example, 1923 Accept-Encoding: compress, gzip 1924 Accept-Encoding: 1925 Accept-Encoding: * 1926 Accept-Encoding: compress;q=0.5, gzip;q=1.0 1927 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 1929 A server tests whether a content-coding for a given representation is 1930 acceptable, according to an Accept-Encoding field, using these rules: 1932 1. The special "*" symbol in an Accept-Encoding field matches any 1933 available content-coding not explicitly listed in the header 1934 field. 1936 2. If the representation has no content-coding, then it is 1937 acceptable by default unless specifically excluded by the Accept- 1938 Encoding field stating either "identity;q=0" or "*;q=0" without a 1939 more specific entry for "identity". 1941 3. If the representation's content-coding is one of the content- 1942 codings listed in the Accept-Encoding field, then it is 1943 acceptable unless it is accompanied by a qvalue of 0. (As 1944 defined in Section 6.3.1, a qvalue of 0 means "not acceptable".) 1946 4. If multiple content-codings are acceptable, then the acceptable 1947 content-coding with the highest non-zero qvalue is preferred. 1949 An Accept-Encoding header field with a combined field-value that is 1950 empty implies that the user agent does not want any content-coding in 1951 response. If an Accept-Encoding header field is present in a request 1952 and none of the available representations for the response have a 1953 content-coding that is listed as acceptable, the origin server SHOULD 1954 send a response without any content-coding. 1956 A request without an Accept-Encoding header field implies that the 1957 user agent will accept any content-coding in response. 1959 Note: Most HTTP/1.0 applications do not recognize or obey qvalues 1960 associated with content-codings. This means that qvalues will not 1961 work and are not permitted with x-gzip or x-compress. 1963 6.3.5. Accept-Language 1965 The "Accept-Language" header field can be used by user agents to 1966 indicate the set of natural languages that are preferred in the 1967 response. Language tags are defined in Section 3.1.3.1. 1969 Accept-Language = 1#( language-range [ weight ] ) 1970 language-range = 1971 1973 Each language-range can be given an associated quality value which 1974 represents an estimate of the user's preference for the languages 1975 specified by that range, as defined in Section 6.3.1. For example, 1977 Accept-Language: da, en-gb;q=0.8, en;q=0.7 1979 would mean: "I prefer Danish, but will accept British English and 1980 other types of English". (see also Section 2.3 of [RFC4647]) 1982 For matching, Section 3 of [RFC4647] defines several matching 1983 schemes. Implementations can offer the most appropriate matching 1984 scheme for their requirements. 1986 Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is 1987 identical to the matching scheme that was previously defined in 1988 Section 14.4 of [RFC2616]. 1990 It might be contrary to the privacy expectations of the user to send 1991 an Accept-Language header field with the complete linguistic 1992 preferences of the user in every request. For a discussion of this 1993 issue, see Section 10.5. 1995 As intelligibility is highly dependent on the individual user, it is 1996 recommended that client applications make the choice of linguistic 1997 preference available to the user. If the choice is not made 1998 available, then the Accept-Language header field MUST NOT be given in 1999 the request. 2001 Note: When making the choice of linguistic preference available to 2002 the user, we remind implementers of the fact that users are not 2003 familiar with the details of language matching as described above, 2004 and ought to be provided appropriate guidance. As an example, 2005 users might assume that on selecting "en-gb", they will be served 2006 any kind of English document if British English is not available. 2007 A user agent might suggest in such a case to add "en" to get the 2008 best matching behavior. 2010 6.4. Authentication Credentials 2012 +---------------------+------------------------+ 2013 | Header Field Name | Defined in... | 2014 +---------------------+------------------------+ 2015 | Authorization | Section 4.1 of [Part7] | 2016 | Proxy-Authorization | Section 4.3 of [Part7] | 2017 +---------------------+------------------------+ 2019 6.5. Context 2021 +-------------------+------------------------+ 2022 | Header Field Name | Defined in... | 2023 +-------------------+------------------------+ 2024 | From | Section 6.5.1 | 2025 | Referer | Section 6.5.2 | 2026 | TE | Section 4.3 of [Part1] | 2027 | User-Agent | Section 6.5.3 | 2028 +-------------------+------------------------+ 2030 6.5.1. From 2032 The "From" header field, if given, SHOULD contain an Internet e-mail 2033 address for the human user who controls the requesting user agent. 2034 The address SHOULD be machine-usable, as defined by "mailbox" in 2035 Section 3.4 of [RFC5322]: 2037 From = mailbox 2039 mailbox = 2041 An example is: 2043 From: webmaster@example.org 2045 This header field MAY be used for logging purposes and as a means for 2046 identifying the source of invalid or unwanted requests. It SHOULD 2047 NOT be used as an insecure form of access protection. The 2048 interpretation of this field is that the request is being performed 2049 on behalf of the person given, who accepts responsibility for the 2050 method performed. In particular, robot agents SHOULD include this 2051 header field so that the person responsible for running the robot can 2052 be contacted if problems occur on the receiving end. 2054 The Internet e-mail address in this field MAY be separate from the 2055 Internet host which issued the request. For example, when a request 2056 is passed through a proxy the original issuer's address SHOULD be 2057 used. 2059 The client SHOULD NOT send the From header field without the user's 2060 approval, as it might conflict with the user's privacy interests or 2061 their site's security policy. It is strongly recommended that the 2062 user be able to disable, enable, and modify the value of this field 2063 at any time prior to a request. 2065 6.5.2. Referer 2067 The "Referer" [sic] header field allows the client to specify the URI 2068 of the resource from which the target URI was obtained (the 2069 "referrer", although the header field is misspelled.). 2071 The Referer header field allows servers to generate lists of back- 2072 links to resources for interest, logging, optimized caching, etc. It 2073 also allows obsolete or mistyped links to be traced for maintenance. 2074 Some servers use Referer as a means of controlling where they allow 2075 links from (so-called "deep linking"), but legitimate requests do not 2076 always contain a Referer header field. 2078 If the target URI was obtained from a source that does not have its 2079 own URI (e.g., input from the user keyboard), the Referer field MUST 2080 either be sent with the value "about:blank", or not be sent at all. 2081 Note that this requirement does not apply to sources with non-HTTP 2082 URIs (e.g., FTP). 2084 Referer = absolute-URI / partial-URI 2086 Example: 2088 Referer: http://www.example.org/hypertext/Overview.html 2090 If the field value is a relative URI, it SHOULD be interpreted 2091 relative to the effective request URI. The URI MUST NOT include a 2092 fragment. See Section 10.2 for security considerations. 2094 6.5.3. User-Agent 2096 The "User-Agent" header field contains information about the user 2097 agent originating the request. User agents SHOULD include this field 2098 with requests. 2100 Typically, it is used for statistical purposes, the tracing of 2101 protocol violations, and tailoring responses to avoid particular user 2102 agent limitations. 2104 The field can contain multiple product tokens (Section 4) and 2105 comments (Section 3.2 of [Part1]) identifying the agent and its 2106 significant subproducts. By convention, the product tokens are 2107 listed in order of their significance for identifying the 2108 application. 2110 Because this field is usually sent on every request a user agent 2111 makes, implementations are encouraged not to include needlessly fine- 2112 grained detail, and to limit (or even prohibit) the addition of 2113 subproducts by third parties. Overly long and detailed User-Agent 2114 field values make requests larger and can also be used to identify 2115 ("fingerprint") the user against their wishes. 2117 Likewise, implementations are encouraged not to use the product 2118 tokens of other implementations in order to declare compatibility 2119 with them, as this circumvents the purpose of the field. Finally, 2120 they are encouraged not to use comments to identify products; doing 2121 so makes the field value more difficult to parse. 2123 User-Agent = product *( RWS ( product / comment ) ) 2125 Example: 2127 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 2129 7. Response Status Codes 2131 The status-code element is a 3-digit integer result code of the 2132 attempt to understand and satisfy the request. 2134 HTTP status codes are extensible. HTTP applications are not required 2135 to understand the meaning of all registered status codes, though such 2136 understanding is obviously desirable. However, applications MUST 2137 understand the class of any status code, as indicated by the first 2138 digit, and treat any unrecognized response as being equivalent to the 2139 x00 status code of that class, with the exception that an 2140 unrecognized response MUST NOT be cached. For example, if an 2141 unrecognized status code of 431 is received by the client, it can 2142 safely assume that there was something wrong with its request and 2143 treat the response as if it had received a 400 status code. In such 2144 cases, user agents SHOULD present to the user the representation 2145 enclosed with the response, since that representation is likely to 2146 include human-readable information which will explain the unusual 2147 status. 2149 The first digit of the status-code defines the class of response. 2150 The last two digits do not have any categorization role. There are 5 2151 values for the first digit: 2153 o 1xx (Informational): Request received, continuing process 2154 o 2xx (Successful): The action was successfully received, 2155 understood, and accepted 2157 o 3xx (Redirection): Further action needs to be taken in order to 2158 complete the request 2160 o 4xx (Client Error): The request contains bad syntax or cannot be 2161 fulfilled 2163 o 5xx (Server Error): The server failed to fulfill an apparently 2164 valid request 2166 For most status codes the response can carry a payload, in which case 2167 a Content-Type header field indicates the payload's media type 2168 (Section 3.1.1.5). 2170 7.1. Overview of Status Codes 2172 The status codes listed below are defined in this specification, 2173 Section 4 of [Part4], Section 3 of [Part5], and Section 3 of [Part7]. 2174 The reason phrases listed here are only recommendations -- they can 2175 be replaced by local equivalents without affecting the protocol. 2177 +-------------+------------------------------+----------------------+ 2178 | status-code | reason-phrase | Defined in... | 2179 +-------------+------------------------------+----------------------+ 2180 | 100 | Continue | Section 7.2.1 | 2181 | 101 | Switching Protocols | Section 7.2.2 | 2182 | 200 | OK | Section 7.3.1 | 2183 | 201 | Created | Section 7.3.2 | 2184 | 202 | Accepted | Section 7.3.3 | 2185 | 203 | Non-Authoritative | Section 7.3.4 | 2186 | | Information | | 2187 | 204 | No Content | Section 7.3.5 | 2188 | 205 | Reset Content | Section 7.3.6 | 2189 | 206 | Partial Content | Section 3.1 of | 2190 | | | [Part5] | 2191 | 300 | Multiple Choices | Section 7.4.1 | 2192 | 301 | Moved Permanently | Section 7.4.2 | 2193 | 302 | Found | Section 7.4.3 | 2194 | 303 | See Other | Section 7.4.4 | 2195 | 304 | Not Modified | Section 4.1 of | 2196 | | | [Part4] | 2197 | 305 | Use Proxy | Section 7.4.5 | 2198 | 307 | Temporary Redirect | Section 7.4.7 | 2199 | 400 | Bad Request | Section 7.5.1 | 2200 | 401 | Unauthorized | Section 3.1 of | 2201 | | | [Part7] | 2202 | 402 | Payment Required | Section 7.5.2 | 2203 | 403 | Forbidden | Section 7.5.3 | 2204 | 404 | Not Found | Section 7.5.4 | 2205 | 405 | Method Not Allowed | Section 7.5.5 | 2206 | 406 | Not Acceptable | Section 7.5.6 | 2207 | 407 | Proxy Authentication | Section 3.2 of | 2208 | | Required | [Part7] | 2209 | 408 | Request Time-out | Section 7.5.7 | 2210 | 409 | Conflict | Section 7.5.8 | 2211 | 410 | Gone | Section 7.5.9 | 2212 | 411 | Length Required | Section 7.5.10 | 2213 | 412 | Precondition Failed | Section 4.2 of | 2214 | | | [Part4] | 2215 | 413 | Request Representation Too | Section 7.5.11 | 2216 | | Large | | 2217 | 414 | URI Too Long | Section 7.5.12 | 2218 | 415 | Unsupported Media Type | Section 7.5.13 | 2219 | 416 | Requested range not | Section 3.2 of | 2220 | | satisfiable | [Part5] | 2221 | 417 | Expectation Failed | Section 7.5.14 | 2222 | 426 | Upgrade Required | Section 7.5.15 | 2223 | 500 | Internal Server Error | Section 7.6.1 | 2224 | 501 | Not Implemented | Section 7.6.2 | 2225 | 502 | Bad Gateway | Section 7.6.3 | 2226 | 503 | Service Unavailable | Section 7.6.4 | 2227 | 504 | Gateway Time-out | Section 7.6.5 | 2228 | 505 | HTTP Version not supported | Section 7.6.6 | 2229 +-------------+------------------------------+----------------------+ 2231 Note that this list is not exhaustive -- it does not include 2232 extension status codes defined in other specifications. 2234 7.2. Informational 1xx 2236 This class of status code indicates a provisional response, 2237 consisting only of the status-line and optional header fields, and is 2238 terminated by an empty line. There are no required header fields for 2239 this class of status code. Since HTTP/1.0 did not define any 1xx 2240 status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 2241 client except under experimental conditions. 2243 A client MUST be prepared to accept one or more 1xx status responses 2244 prior to a regular response, even if the client does not expect a 100 2245 (Continue) status message. Unexpected 1xx status responses MAY be 2246 ignored by a user agent. 2248 Proxies MUST forward 1xx responses, unless the connection between the 2249 proxy and its client has been closed, or unless the proxy itself 2250 requested the generation of the 1xx response. (For example, if a 2251 proxy adds an "Expect: 100-continue" field when it forwards a 2252 request, then it need not forward the corresponding 100 (Continue) 2253 response(s).) 2255 7.2.1. 100 Continue 2257 The client SHOULD continue with its request. This interim response 2258 is used to inform the client that the initial part of the request has 2259 been received and has not yet been rejected by the server. The 2260 client SHOULD continue by sending the remainder of the request or, if 2261 the request has already been completed, ignore this response. The 2262 server MUST send a final response after the request has been 2263 completed. See Section 6.1.2.1 for detailed discussion of the use 2264 and handling of this status code. 2266 7.2.2. 101 Switching Protocols 2268 The server understands and is willing to comply with the client's 2269 request, via the Upgrade message header field (Section 6.3 of 2270 [Part1]), for a change in the application protocol being used on this 2271 connection. The server will switch protocols to those defined by the 2272 response's Upgrade header field immediately after the empty line 2273 which terminates the 101 response. 2275 The protocol SHOULD be switched only when it is advantageous to do 2276 so. For example, switching to a newer version of HTTP is 2277 advantageous over older versions, and switching to a real-time, 2278 synchronous protocol might be advantageous when delivering resources 2279 that use such features. 2281 7.3. Successful 2xx 2283 This class of status code indicates that the client's request was 2284 successfully received, understood, and accepted. 2286 7.3.1. 200 OK 2288 The request has succeeded. The payload returned with the response is 2289 dependent on the method used in the request, for example: 2291 GET a representation of the target resource is sent in the response; 2293 HEAD the same representation as GET, except without the message 2294 body; 2296 POST a representation describing or containing the result of the 2297 action; 2299 TRACE a representation containing the request message as received by 2300 the end server. 2302 Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to 2303 determine freshness for 200 responses. 2305 7.3.2. 201 Created 2307 The request has been fulfilled and has resulted in one or more new 2308 resources being created. 2310 Newly created resources are typically linked to from the response 2311 payload, with the most relevant URI also being carried in the 2312 Location header field. If the newly created resource's URI is the 2313 same as the Effective Request URI, this information can be omitted 2314 (e.g., in the case of a response to a PUT request). 2316 The origin server MUST create the resource(s) before returning the 2317 201 status code. If the action cannot be carried out immediately, 2318 the server SHOULD respond with 202 (Accepted) response instead. 2320 A 201 response MAY contain an ETag response header field indicating 2321 the current value of the entity-tag for the representation of the 2322 resource identified by the Location header field or, in case the 2323 Location header field was omitted, by the Effective Request URI (see 2324 Section 2.3 of [Part4]). 2326 7.3.3. 202 Accepted 2328 The request has been accepted for processing, but the processing has 2329 not been completed. The request might or might not eventually be 2330 acted upon, as it might be disallowed when processing actually takes 2331 place. There is no facility for re-sending a status code from an 2332 asynchronous operation such as this. 2334 The 202 response is intentionally non-committal. Its purpose is to 2335 allow a server to accept a request for some other process (perhaps a 2336 batch-oriented process that is only run once per day) without 2337 requiring that the user agent's connection to the server persist 2338 until the process is completed. The representation returned with 2339 this response SHOULD include an indication of the request's current 2340 status and either a pointer to a status monitor or some estimate of 2341 when the user can expect the request to be fulfilled. 2343 7.3.4. 203 Non-Authoritative Information 2345 The representation in the response has been transformed or otherwise 2346 modified by a transforming proxy (Section 2.3 of [Part1]). Note that 2347 the behavior of transforming intermediaries is controlled by the no- 2348 transform Cache-Control directive (Section 7.2 of [Part6]). 2350 This status code is only appropriate when the response status code 2351 would have been 200 (OK) otherwise. When the status code before 2352 transformation would have been different, the 214 Transformation 2353 Applied warn-code (Section 7.5 of [Part6]) is appropriate. 2355 Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to 2356 determine freshness for 203 responses. 2358 7.3.5. 204 No Content 2360 The 204 (No Content) status code indicates that the server has 2361 successfully fulfilled the request and that there is no additional 2362 content to return in the response payload body. Metadata in the 2363 response header fields refer to the target resource and its current 2364 representation after the requested action. 2366 For example, if a 204 status code is received in response to a PUT 2367 request and the response contains an ETag header field, then the PUT 2368 was successful and the ETag field-value contains the entity-tag for 2369 the new representation of that target resource. 2371 The 204 response allows a server to indicate that the action has been 2372 successfully applied to the target resource while implying that the 2373 user agent SHOULD NOT traverse away from its current "document view" 2374 (if any). The server assumes that the user agent will provide some 2375 indication of the success to its user, in accord with its own 2376 interface, and apply any new or updated metadata in the response to 2377 the active representation. 2379 For example, a 204 status code is commonly used with document editing 2380 interfaces corresponding to a "save" action, such that the document 2381 being saved remains available to the user for editing. It is also 2382 frequently used with interfaces that expect automated data transfers 2383 to be prevalent, such as within distributed version control systems. 2385 The 204 response MUST NOT include a message body, and thus is always 2386 terminated by the first empty line after the header fields. 2388 7.3.6. 205 Reset Content 2390 The server has fulfilled the request and the user agent SHOULD reset 2391 the document view which caused the request to be sent. This response 2392 is primarily intended to allow input for actions to take place via 2393 user input, followed by a clearing of the form in which the input is 2394 given so that the user can easily initiate another input action. 2396 The message body included with the response MUST be empty. Note that 2397 receivers still need to parse the response according to the algorithm 2398 defined in Section 3.3 of [Part1]. 2400 7.4. Redirection 3xx 2402 This class of status code indicates that further action needs to be 2403 taken by the user agent in order to fulfill the request. If the 2404 required action involves a subsequent HTTP request, it MAY be carried 2405 out by the user agent without interaction with the user if and only 2406 if the method used in the second request is known to be "safe", as 2407 defined in Section 5.2.1. 2409 There are several types of redirects: 2411 1. Redirects of the request to another URI, either temporarily or 2412 permanently. The new URI is specified in the Location header 2413 field. In this specification, the status codes 301 (Moved 2414 Permanently), 302 (Found), and 307 (Temporary Redirect) fall 2415 under this category. 2417 2. Redirection to a new location that represents an indirect 2418 response to the request, such as the result of a POST operation 2419 to be retrieved with a subsequent GET request. This is status 2420 code 303 (See Other). 2422 3. Redirection offering a choice of matching resources for use by 2423 reactive content negotiation (Section 3.4.2). This is status 2424 code 300 (Multiple Choices). 2426 4. Other kinds of redirection, such as to a cached result (status 2427 code 304 (Not Modified), see Section 4.1 of [Part4]). 2429 Note: In HTTP/1.0, only the status codes 301 (Moved Permanently) 2430 and 302 (Found) were defined for the first type of redirect, and 2431 the second type did not exist at all ([RFC1945], Section 9.3). 2432 However it turned out that web forms using POST expected redirects 2433 to change the operation for the subsequent request to retrieval 2434 (GET). To address this use case, HTTP/1.1 introduced the second 2435 type of redirect with the status code 303 (See Other) ([RFC2068], 2436 Section 10.3.4). As user agents did not change their behavior to 2437 maintain backwards compatibility, the first revision of HTTP/1.1 2438 added yet another status code, 307 (Temporary Redirect), for which 2439 the backwards compatibility problems did not apply ([RFC2616], 2440 Section 10.3.8). Over 10 years later, most user agents still do 2441 method rewriting for status codes 301 and 302, therefore this 2442 specification makes that behavior conformant in case the original 2443 request was POST. 2445 A Location header field on a 3xx response indicates that a client MAY 2446 automatically redirect to the URI provided; see Section 8.1.2. 2448 Note that for methods not known to be "safe", as defined in 2449 Section 5.2.1, automatic redirection needs to done with care, since 2450 the redirect might change the conditions under which the request was 2451 issued. 2453 Clients SHOULD detect and intervene in cyclical redirections (i.e., 2454 "infinite" redirection loops). 2456 Note: An earlier version of this specification recommended a 2457 maximum of five redirections ([RFC2068], Section 10.3). Content 2458 developers need to be aware that some clients might implement such 2459 a fixed limitation. 2461 7.4.1. 300 Multiple Choices 2463 The target resource has more than one representation, each with its 2464 own specific location, and reactive negotiation information 2465 (Section 3.4) is being provided so that the user (or user agent) can 2466 select a preferred representation by redirecting its request to that 2467 location. 2469 Unless it was a HEAD request, the response SHOULD include a 2470 representation containing a list of representation metadata and 2471 location(s) from which the user or user agent can choose the one most 2472 appropriate. Depending upon the format and the capabilities of the 2473 user agent, selection of the most appropriate choice MAY be performed 2474 automatically. However, this specification does not define any 2475 standard for such automatic selection. 2477 If the server has a preferred choice of representation, it SHOULD 2478 include the specific URI for that representation in the Location 2479 field; user agents MAY use the Location field value for automatic 2480 redirection. 2482 Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to 2483 determine freshness for 300 responses. 2485 7.4.2. 301 Moved Permanently 2487 The target resource has been assigned a new permanent URI and any 2488 future references to this resource SHOULD use one of the returned 2489 URIs. Clients with link editing capabilities ought to automatically 2490 re-link references to the effective request URI to one or more of the 2491 new references returned by the server, where possible. 2493 Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to 2494 determine freshness for 301 responses. 2496 The new permanent URI SHOULD be given by the Location field in the 2497 response. A response payload can contain a short hypertext note with 2498 a hyperlink to the new URI(s). 2500 Note: For historic reasons, user agents MAY change the request 2501 method from POST to GET for the subsequent request. If this 2502 behavior is undesired, status code 307 (Temporary Redirect) can be 2503 used instead. 2505 7.4.3. 302 Found 2507 The target resource resides temporarily under a different URI. Since 2508 the redirection might be altered on occasion, the client SHOULD 2509 continue to use the effective request URI for future requests. 2511 The temporary URI SHOULD be given by the Location field in the 2512 response. A response payload can contain a short hypertext note with 2513 a hyperlink to the new URI(s). 2515 Note: For historic reasons, user agents MAY change the request 2516 method from POST to GET for the subsequent request. If this 2517 behavior is undesired, status code 307 (Temporary Redirect) can be 2518 used instead. 2520 7.4.4. 303 See Other 2522 The 303 status code indicates that the server is redirecting the user 2523 agent to a different resource, as indicated by a URI in the Location 2524 header field, that is intended to provide an indirect response to the 2525 original request. In order to satisfy the original request, a user 2526 agent SHOULD perform a retrieval request using the Location URI (a 2527 GET or HEAD request if using HTTP), which can itself be redirected 2528 further, and present the eventual result as an answer to the original 2529 request. Note that the new URI in the Location header field is not 2530 considered equivalent to the effective request URI. 2532 This status code is generally applicable to any HTTP method. It is 2533 primarily used to allow the output of a POST action to redirect the 2534 user agent to a selected resource, since doing so provides the 2535 information corresponding to the POST response in a form that can be 2536 separately identified, bookmarked, and cached independent of the 2537 original request. 2539 A 303 response to a GET request indicates that the requested resource 2540 does not have a representation of its own that can be transferred by 2541 the server over HTTP. The Location URI indicates a resource that is 2542 descriptive of the target resource, such that the follow-on 2543 representation might be useful to recipients without implying that it 2544 adequately represents the target resource. Note that answers to the 2545 questions of what can be represented, what representations are 2546 adequate, and what might be a useful description are outside the 2547 scope of HTTP and thus entirely determined by the URI owner(s). 2549 Except for responses to a HEAD request, the representation of a 303 2550 response SHOULD contain a short hypertext note with a hyperlink to 2551 the Location URI. 2553 7.4.5. 305 Use Proxy 2555 The 305 status code was defined in a previous version of this 2556 specification (see Appendix C), and is now deprecated. 2558 7.4.6. 306 (Unused) 2560 The 306 status code was used in a previous version of the 2561 specification, is no longer used, and the code is reserved. 2563 7.4.7. 307 Temporary Redirect 2565 The target resource resides temporarily under a different URI. Since 2566 the redirection can change over time, the client SHOULD continue to 2567 use the effective request URI for future requests. 2569 The temporary URI SHOULD be given by the Location field in the 2570 response. A response payload can contain a short hypertext note with 2571 a hyperlink to the new URI(s). 2573 Note: This status code is similar to 302 (Found), except that it 2574 does not allow rewriting the request method from POST to GET. 2575 This specification defines no equivalent counterpart for 301 2576 (Moved Permanently) ([status-308], however, defines the status 2577 code 308 (Permanent Redirect) for this purpose). 2579 7.5. Client Error 4xx 2581 The 4xx class of status code is intended for cases in which the 2582 client seems to have erred. Except when responding to a HEAD 2583 request, the server SHOULD include a representation containing an 2584 explanation of the error situation, and whether it is a temporary or 2585 permanent condition. These status codes are applicable to any 2586 request method. User agents SHOULD display any included 2587 representation to the user. 2589 7.5.1. 400 Bad Request 2591 The server cannot or will not process the request, due to a client 2592 error (e.g., malformed syntax). 2594 7.5.2. 402 Payment Required 2596 This code is reserved for future use. 2598 7.5.3. 403 Forbidden 2600 The server understood the request, but refuses to authorize it. 2601 Providing different user authentication credentials might be 2602 successful, but any credentials that were provided in the request are 2603 insufficient. The request SHOULD NOT be repeated with the same 2604 credentials. 2606 If the request method was not HEAD and the server wishes to make 2607 public why the request has not been fulfilled, it SHOULD describe the 2608 reason for the refusal in the representation. If the server does not 2609 wish to make this information available to the client, the status 2610 code 404 (Not Found) MAY be used instead. 2612 7.5.4. 404 Not Found 2614 The server has not found anything matching the effective request URI. 2615 No indication is given of whether the condition is temporary or 2616 permanent. The 410 (Gone) status code SHOULD be used if the server 2617 knows, through some internally configurable mechanism, that an old 2618 resource is permanently unavailable and has no forwarding address. 2619 This status code is commonly used when the server does not wish to 2620 reveal exactly why the request has been refused, or when no other 2621 response is applicable. 2623 7.5.5. 405 Method Not Allowed 2625 The method specified in the request-line is not allowed for the 2626 target resource. The response MUST include an Allow header field 2627 containing a list of valid methods for the requested resource. 2629 7.5.6. 406 Not Acceptable 2631 The resource identified by the request is only capable of generating 2632 response representations which have content characteristics not 2633 acceptable according to the Accept and Accept-* header fields sent in 2634 the request. 2636 Unless it was a HEAD request, the response SHOULD include a 2637 representation containing a list of available representation 2638 characteristics and location(s) from which the user or user agent can 2639 choose the one most appropriate. Depending upon the format and the 2640 capabilities of the user agent, selection of the most appropriate 2641 choice MAY be performed automatically. However, this specification 2642 does not define any standard for such automatic selection. 2644 Note: HTTP/1.1 servers are allowed to return responses which are 2645 not acceptable according to the accept header fields sent in the 2646 request. In some cases, this might even be preferable to sending 2647 a 406 response. User agents are encouraged to inspect the header 2648 fields of an incoming response to determine if it is acceptable. 2650 If the response could be unacceptable, a user agent SHOULD 2651 temporarily stop receipt of more data and query the user for a 2652 decision on further actions. 2654 7.5.7. 408 Request Timeout 2656 The client did not produce a request within the time that the server 2657 was prepared to wait. The client MAY repeat the request without 2658 modifications at any later time. 2660 7.5.8. 409 Conflict 2662 The request could not be completed due to a conflict with the current 2663 state of the resource. This code is only allowed in situations where 2664 it is expected that the user might be able to resolve the conflict 2665 and resubmit the request. The payload SHOULD include enough 2666 information for the user to recognize the source of the conflict. 2667 Ideally, the response representation would include enough information 2668 for the user or user agent to fix the problem; however, that might 2669 not be possible and is not required. 2671 Conflicts are most likely to occur in response to a PUT request. For 2672 example, if versioning were being used and the representation being 2673 PUT included changes to a resource which conflict with those made by 2674 an earlier (third-party) request, the server might use the 409 2675 response to indicate that it can't complete the request. In this 2676 case, the response representation would likely contain a list of the 2677 differences between the two versions. 2679 7.5.9. 410 Gone 2681 The target resource is no longer available at the server and no 2682 forwarding address is known. This condition is expected to be 2683 considered permanent. Clients with link editing capabilities SHOULD 2684 delete references to the effective request URI after user approval. 2685 If the server does not know, or has no facility to determine, whether 2686 or not the condition is permanent, the status code 404 (Not Found) 2687 SHOULD be used instead. 2689 The 410 response is primarily intended to assist the task of web 2690 maintenance by notifying the recipient that the resource is 2691 intentionally unavailable and that the server owners desire that 2692 remote links to that resource be removed. Such an event is common 2693 for limited-time, promotional services and for resources belonging to 2694 individuals no longer working at the server's site. It is not 2695 necessary to mark all permanently unavailable resources as "gone" or 2696 to keep the mark for any length of time -- that is left to the 2697 discretion of the server owner. 2699 Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to 2700 determine freshness for 410 responses. 2702 7.5.10. 411 Length Required 2704 The server refuses to accept the request without a defined Content- 2705 Length. The client MAY repeat the request if it adds a valid 2706 Content-Length header field containing the length of the message body 2707 in the request message. 2709 7.5.11. 413 Request Representation Too Large 2711 The server is refusing to process a request because the request 2712 representation is larger than the server is willing or able to 2713 process. The server MAY close the connection to prevent the client 2714 from continuing the request. 2716 If the condition is temporary, the server SHOULD include a Retry- 2717 After header field to indicate that it is temporary and after what 2718 time the client MAY try again. 2720 7.5.12. 414 URI Too Long 2722 The server is refusing to service the request because the effective 2723 request URI is longer than the server is willing to interpret. This 2724 rare condition is only likely to occur when a client has improperly 2725 converted a POST request to a GET request with long query 2726 information, when the client has descended into a URI "black hole" of 2727 redirection (e.g., a redirected URI prefix that points to a suffix of 2728 itself), or when the server is under attack by a client attempting to 2729 exploit security holes present in some servers using fixed-length 2730 buffers for reading or manipulating the request-target. 2732 7.5.13. 415 Unsupported Media Type 2734 The server is refusing to service the request because the request 2735 payload is in a format not supported by this request method on the 2736 target resource. 2738 7.5.14. 417 Expectation Failed 2740 The expectation given in an Expect header field (see Section 6.1.2) 2741 could not be met by this server, or, if the server is a proxy, the 2742 server has unambiguous evidence that the request could not be met by 2743 the next-hop server. 2745 7.5.15. 426 Upgrade Required 2747 The request can not be completed without a prior protocol upgrade. 2748 This response MUST include an Upgrade header field (Section 6.3 of 2749 [Part1]) specifying the required protocols. 2751 Example: 2753 HTTP/1.1 426 Upgrade Required 2754 Upgrade: HTTP/3.0 2755 Connection: Upgrade 2756 Content-Length: 53 2757 Content-Type: text/plain 2759 This service requires use of the HTTP/3.0 protocol. 2761 The server SHOULD include a message body in the 426 response which 2762 indicates in human readable form the reason for the error and 2763 describes any alternative courses which might be available to the 2764 user. 2766 7.6. Server Error 5xx 2768 Response status codes beginning with the digit "5" indicate cases in 2769 which the server is aware that it has erred or is incapable of 2770 performing the request. Except when responding to a HEAD request, 2771 the server SHOULD include a representation containing an explanation 2772 of the error situation, and whether it is a temporary or permanent 2773 condition. User agents SHOULD display any included representation to 2774 the user. These response codes are applicable to any request method. 2776 7.6.1. 500 Internal Server Error 2778 The server encountered an unexpected condition which prevented it 2779 from fulfilling the request. 2781 7.6.2. 501 Not Implemented 2783 The server does not support the functionality required to fulfill the 2784 request. This is the appropriate response when the server does not 2785 recognize the request method and is not capable of supporting it for 2786 any resource. 2788 7.6.3. 502 Bad Gateway 2790 The server, while acting as a gateway or proxy, received an invalid 2791 response from the upstream server it accessed in attempting to 2792 fulfill the request. 2794 7.6.4. 503 Service Unavailable 2796 The server is currently unable to handle the request due to a 2797 temporary overloading or maintenance of the server. 2799 The implication is that this is a temporary condition which will be 2800 alleviated after some delay. If known, the length of the delay MAY 2801 be indicated in a Retry-After header field (Section 8.1.3). If no 2802 Retry-After is given, the client SHOULD handle the response as it 2803 would for a 500 (Internal Server Error) response. 2805 Note: The existence of the 503 status code does not imply that a 2806 server has to use it when becoming overloaded. Some servers might 2807 wish to simply refuse the connection. 2809 7.6.5. 504 Gateway Timeout 2811 The server, while acting as a gateway or proxy, did not receive a 2812 timely response from the upstream server specified by the URI (e.g., 2813 HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed 2814 to access in attempting to complete the request. 2816 Note to implementers: some deployed proxies are known to return 2817 400 (Bad Request) or 500 (Internal Server Error) when DNS lookups 2818 time out. 2820 7.6.6. 505 HTTP Version Not Supported 2822 The server does not support, or refuses to support, the protocol 2823 version that was used in the request message. The server is 2824 indicating that it is unable or unwilling to complete the request 2825 using the same major version as the client, as described in Section 2826 2.6 of [Part1], other than with this error message. The response 2827 SHOULD contain a representation describing why that version is not 2828 supported and what other protocols are supported by that server. 2830 8. Response Header Fields 2832 The response header fields allow the server to pass additional 2833 information about the response which cannot be placed in the status- 2834 line. These header fields give information about the server and 2835 about further access to the target resource (Section 5.5 of [Part1]). 2837 8.1. Control Data 2839 Response header fields can supply control data that supplements the 2840 status code or instructs the client where to go next. 2842 +-------------------+------------------------+ 2843 | Header Field Name | Defined in... | 2844 +-------------------+------------------------+ 2845 | Age | Section 7.1 of [Part6] | 2846 | Date | Section 8.1.1.2 | 2847 | Location | Section 8.1.2 | 2848 | Retry-After | Section 8.1.3 | 2849 +-------------------+------------------------+ 2851 8.1.1. Origination Date 2853 8.1.1.1. Date/Time Formats 2855 HTTP applications have historically allowed three different formats 2856 for date/time stamps. However, the preferred format is a fixed- 2857 length subset of that defined by [RFC1123]: 2859 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 2861 The other formats are described here only for compatibility with 2862 obsolete implementations. 2864 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 2865 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 2867 HTTP/1.1 clients and servers that parse a date value MUST accept all 2868 three formats (for compatibility with HTTP/1.0), though they MUST 2869 only generate the RFC 1123 format for representing HTTP-date values 2870 in header fields. 2872 All HTTP date/time stamps MUST be represented in Greenwich Mean Time 2873 (GMT), without exception. For the purposes of HTTP, GMT is exactly 2874 equal to UTC (Coordinated Universal Time). This is indicated in the 2875 first two formats by the inclusion of "GMT" as the three-letter 2876 abbreviation for time zone, and MUST be assumed when reading the 2877 asctime format. HTTP-date is case sensitive and MUST NOT include 2878 additional whitespace beyond that specifically included as SP in the 2879 grammar. 2881 HTTP-date = rfc1123-date / obs-date 2883 Preferred format: 2885 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT 2886 ; fixed length subset of the format defined in 2887 ; Section 5.2.14 of [RFC1123] 2889 day-name = %x4D.6F.6E ; "Mon", case-sensitive 2890 / %x54.75.65 ; "Tue", case-sensitive 2891 / %x57.65.64 ; "Wed", case-sensitive 2892 / %x54.68.75 ; "Thu", case-sensitive 2893 / %x46.72.69 ; "Fri", case-sensitive 2894 / %x53.61.74 ; "Sat", case-sensitive 2895 / %x53.75.6E ; "Sun", case-sensitive 2897 date1 = day SP month SP year 2898 ; e.g., 02 Jun 1982 2900 day = 2DIGIT 2901 month = %x4A.61.6E ; "Jan", case-sensitive 2902 / %x46.65.62 ; "Feb", case-sensitive 2903 / %x4D.61.72 ; "Mar", case-sensitive 2904 / %x41.70.72 ; "Apr", case-sensitive 2905 / %x4D.61.79 ; "May", case-sensitive 2906 / %x4A.75.6E ; "Jun", case-sensitive 2907 / %x4A.75.6C ; "Jul", case-sensitive 2908 / %x41.75.67 ; "Aug", case-sensitive 2909 / %x53.65.70 ; "Sep", case-sensitive 2910 / %x4F.63.74 ; "Oct", case-sensitive 2911 / %x4E.6F.76 ; "Nov", case-sensitive 2912 / %x44.65.63 ; "Dec", case-sensitive 2913 year = 4DIGIT 2915 GMT = %x47.4D.54 ; "GMT", case-sensitive 2917 time-of-day = hour ":" minute ":" second 2918 ; 00:00:00 - 23:59:59 2920 hour = 2DIGIT 2921 minute = 2DIGIT 2922 second = 2DIGIT 2924 The semantics of day-name, day, month, year, and time-of-day are the 2925 same as those defined for the RFC 5322 constructs with the 2926 corresponding name ([RFC5322], Section 3.3). 2928 Obsolete formats: 2930 obs-date = rfc850-date / asctime-date 2931 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 2932 date2 = day "-" month "-" 2DIGIT 2933 ; day-month-year (e.g., 02-Jun-82) 2935 day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive 2936 / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive 2937 / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive 2938 / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive 2939 / %x46.72.69.64.61.79 ; "Friday", case-sensitive 2940 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 2941 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 2943 asctime-date = day-name SP date3 SP time-of-day SP year 2944 date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) 2945 ; month day (e.g., Jun 2) 2947 Note: Recipients of date values are encouraged to be robust in 2948 accepting date values that might have been sent by non-HTTP 2949 applications, as is sometimes the case when retrieving or posting 2950 messages via proxies/gateways to SMTP or NNTP. 2952 Note: HTTP requirements for the date/time stamp format apply only 2953 to their usage within the protocol stream. Clients and servers 2954 are not required to use these formats for user presentation, 2955 request logging, etc. 2957 8.1.1.2. Date 2959 The "Date" header field represents the date and time at which the 2960 message was originated, having the same semantics as the Origination 2961 Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The 2962 field value is an HTTP-date, as defined in Section 8.1.1.1; it MUST 2963 be sent in rfc1123-date format. 2965 Date = HTTP-date 2967 An example is 2969 Date: Tue, 15 Nov 1994 08:12:31 GMT 2971 Origin servers MUST include a Date header field in all responses, 2972 except in these cases: 2974 1. If the response status code is 100 (Continue) or 101 (Switching 2975 Protocols), the response MAY include a Date header field, at the 2976 server's option. 2978 2. If the response status code conveys a server error, e.g., 500 2979 (Internal Server Error) or 503 (Service Unavailable), and it is 2980 inconvenient or impossible to generate a valid Date. 2982 3. If the server does not have a clock that can provide a reasonable 2983 approximation of the current time, its responses MUST NOT include 2984 a Date header field. 2986 A received message that does not have a Date header field MUST be 2987 assigned one by the recipient if the message will be cached by that 2988 recipient. 2990 Clients can use the Date header field as well; in order to keep 2991 request messages small, they are advised not to include it when it 2992 doesn't convey any useful information (as is usually the case for 2993 requests that do not contain a payload). 2995 The HTTP-date sent in a Date header field SHOULD NOT represent a date 2996 and time subsequent to the generation of the message. It SHOULD 2997 represent the best available approximation of the date and time of 2998 message generation, unless the implementation has no means of 2999 generating a reasonably accurate date and time. In theory, the date 3000 ought to represent the moment just before the payload is generated. 3001 In practice, the date can be generated at any time during the message 3002 origination without affecting its semantic value. 3004 8.1.2. Location 3006 The "Location" header field MAY be sent in responses to refer to a 3007 specific resource in accordance with the semantics of the status 3008 code. 3010 Location = URI-reference 3012 For 201 (Created) responses, the Location is the URI of the new 3013 resource which was created by the request. For 3xx (Redirection) 3014 responses, the location SHOULD indicate the server's preferred URI 3015 for automatic redirection to the resource. 3017 The field value consists of a single URI-reference. When it has the 3018 form of a relative reference ([RFC3986], Section 4.2), the final 3019 value is computed by resolving it against the effective request URI 3020 ([RFC3986], Section 5). If the original URI, as navigated to by the 3021 user agent, did contain a fragment identifier, and the final value 3022 does not, then the original URI's fragment identifier is added to the 3023 final value. 3025 For example, the original URI "http://www.example.org/~tim", combined 3026 with a field value given as: 3028 Location: /pub/WWW/People.html#tim 3030 would result in a final value of 3031 "http://www.example.org/pub/WWW/People.html#tim" 3033 An original URI "http://www.example.org/index.html#larry", combined 3034 with a field value given as: 3036 Location: http://www.example.net/index.html 3038 would result in a final value of 3039 "http://www.example.net/index.html#larry", preserving the original 3040 fragment identifier. 3042 Note: Some recipients attempt to recover from Location fields that 3043 are not valid URI references. This specification does not mandate 3044 or define such processing, but does allow it. 3046 There are circumstances in which a fragment identifier in a Location 3047 URI would not be appropriate. For instance, when it appears in a 201 3048 (Created) response, where the Location header field specifies the URI 3049 for the entire created resource. 3051 Note: The Content-Location header field (Section 3.1.4.2) differs 3052 from Location in that the Content-Location identifies the most 3053 specific resource corresponding to the enclosed representation. 3054 It is therefore possible for a response to contain header fields 3055 for both Location and Content-Location. 3057 8.1.3. Retry-After 3059 The header "Retry-After" field can be used with a 503 (Service 3060 Unavailable) response to indicate how long the service is expected to 3061 be unavailable to the requesting client. This field MAY also be used 3062 with any 3xx (Redirection) response to indicate the minimum time the 3063 user-agent is asked to wait before issuing the redirected request. 3065 The value of this field can be either an HTTP-date or an integer 3066 number of seconds (in decimal) after the time of the response. 3068 Retry-After = HTTP-date / delta-seconds 3070 Time spans are non-negative decimal integers, representing time in 3071 seconds. 3073 delta-seconds = 1*DIGIT 3075 Two examples of its use are 3077 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 3078 Retry-After: 120 3080 In the latter example, the delay is 2 minutes. 3082 8.2. Selected Representation Header Fields 3084 We use the term "selected representation" to refer to the the current 3085 representation of a target resource that would have been selected in 3086 a successful response if the same request had used the method GET and 3087 excluded any conditional request header fields. 3089 Additional header fields define metadata about the selected 3090 representation, which might differ from the representation included 3091 in the message for responses to some state-changing methods. The 3092 following header fields are defined as selected representation 3093 metadata: 3095 +-------------------+------------------------+ 3096 | Header Field Name | Defined in... | 3097 +-------------------+------------------------+ 3098 | ETag | Section 2.3 of [Part4] | 3099 | Last-Modified | Section 2.2 of [Part4] | 3100 | Vary | Section 8.2.1 | 3101 +-------------------+------------------------+ 3103 8.2.1. Vary 3105 The "Vary" header field conveys the set of header fields that were 3106 used to select the representation. 3108 Caches use this information as part of determining whether a stored 3109 response can be used to satisfy a given request (Section 4.3 of 3110 [Part6]). 3112 In uncacheable or stale responses, the Vary field value advises the 3113 user agent about the criteria that were used to select the 3114 representation. 3116 Vary = "*" / 1#field-name 3118 The set of header fields named by the Vary field value is known as 3119 the selecting header fields. 3121 A server SHOULD include a Vary header field with any cacheable 3122 response that is subject to proactive negotiation. Doing so allows a 3123 cache to properly interpret future requests on that resource and 3124 informs the user agent about the presence of negotiation on that 3125 resource. A server MAY include a Vary header field with a non- 3126 cacheable response that is subject to proactive negotiation, since 3127 this might provide the user agent with useful information about the 3128 dimensions over which the response varies at the time of the 3129 response. 3131 A Vary field value of "*" signals that unspecified parameters not 3132 limited to the header fields (e.g., the network address of the 3133 client), play a role in the selection of the response representation; 3134 therefore, a cache cannot determine whether this response is 3135 appropriate. A proxy MUST NOT generate the "*" value. 3137 The field-names given are not limited to the set of standard header 3138 fields defined by this specification. Field names are case- 3139 insensitive. 3141 8.3. Authentication Challenges 3143 Authentication challenges indicate what mechanisms are available for 3144 the client to provide authentication credentials in future requests. 3146 +--------------------+------------------------+ 3147 | Header Field Name | Defined in... | 3148 +--------------------+------------------------+ 3149 | WWW-Authenticate | Section 4.4 of [Part7] | 3150 | Proxy-Authenticate | Section 4.2 of [Part7] | 3151 +--------------------+------------------------+ 3153 8.4. Informative 3155 The remaining response header fields provide more information about 3156 the target resource for potential use in later requests. 3158 +-------------------+------------------------+ 3159 | Header Field Name | Defined in... | 3160 +-------------------+------------------------+ 3161 | Accept-Ranges | Section 5.1 of [Part5] | 3162 | Allow | Section 8.4.1 | 3163 | Server | Section 8.4.2 | 3164 +-------------------+------------------------+ 3166 8.4.1. Allow 3168 The "Allow" header field lists the set of methods advertised as 3169 supported by the target resource. The purpose of this field is 3170 strictly to inform the recipient of valid request methods associated 3171 with the resource. 3173 Allow = #method 3175 Example of use: 3177 Allow: GET, HEAD, PUT 3179 The actual set of allowed methods is defined by the origin server at 3180 the time of each request. 3182 A proxy MUST NOT modify the Allow header field -- it does not need to 3183 understand all the methods specified in order to handle them 3184 according to the generic message handling rules. 3186 8.4.2. Server 3188 The "Server" header field contains information about the software 3189 used by the origin server to handle the request. 3191 The field can contain multiple product tokens (Section 4) and 3192 comments (Section 3.2 of [Part1]) identifying the server and any 3193 significant subproducts. The product tokens are listed in order of 3194 their significance for identifying the application. 3196 Server = product *( RWS ( product / comment ) ) 3198 Example: 3200 Server: CERN/3.0 libwww/2.17 3202 If the response is being forwarded through a proxy, the proxy 3203 application MUST NOT modify the Server header field. Instead, it 3204 MUST include a Via field (as described in Section 5.7 of [Part1]). 3206 Note: Revealing the specific software version of the server might 3207 allow the server machine to become more vulnerable to attacks 3208 against software that is known to contain security holes. Server 3209 implementers are encouraged to make this field a configurable 3210 option. 3212 9. IANA Considerations 3214 9.1. Method Registry 3216 The HTTP Method Registry defines the name space for the request 3217 method token (Section 5). The method registry is maintained at 3218 . 3220 9.1.1. Procedure 3222 HTTP method registrations MUST include the following fields: 3224 o Method Name (see Section 5) 3226 o Safe ("yes" or "no", see Section 5.2.1) 3228 o Idempotent ("yes" or "no", see Section 5.2.2) 3230 o Pointer to specification text 3232 Values to be added to this name space require IETF Review (see 3233 [RFC5226], Section 4.1). 3235 9.1.2. Considerations for New Methods 3237 Standardized methods are generic; that is, they are potentially 3238 applicable to any resource, not just one particular media type, kind 3239 of resource, or application. As such, it is preferred that new 3240 methods be registered in a document that isn't specific to a single 3241 application or data format, since orthogonal technologies deserve 3242 orthogonal specification. 3244 Since message parsing (Section 3.3 of [Part1]) needs to be 3245 independent of method semantics (aside from responses to HEAD), 3246 definitions of new methods cannot change the parsing algorithm or 3247 prohibit the presence of a message body on either the request or the 3248 response message. Definitions of new methods can specify that only a 3249 zero-length message body is allowed by requiring a Content-Length 3250 header field with a value of "0". 3252 New method definitions need to indicate whether they are safe 3253 (Section 5.2.1), idempotent (Section 5.2.2), cacheable 3254 (Section 5.2.3), and what semantics are to be associated with the 3255 payload body if any is present in the request. If a method is 3256 cacheable, the method definition ought to describe how, and under 3257 what conditions, a cache can store a response and use it to satisfy a 3258 subsequent request. 3260 9.1.3. Registrations 3262 The HTTP Method Registry shall be populated with the registrations 3263 below: 3265 +---------+------+------------+---------------+ 3266 | Method | Safe | Idempotent | Reference | 3267 +---------+------+------------+---------------+ 3268 | CONNECT | no | no | Section 5.3.6 | 3269 | DELETE | no | yes | Section 5.3.5 | 3270 | GET | yes | yes | Section 5.3.1 | 3271 | HEAD | yes | yes | Section 5.3.2 | 3272 | OPTIONS | yes | yes | Section 5.3.7 | 3273 | POST | no | no | Section 5.3.3 | 3274 | PUT | no | yes | Section 5.3.4 | 3275 | TRACE | yes | yes | Section 5.3.8 | 3276 +---------+------+------------+---------------+ 3278 9.2. Status Code Registry 3280 The HTTP Status Code Registry defines the name space for the response 3281 status-code token (Section 7). The status code registry is 3282 maintained at . 3284 This section replaces the registration procedure for HTTP Status 3285 Codes previously defined in Section 7.1 of [RFC2817]. 3287 9.2.1. Procedure 3289 Values to be added to the HTTP status code name space require IETF 3290 Review (see [RFC5226], Section 4.1). 3292 9.2.2. Considerations for New Status Codes 3294 When it is necessary to express semantics for a response that are not 3295 defined by current status codes, a new status code can be registered. 3296 HTTP status codes are generic; they are potentially applicable to any 3297 resource, not just one particular media type, "type" of resource, or 3298 application. As such, it is preferred that new status codes be 3299 registered in a document that isn't specific to a single application. 3301 New status codes are required to fall under one of the categories 3302 defined in Section 7. To allow existing parsers to properly handle 3303 them, new status codes cannot disallow a payload, although they can 3304 mandate a zero-length payload body. 3306 A definition for a new status code ought to explain the request 3307 conditions that produce a response containing that status code (e.g., 3308 combinations of request header fields and/or method(s)) along with 3309 any dependencies on response header fields (e.g., what fields are 3310 required and what fields can modify the semantics). A response that 3311 can transfer a payload ought to specify expected cache behavior 3312 (e.g., cacheability and freshness criteria, as described in [Part6]) 3313 and whether the payload has any implied association with an 3314 identified resource (Section 3.1.4.1). 3316 9.2.3. Registrations 3318 The HTTP Status Code Registry shall be updated with the registrations 3319 below: 3321 +-------+----------------------------------+----------------+ 3322 | Value | Description | Reference | 3323 +-------+----------------------------------+----------------+ 3324 | 100 | Continue | Section 7.2.1 | 3325 | 101 | Switching Protocols | Section 7.2.2 | 3326 | 200 | OK | Section 7.3.1 | 3327 | 201 | Created | Section 7.3.2 | 3328 | 202 | Accepted | Section 7.3.3 | 3329 | 203 | Non-Authoritative Information | Section 7.3.4 | 3330 | 204 | No Content | Section 7.3.5 | 3331 | 205 | Reset Content | Section 7.3.6 | 3332 | 300 | Multiple Choices | Section 7.4.1 | 3333 | 301 | Moved Permanently | Section 7.4.2 | 3334 | 302 | Found | Section 7.4.3 | 3335 | 303 | See Other | Section 7.4.4 | 3336 | 305 | Use Proxy | Section 7.4.5 | 3337 | 306 | (Unused) | Section 7.4.6 | 3338 | 307 | Temporary Redirect | Section 7.4.7 | 3339 | 400 | Bad Request | Section 7.5.1 | 3340 | 402 | Payment Required | Section 7.5.2 | 3341 | 403 | Forbidden | Section 7.5.3 | 3342 | 404 | Not Found | Section 7.5.4 | 3343 | 405 | Method Not Allowed | Section 7.5.5 | 3344 | 406 | Not Acceptable | Section 7.5.6 | 3345 | 408 | Request Timeout | Section 7.5.7 | 3346 | 409 | Conflict | Section 7.5.8 | 3347 | 410 | Gone | Section 7.5.9 | 3348 | 411 | Length Required | Section 7.5.10 | 3349 | 413 | Request Representation Too Large | Section 7.5.11 | 3350 | 414 | URI Too Long | Section 7.5.12 | 3351 | 415 | Unsupported Media Type | Section 7.5.13 | 3352 | 417 | Expectation Failed | Section 7.5.14 | 3353 | 426 | Upgrade Required | Section 7.5.15 | 3354 | 500 | Internal Server Error | Section 7.6.1 | 3355 | 501 | Not Implemented | Section 7.6.2 | 3356 | 502 | Bad Gateway | Section 7.6.3 | 3357 | 503 | Service Unavailable | Section 7.6.4 | 3358 | 504 | Gateway Timeout | Section 7.6.5 | 3359 | 505 | HTTP Version Not Supported | Section 7.6.6 | 3360 +-------+----------------------------------+----------------+ 3362 9.3. Header Field Registry 3364 HTTP header fields are registered within the Message Header Field 3365 Registry located at , as defined by [RFC3864]. 3368 9.3.1. Considerations for New Header Fields 3370 Header fields are key:value pairs that can be used to communicate 3371 data about the message, its payload, the target resource, or the 3372 connection (i.e., control data). See Section 3.2 of [Part1] for a 3373 general definition of header field syntax in HTTP messages. 3375 The requirements for header field names are defined in Section 4.1 of 3376 [RFC3864]. Authors of specifications defining new fields are advised 3377 to keep the name as short as practical, and not to prefix them with 3378 "X-" if they are to be registered (either immediately or in the 3379 future). 3381 New header field values typically have their syntax defined using 3382 ABNF ([RFC5234]), using the extension defined in Appendix B of 3383 [Part1] as necessary, and are usually constrained to the range of 3384 ASCII characters. Header fields needing a greater range of 3385 characters can use an encoding such as the one defined in [RFC5987]. 3387 Because commas (",") are used as a generic delimiter between field- 3388 values, they need to be treated with care if they are allowed in the 3389 field-value's payload. Typically, components that might contain a 3390 comma are protected with double-quotes using the quoted-string ABNF 3391 production (Section 3.2.4 of [Part1]). 3393 For example, a textual date and a URI (either of which might contain 3394 a comma) could be safely carried in field-values like these: 3396 Example-URI-Field: "http://example.com/a.html,foo", 3397 "http://without-a-comma.example.com/" 3398 Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" 3400 Note that double-quote delimiters almost always are used with the 3401 quoted-string production; using a different syntax inside double- 3402 quotes will likely cause unnecessary confusion. 3404 Many header fields use a format including (case-insensitively) named 3405 parameters (for instance, Content-Type, defined in Section 3.1.1.5). 3406 Allowing both unquoted (token) and quoted (quoted-string) syntax for 3407 the parameter value enables recipients to use existing parser 3408 components. When allowing both forms, the meaning of a parameter 3409 value ought to be independent of the syntax used for it (for an 3410 example, see the notes on parameter handling for media types in 3411 Section 3.1.1.1). 3413 Authors of specifications defining new header fields are advised to 3414 consider documenting: 3416 o Whether the field is a single value, or whether it can be a list 3417 (delimited by commas; see Section 3.2 of [Part1]). 3419 If it does not use the list syntax, document how to treat messages 3420 where the header field occurs multiple times (a sensible default 3421 would be to ignore the header field, but this might not always be 3422 the right choice). 3424 Note that intermediaries and software libraries might combine 3425 multiple header field instances into a single one, despite the 3426 header field not allowing this. A robust format enables 3427 recipients to discover these situations (good example: "Content- 3428 Type", as the comma can only appear inside quoted strings; bad 3429 example: "Location", as a comma can occur inside a URI). 3431 o Under what conditions the header field can be used; e.g., only in 3432 responses or requests, in all messages, only on responses to a 3433 particular request method. 3435 o Whether it is appropriate to list the field-name in the Connection 3436 header field (i.e., if the header field is to be hop-by-hop, see 3437 Section 6.1 of [Part1]). 3439 o Under what conditions intermediaries are allowed to modify the 3440 header field's value, insert or delete it. 3442 o How the header field might interact with caching (see [Part6]). 3444 o Whether the header field is useful or allowable in trailers (see 3445 Section 4.1 of [Part1]). 3447 o Whether the header field ought to be preserved across redirects. 3449 9.3.2. Registrations 3451 The Message Header Field Registry shall be updated with the following 3452 permanent registrations: 3454 +-------------------+----------+----------+-----------------+ 3455 | Header Field Name | Protocol | Status | Reference | 3456 +-------------------+----------+----------+-----------------+ 3457 | Accept | http | standard | Section 6.3.2 | 3458 | Accept-Charset | http | standard | Section 6.3.3 | 3459 | Accept-Encoding | http | standard | Section 6.3.4 | 3460 | Accept-Language | http | standard | Section 6.3.5 | 3461 | Allow | http | standard | Section 8.4.1 | 3462 | Content-Encoding | http | standard | Section 3.1.2.2 | 3463 | Content-Language | http | standard | Section 3.1.3.2 | 3464 | Content-Location | http | standard | Section 3.1.4.2 | 3465 | Content-Type | http | standard | Section 3.1.1.5 | 3466 | Date | http | standard | Section 8.1.1.2 | 3467 | Expect | http | standard | Section 6.1.2 | 3468 | From | http | standard | Section 6.5.1 | 3469 | Location | http | standard | Section 8.1.2 | 3470 | MIME-Version | http | standard | Appendix A.1 | 3471 | Max-Forwards | http | standard | Section 6.1.1 | 3472 | Referer | http | standard | Section 6.5.2 | 3473 | Retry-After | http | standard | Section 8.1.3 | 3474 | Server | http | standard | Section 8.4.2 | 3475 | User-Agent | http | standard | Section 6.5.3 | 3476 | Vary | http | standard | Section 8.2.1 | 3477 +-------------------+----------+----------+-----------------+ 3479 The change controller for the above registrations is: "IETF 3480 (iesg@ietf.org) - Internet Engineering Task Force". 3482 9.4. Content Coding Registry 3484 The HTTP Content Coding Registry defines the name space for content 3485 coding names (Section 4.2 of [Part1]). The content coding registry 3486 is maintained at . 3488 9.4.1. Procedure 3490 Content Coding registrations MUST include the following fields: 3492 o Name 3494 o Description 3496 o Pointer to specification text 3498 Names of content codings MUST NOT overlap with names of transfer 3499 codings (Section 4 of [Part1]), unless the encoding transformation is 3500 identical (as is the case for the compression codings defined in 3501 Section 4.2 of [Part1]). 3503 Values to be added to this name space require IETF Review (see 3504 Section 4.1 of [RFC5226]), and MUST conform to the purpose of content 3505 coding defined in this section. 3507 9.4.2. Registrations 3509 The HTTP Content Codings Registry shall be updated with the 3510 registrations below: 3512 +----------+----------------------------------------+---------------+ 3513 | Name | Description | Reference | 3514 +----------+----------------------------------------+---------------+ 3515 | compress | UNIX "compress" program method | Section 4.2.1 | 3516 | | | of [Part1] | 3517 | deflate | "deflate" compression mechanism | Section 4.2.2 | 3518 | | ([RFC1951]) used inside the "zlib" | of [Part1] | 3519 | | data format ([RFC1950]) | | 3520 | gzip | Same as GNU zip [RFC1952] | Section 4.2.3 | 3521 | | | of [Part1] | 3522 | identity | reserved (synonym for "no encoding" in | Section 6.3.4 | 3523 | | Accept-Encoding header field) | | 3524 +----------+----------------------------------------+---------------+ 3526 10. Security Considerations 3528 This section is meant to inform application developers, information 3529 providers, and users of the security limitations in HTTP/1.1 as 3530 described by this document. The discussion does not include 3531 definitive solutions to the problems revealed, though it does make 3532 some suggestions for reducing security risks. 3534 10.1. Transfer of Sensitive Information 3536 Like any generic data transfer protocol, HTTP cannot regulate the 3537 content of the data that is transferred, nor is there any a priori 3538 method of determining the sensitivity of any particular piece of 3539 information within the context of any given request. Therefore, 3540 applications SHOULD supply as much control over this information as 3541 possible to the provider of that information. Four header fields are 3542 worth special mention in this context: Server, Via, Referer and From. 3544 Revealing the specific software version of the server might allow the 3545 server machine to become more vulnerable to attacks against software 3546 that is known to contain security holes. Implementers SHOULD make 3547 the Server header field a configurable option. 3549 Proxies which serve as a portal through a network firewall SHOULD 3550 take special precautions regarding the transfer of header information 3551 that identifies the hosts behind the firewall. In particular, they 3552 SHOULD remove, or replace with sanitized versions, any Via fields 3553 generated behind the firewall. 3555 The Referer header field allows reading patterns to be studied and 3556 reverse links drawn. Although it can be very useful, its power can 3557 be abused if user details are not separated from the information 3558 contained in the Referer. Even when the personal information has 3559 been removed, the Referer header field might indicate a private 3560 document's URI whose publication would be inappropriate. 3562 The information sent in the From field might conflict with the user's 3563 privacy interests or their site's security policy, and hence it 3564 SHOULD NOT be transmitted without the user being able to disable, 3565 enable, and modify the contents of the field. The user MUST be able 3566 to set the contents of this field within a user preference or 3567 application defaults configuration. 3569 We suggest, though do not require, that a convenient toggle interface 3570 be provided for the user to enable or disable the sending of From and 3571 Referer information. 3573 The User-Agent (Section 6.5.3) or Server (Section 8.4.2) header 3574 fields can sometimes be used to determine that a specific client or 3575 server has a particular security hole which might be exploited. 3576 Unfortunately, this same information is often used for other valuable 3577 purposes for which HTTP currently has no better mechanism. 3579 Furthermore, the User-Agent header field might contain enough entropy 3580 to be used, possibly in conjunction with other material, to uniquely 3581 identify the user. 3583 Some request methods, like TRACE (Section 5.3.8), expose information 3584 that was sent in request header fields within the body of their 3585 response. Clients SHOULD be careful with sensitive information, like 3586 Cookies, Authorization credentials, and other header fields that 3587 might be used to collect data from the client. 3589 10.2. Encoding Sensitive Information in URIs 3591 Because the source of a link might be private information or might 3592 reveal an otherwise private information source, it is strongly 3593 recommended that the user be able to select whether or not the 3594 Referer field is sent. For example, a browser client could have a 3595 toggle switch for browsing openly/anonymously, which would 3596 respectively enable/disable the sending of Referer and From 3597 information. 3599 Clients SHOULD NOT include a Referer header field in a (non-secure) 3600 HTTP request if the referring page was transferred with a secure 3601 protocol. 3603 Authors of services SHOULD NOT use GET-based forms for the submission 3604 of sensitive data because that data will be placed in the request- 3605 target. Many existing servers, proxies, and user agents log or 3606 display the request-target in places where it might be visible to 3607 third parties. Such services can use POST-based form submission 3608 instead. 3610 10.3. Location Header Fields: Spoofing and Information Leakage 3612 If a single server supports multiple organizations that do not trust 3613 one another, then it MUST check the values of Location and Content- 3614 Location header fields in responses that are generated under control 3615 of said organizations to make sure that they do not attempt to 3616 invalidate resources over which they have no authority. 3618 Furthermore, appending the fragment identifier from one URI to 3619 another one obtained from a Location header field might leak 3620 confidential information to the target server -- although the 3621 fragment identifier is not transmitted in the final request, it might 3622 be visible to the user agent through other means, such as scripting. 3624 10.4. Security Considerations for CONNECT 3626 Since tunneled data is opaque to the proxy, there are additional 3627 risks to tunneling to other well-known or reserved ports. A HTTP 3628 client CONNECTing to port 25 could relay spam via SMTP, for example. 3629 As such, proxies SHOULD restrict CONNECT access to a small number of 3630 known ports. 3632 10.5. Privacy Issues Connected to Accept Header Fields 3634 Accept header fields can reveal information about the user to all 3635 servers which are accessed. The Accept-Language header field in 3636 particular can reveal information the user would consider to be of a 3637 private nature, because the understanding of particular languages is 3638 often strongly correlated to the membership of a particular ethnic 3639 group. User agents which offer the option to configure the contents 3640 of an Accept-Language header field to be sent in every request are 3641 strongly encouraged to let the configuration process include a 3642 message which makes the user aware of the loss of privacy involved. 3644 An approach that limits the loss of privacy would be for a user agent 3645 to omit the sending of Accept-Language header fields by default, and 3646 to ask the user whether or not to start sending Accept-Language 3647 header fields to a server if it detects, by looking for any Vary 3648 header fields generated by the server, that such sending could 3649 improve the quality of service. 3651 Elaborate user-customized accept header fields sent in every request, 3652 in particular if these include quality values, can be used by servers 3653 as relatively reliable and long-lived user identifiers. Such user 3654 identifiers would allow content providers to do click-trail tracking, 3655 and would allow collaborating content providers to match cross-server 3656 click-trails or form submissions of individual users. Note that for 3657 many users not behind a proxy, the network address of the host 3658 running the user agent will also serve as a long-lived user 3659 identifier. In environments where proxies are used to enhance 3660 privacy, user agents ought to be conservative in offering accept 3661 header field configuration options to end users. As an extreme 3662 privacy measure, proxies could filter the accept header fields in 3663 relayed requests. General purpose user agents which provide a high 3664 degree of header field configurability SHOULD warn users about the 3665 loss of privacy which can be involved. 3667 11. Acknowledgments 3669 See Section 9 of [Part1]. 3671 12. References 3673 12.1. Normative References 3675 [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 3676 Transfer Protocol (HTTP/1.1): Message Syntax and 3677 Routing", draft-ietf-httpbis-p1-messaging-21 (work in 3678 progress), October 2012. 3680 [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 3681 Transfer Protocol (HTTP/1.1): Conditional Requests", 3682 draft-ietf-httpbis-p4-conditional-21 (work in 3683 progress), October 2012. 3685 [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 3686 "Hypertext Transfer Protocol (HTTP/1.1): Range 3687 Requests", draft-ietf-httpbis-p5-range-21 (work in 3688 progress), October 2012. 3690 [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 3691 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 3692 draft-ietf-httpbis-p6-cache-21 (work in progress), 3693 October 2012. 3695 [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 3696 Transfer Protocol (HTTP/1.1): Authentication", 3697 draft-ietf-httpbis-p7-auth-21 (work in progress), 3698 October 2012. 3700 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data 3701 Format Specification version 3.3", RFC 1950, May 1996. 3703 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format 3704 Specification version 1.3", RFC 1951, May 1996. 3706 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and 3707 G. Randers-Pehrson, "GZIP file format specification 3708 version 4.3", RFC 1952, May 1996. 3710 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet 3711 Mail Extensions (MIME) Part One: Format of Internet 3712 Message Bodies", RFC 2045, November 1996. 3714 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet 3715 Mail Extensions (MIME) Part Two: Media Types", 3716 RFC 2046, November 1996. 3718 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3719 Requirement Levels", BCP 14, RFC 2119, March 1997. 3721 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 3722 "Uniform Resource Identifier (URI): Generic Syntax", 3723 STD 66, RFC 3986, January 2005. 3725 [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of 3726 Language Tags", BCP 47, RFC 4647, September 2006. 3728 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for 3729 Syntax Specifications: ABNF", STD 68, RFC 5234, 3730 January 2008. 3732 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for 3733 Identifying Languages", BCP 47, RFC 5646, 3734 September 2009. 3736 12.2. Informative References 3738 [REST] Fielding, R., "Architectural Styles and the Design of 3739 Network-based Software Architectures", Doctoral 3740 Dissertation, University of California, Irvine , 3741 September 2000, 3742 . 3744 [RFC1123] Braden, R., "Requirements for Internet Hosts - 3745 Application and Support", STD 3, RFC 1123, 3746 October 1989. 3748 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, 3749 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, 3750 May 1996. 3752 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet 3753 Mail Extensions (MIME) Part Five: Conformance Criteria 3754 and Examples", RFC 2049, November 1996. 3756 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and 3757 T. Berners-Lee, "Hypertext Transfer Protocol -- 3758 HTTP/1.1", RFC 2068, January 1997. 3760 [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, 3761 February 1997. 3763 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 3764 Languages", BCP 18, RFC 2277, January 1998. 3766 [RFC2295] Holtman, K. and A. Mutz, "Transparent Content 3767 Negotiation in HTTP", RFC 2295, March 1998. 3769 [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ 3770 form-data", RFC 2388, August 1998. 3772 [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, 3773 "MIME Encapsulation of Aggregate Documents, such as 3774 HTML (MHTML)", RFC 2557, March 1999. 3776 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3777 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3778 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3780 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 3781 HTTP/1.1", RFC 2817, May 2000. 3783 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 3784 10646", STD 63, RFC 3629, November 2003. 3786 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 3787 Procedures for Message Header Fields", BCP 90, 3788 RFC 3864, September 2004. 3790 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications 3791 and Registration Procedures", BCP 13, RFC 4288, 3792 December 2005. 3794 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 3795 an IANA Considerations Section in RFCs", BCP 26, 3796 RFC 5226, May 2008. 3798 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 3799 October 2008. 3801 [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", 3802 RFC 5789, March 2010. 3804 [RFC5987] Reschke, J., "Character Set and Language Encoding for 3805 Hypertext Transfer Protocol (HTTP) Header Field 3806 Parameters", RFC 5987, August 2010. 3808 [RFC6151] Turner, S. and L. Chen, "Updated Security 3809 Considerations for the MD5 Message-Digest and the HMAC- 3810 MD5 Algorithms", RFC 6151, March 2011. 3812 [RFC6266] Reschke, J., "Use of the Content-Disposition Header 3813 Field in the Hypertext Transfer Protocol (HTTP)", 3814 RFC 6266, June 2011. 3816 [status-308] Reschke, J., "The Hypertext Transfer Protocol (HTTP) 3817 Status Code 308 (Permanent Redirect)", 3818 draft-reschke-http-status-308-07 (work in progress), 3819 March 2012. 3821 Appendix A. Differences between HTTP and MIME 3823 HTTP/1.1 uses many of the constructs defined for Internet Mail 3824 ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME 3825 [RFC2045]) to allow a message body to be transmitted in an open 3826 variety of representations and with extensible mechanisms. However, 3827 RFC 2045 discusses mail, and HTTP has a few features that are 3828 different from those described in MIME. These differences were 3829 carefully chosen to optimize performance over binary connections, to 3830 allow greater freedom in the use of new media types, to make date 3831 comparisons easier, and to acknowledge the practice of some early 3832 HTTP servers and clients. 3834 This appendix describes specific areas where HTTP differs from MIME. 3835 Proxies and gateways to strict MIME environments SHOULD be aware of 3836 these differences and provide the appropriate conversions where 3837 necessary. Proxies and gateways from MIME environments to HTTP also 3838 need to be aware of the differences because some conversions might be 3839 required. 3841 A.1. MIME-Version 3843 HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages 3844 MAY include a single MIME-Version header field to indicate what 3845 version of the MIME protocol was used to construct the message. Use 3846 of the MIME-Version header field indicates that the message is in 3847 full conformance with the MIME protocol (as defined in [RFC2045]). 3848 Proxies/gateways are responsible for ensuring full conformance (where 3849 possible) when exporting HTTP messages to strict MIME environments. 3851 MIME-Version = 1*DIGIT "." 1*DIGIT 3853 MIME version "1.0" is the default for use in HTTP/1.1. However, 3854 HTTP/1.1 message parsing and semantics are defined by this document 3855 and not the MIME specification. 3857 A.2. Conversion to Canonical Form 3859 MIME requires that an Internet mail body-part be converted to 3860 canonical form prior to being transferred, as described in Section 4 3861 of [RFC2049]. Section 3.1.1.3 of this document describes the forms 3862 allowed for subtypes of the "text" media type when transmitted over 3863 HTTP. [RFC2046] requires that content with a type of "text" 3864 represent line breaks as CRLF and forbids the use of CR or LF outside 3865 of line break sequences. HTTP allows CRLF, bare CR, and bare LF to 3866 indicate a line break within text content when a message is 3867 transmitted over HTTP. 3869 Where it is possible, a proxy or gateway from HTTP to a strict MIME 3870 environment SHOULD translate all line breaks within the text media 3871 types described in Section 3.1.1.3 of this document to the RFC 2049 3872 canonical form of CRLF. Note, however, that this might be 3873 complicated by the presence of a Content-Encoding and by the fact 3874 that HTTP allows the use of some character encodings which do not use 3875 octets 13 and 10 to represent CR and LF, respectively, as is the case 3876 for some multi-byte character encodings. 3878 Conversion will break any cryptographic checksums applied to the 3879 original content unless the original content is already in canonical 3880 form. Therefore, the canonical form is recommended for any content 3881 that uses such checksums in HTTP. 3883 A.3. Conversion of Date Formats 3885 HTTP/1.1 uses a restricted set of date formats (Section 8.1.1.1) to 3886 simplify the process of date comparison. Proxies and gateways from 3887 other protocols SHOULD ensure that any Date header field present in a 3888 message conforms to one of the HTTP/1.1 formats and rewrite the date 3889 if necessary. 3891 A.4. Introduction of Content-Encoding 3893 MIME does not include any concept equivalent to HTTP/1.1's Content- 3894 Encoding header field. Since this acts as a modifier on the media 3895 type, proxies and gateways from HTTP to MIME-compliant protocols MUST 3896 either change the value of the Content-Type header field or decode 3897 the representation before forwarding the message. (Some experimental 3898 applications of Content-Type for Internet mail have used a media-type 3899 parameter of ";conversions=" to perform a function 3900 equivalent to Content-Encoding. However, this parameter is not part 3901 of the MIME standards). 3903 A.5. No Content-Transfer-Encoding 3905 HTTP does not use the Content-Transfer-Encoding field of MIME. 3906 Proxies and gateways from MIME-compliant protocols to HTTP MUST 3907 remove any Content-Transfer-Encoding prior to delivering the response 3908 message to an HTTP client. 3910 Proxies and gateways from HTTP to MIME-compliant protocols are 3911 responsible for ensuring that the message is in the correct format 3912 and encoding for safe transport on that protocol, where "safe 3913 transport" is defined by the limitations of the protocol being used. 3914 Such a proxy or gateway SHOULD label the data with an appropriate 3915 Content-Transfer-Encoding if doing so will improve the likelihood of 3916 safe transport over the destination protocol. 3918 A.6. MHTML and Line Length Limitations 3920 HTTP implementations which share code with MHTML [RFC2557] 3921 implementations need to be aware of MIME line length limitations. 3922 Since HTTP does not have this limitation, HTTP does not fold long 3923 lines. MHTML messages being transported by HTTP follow all 3924 conventions of MHTML, including line length limitations and folding, 3925 canonicalization, etc., since HTTP transports all message-bodies as 3926 payload (see Section 3.1.1.4) and does not interpret the content or 3927 any MIME header lines that might be contained therein. 3929 Appendix B. Additional Features 3931 [RFC1945] and [RFC2068] document protocol elements used by some 3932 existing HTTP implementations, but not consistently and correctly 3933 across most HTTP/1.1 applications. Implementers are advised to be 3934 aware of these features, but cannot rely upon their presence in, or 3935 interoperability with, other HTTP/1.1 applications. Some of these 3936 describe proposed experimental features, and some describe features 3937 that experimental deployment found lacking that are now addressed in 3938 the base HTTP/1.1 specification. 3940 A number of other header fields, such as Content-Disposition and 3941 Title, from SMTP and MIME are also often implemented (see [RFC6266] 3942 and [RFC2076]). 3944 Appendix C. Changes from RFC 2616 3946 Remove base URI setting semantics for "Content-Location" due to poor 3947 implementation support, which was caused by too many broken servers 3948 emitting bogus Content-Location header fields, and also the 3949 potentially undesirable effect of potentially breaking relative links 3950 in content-negotiated resources. (Section 3.1.4.2) 3952 Clarify definition of POST. (Section 5.3.3) 3954 Remove requirement to handle all Content-* header fields; ban use of 3955 Content-Range with PUT. (Section 5.3.4) 3957 Take over definition of CONNECT method from [RFC2817]. 3958 (Section 5.3.6) 3960 Restrict "Max-Forwards" header field to OPTIONS and TRACE 3961 (previously, extension methods could have used it as well). 3962 (Section 6.1.1) 3964 The ABNF for the "Expect" header field has been both fixed (allowing 3965 parameters for value-less expectations as well) and simplified 3966 (allowing trailing semicolons after "100-continue" when they were 3967 invalid before). (Section 6.1.2) 3969 Remove ISO-8859-1 special-casing in Accept-Charset. (Section 6.3.3) 3971 Allow "Referer" field value of "about:blank" as alternative to not 3972 specifying it. (Section 6.5.2) 3974 Broadened the definition of 203 (Non-Authoritative Information) to 3975 include cases of payload transformations as well. (Section 7.3.4) 3977 Status codes 301, 302, and 307: removed the normative requirements on 3978 both response payloads and user interaction. (Section 7.4) 3980 Failed to consider that there are many other request methods that are 3981 safe to automatically redirect, and further that the user agent is 3982 able to make that determination based on the request method 3983 semantics. Furthermore, allow user agents to rewrite the method from 3984 POST to GET for status codes 301 and 302. (Sections 7.4.2, 7.4.3 and 3985 7.4.7) 3987 Deprecate 305 (Use Proxy) status code, because user agents did not 3988 implement it. It used to indicate that the target resource needs to 3989 be accessed through the proxy given by the Location field. The 3990 Location field gave the URI of the proxy. The recipient was expected 3991 to repeat this single request via the proxy. (Section 7.4.5) 3993 Define status 426 (Upgrade Required) (this was incorporated from 3994 [RFC2817]). (Section 7.5.15) 3996 Correct syntax of "Location" header field to allow URI references 3997 (including relative references and fragments), as referred symbol 3998 "absoluteURI" wasn't what was expected, and add some clarifications 3999 as to when use of fragments would not be appropriate. 4000 (Section 8.1.2) 4002 Reclassify "Allow" as response header field, removing the option to 4003 specify it in a PUT request. Relax the server requirement on the 4004 contents of the Allow header field and remove requirement on clients 4005 to always trust the header field value. (Section 8.4.1) 4007 In the description of the "Server" header field, the "Via" field was 4008 described as a SHOULD. The requirement was and is stated correctly 4009 in the description of the Via header field in Section 5.7 of [Part1]. 4010 (Section 8.4.2) 4012 Clarify contexts that charset is used in. (Section 3.1.1.2) 4014 Remove the default character encoding of "ISO-8859-1" for text media 4015 types; the default now is whatever the media type definition says. 4016 (Section 3.1.1.3) 4018 Registration of Content Codings now requires IETF Review 4019 (Section 9.4) 4021 Remove definition of "Content-MD5 header" field because it was 4022 inconsistently implemented with respect to partial responses, and 4023 also because of known deficiencies in the hash algorithm itself (see 4024 [RFC6151] for details). 4026 Introduce Method Registry. (Section 9.1) 4028 Take over the Status Code Registry, previously defined in Section 7.1 4029 of [RFC2817]. (Section 9.2) 4031 Remove reference to non-existant identity transfer-coding value 4032 tokens. (Appendix A.5) 4033 Remove discussion of Content-Disposition header field, it is now 4034 defined by [RFC6266]. (Appendix B) 4036 Appendix D. Imported ABNF 4038 The following core rules are included by reference, as defined in 4039 Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), 4040 CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double 4041 quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF 4042 (line feed), OCTET (any 8-bit sequence of data), SP (space), and 4043 VCHAR (any visible US-ASCII character). 4045 The rules below are defined in [Part1]: 4047 BWS = 4048 OWS = 4049 RWS = 4050 URI-reference = 4051 absolute-URI = 4052 comment = 4053 field-name = 4054 partial-URI = 4055 quoted-string = 4056 token = 4057 word = 4059 Appendix E. Collected ABNF 4061 Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ 4062 OWS ( media-range [ accept-params ] ) ] ) ] 4063 Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS 4064 "," [ OWS ( ( charset / "*" ) [ weight ] ) ] ) 4065 Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS 4066 ( codings [ weight ] ) ] ) ] 4067 Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS 4068 "," [ OWS ( language-range [ weight ] ) ] ) 4069 Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ] 4071 BWS = 4073 Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS 4074 content-coding ] ) 4075 Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS 4076 language-tag ] ) 4077 Content-Location = absolute-URI / partial-URI 4078 Content-Type = media-type 4080 Date = HTTP-date 4081 Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) 4083 From = mailbox 4085 GMT = %x47.4D.54 ; GMT 4087 HTTP-date = rfc1123-date / obs-date 4089 Location = URI-reference 4091 MIME-Version = 1*DIGIT "." 1*DIGIT 4092 Max-Forwards = 1*DIGIT 4094 OWS = 4096 RWS = 4097 Referer = absolute-URI / partial-URI 4098 Retry-After = HTTP-date / delta-seconds 4100 Server = product *( RWS ( product / comment ) ) 4102 URI-reference = 4103 User-Agent = product *( RWS ( product / comment ) ) 4105 Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] 4106 ) ) 4108 absolute-URI = 4109 accept-ext = OWS ";" OWS token [ "=" word ] 4110 accept-params = weight *accept-ext 4111 asctime-date = day-name SP date3 SP time-of-day SP year 4112 attribute = token 4114 charset = token 4115 codings = content-coding / "identity" / "*" 4116 comment = 4117 content-coding = token 4119 date1 = day SP month SP year 4120 date2 = day "-" month "-" 2DIGIT 4121 date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) 4122 day = 2DIGIT 4123 day-name = %x4D.6F.6E ; Mon 4124 / %x54.75.65 ; Tue 4125 / %x57.65.64 ; Wed 4126 / %x54.68.75 ; Thu 4127 / %x46.72.69 ; Fri 4128 / %x53.61.74 ; Sat 4129 / %x53.75.6E ; Sun 4130 day-name-l = %x4D.6F.6E.64.61.79 ; Monday 4131 / %x54.75.65.73.64.61.79 ; Tuesday 4132 / %x57.65.64.6E.65.73.64.61.79 ; Wednesday 4133 / %x54.68.75.72.73.64.61.79 ; Thursday 4134 / %x46.72.69.64.61.79 ; Friday 4135 / %x53.61.74.75.72.64.61.79 ; Saturday 4136 / %x53.75.6E.64.61.79 ; Sunday 4137 delta-seconds = 1*DIGIT 4139 expect-name = token 4140 expect-param = expect-name [ BWS "=" BWS expect-value ] 4141 expect-value = token / quoted-string 4142 expectation = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [ 4143 OWS expect-param ] ) 4145 field-name = 4147 hour = 2DIGIT 4149 language-range = 4150 language-tag = 4152 mailbox = 4153 media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS 4154 ";" OWS parameter ) 4155 media-type = type "/" subtype *( OWS ";" OWS parameter ) 4156 method = token 4157 minute = 2DIGIT 4158 month = %x4A.61.6E ; Jan 4159 / %x46.65.62 ; Feb 4160 / %x4D.61.72 ; Mar 4161 / %x41.70.72 ; Apr 4162 / %x4D.61.79 ; May 4163 / %x4A.75.6E ; Jun 4164 / %x4A.75.6C ; Jul 4165 / %x41.75.67 ; Aug 4166 / %x53.65.70 ; Sep 4167 / %x4F.63.74 ; Oct 4168 / %x4E.6F.76 ; Nov 4169 / %x44.65.63 ; Dec 4171 obs-date = rfc850-date / asctime-date 4173 parameter = attribute "=" value 4174 partial-URI = 4175 product = token [ "/" product-version ] 4176 product-version = token 4178 quoted-string = 4179 qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 4181 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT 4182 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 4184 second = 2DIGIT 4185 subtype = token 4187 time-of-day = hour ":" minute ":" second 4188 token = 4189 type = token 4191 value = word 4193 weight = OWS ";" OWS "q=" qvalue 4194 word = 4196 year = 4DIGIT 4198 Appendix F. Change Log (to be removed by RFC Editor before publication) 4200 F.1. Since RFC 2616 4202 Extracted relevant partitions from [RFC2616]. 4204 F.2. Since draft-ietf-httpbis-p2-semantics-00 4206 Closed issues: 4208 o : "Via is a MUST" 4209 () 4211 o : "Fragments 4212 allowed in Location" 4213 () 4215 o : "Safe Methods 4216 vs Redirection" () 4218 o : "Revise 4219 description of the POST method" 4220 () 4222 o : "Normative and 4223 Informative references" 4225 o : "RFC2606 4226 Compliance" 4228 o : "Informative 4229 references" 4231 o : "Redundant 4232 cross-references" 4234 Other changes: 4236 o Move definitions of 304 and 412 condition codes to [Part4] 4238 F.3. Since draft-ietf-httpbis-p3-payload-00 4240 Closed issues: 4242 o : "Media Type 4243 Registrations" () 4245 o : "Clarification 4246 regarding quoting of charset values" 4247 () 4249 o : "Remove 4250 'identity' token references" 4251 () 4253 o : "Accept- 4254 Encoding BNF" 4256 o : "Normative and 4257 Informative references" 4259 o : "RFC1700 4260 references" 4262 o : "Updating to 4263 RFC4288" 4265 o : "Informative 4266 references" 4268 o : "ISO-8859-1 4269 Reference" 4271 o : "Encoding 4272 References Normative" 4274 o : "Normative up- 4275 to-date references" 4277 F.4. Since draft-ietf-httpbis-p2-semantics-01 4279 Closed issues: 4281 o : "PUT side 4282 effects" 4284 o : "Duplicate Host 4285 header requirements" 4287 Ongoing work on ABNF conversion 4288 (): 4290 o Move "Product Tokens" section (back) into Part 1, as "token" is 4291 used in the definition of the Upgrade header field. 4293 o Add explicit references to BNF syntax and rules imported from 4294 other parts of the specification. 4296 o Copy definition of delta-seconds from Part6 instead of referencing 4297 it. 4299 F.5. Since draft-ietf-httpbis-p3-payload-01 4301 Ongoing work on ABNF conversion 4302 (): 4304 o Add explicit references to BNF syntax and rules imported from 4305 other parts of the specification. 4307 F.6. Since draft-ietf-httpbis-p2-semantics-02 4309 Closed issues: 4311 o : "Requiring 4312 Allow in 405 responses" 4314 o : "Status Code 4315 Registry" 4317 o : "Redirection 4318 vs. Location" 4320 o : "Cacheability 4321 of 303 response" 4323 o : "305 Use Proxy" 4325 o : 4326 "Classification for Allow header field" 4328 o : "PUT - 'store 4329 under' vs 'store at'" 4331 Ongoing work on IANA Message Header Field Registration 4332 (): 4334 o Reference RFC 3984, and update header field registrations for 4335 header fields defined in this document. 4337 Ongoing work on ABNF conversion 4338 (): 4340 o Replace string literals when the string really is case-sensitive 4341 (method). 4343 F.7. Since draft-ietf-httpbis-p3-payload-02 4345 Closed issues: 4347 o : "Quoting 4348 Charsets" 4350 o : 4351 "Classification for Allow header field" 4353 o : "missing 4354 default for qvalue in description of Accept-Encoding" 4356 Ongoing work on IANA Message Header Field Registration 4357 (): 4359 o Reference RFC 3984, and update header field registrations for 4360 header fields defined in this document. 4362 F.8. Since draft-ietf-httpbis-p2-semantics-03 4364 Closed issues: 4366 o : "OPTIONS 4367 payload bodies" 4369 o : "Description 4370 of CONNECT should refer to RFC2817" 4372 o : "Location 4373 Content-Location reference request/response mixup" 4375 Ongoing work on Method Registry 4376 (): 4378 o Added initial proposal for registration process, plus initial 4379 content (non-HTTP/1.1 methods to be added by a separate 4380 specification). 4382 F.9. Since draft-ietf-httpbis-p3-payload-03 4384 Closed issues: 4386 o : "Quoting 4387 Charsets" 4389 o : "language tag 4390 matching (Accept-Language) vs RFC4647" 4392 o : "RFC 1806 has 4393 been replaced by RFC2183" 4395 Other changes: 4397 o : "Encoding 4398 References Normative" -- rephrase the annotation and reference 4399 BCP97. 4401 F.10. Since draft-ietf-httpbis-p2-semantics-04 4403 Closed issues: 4405 o : "Content-*" 4407 o : "RFC 2822 is 4408 updated by RFC 5322" 4410 Ongoing work on ABNF conversion 4411 (): 4413 o Use "/" instead of "|" for alternatives. 4415 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 4416 whitespace ("OWS") and required whitespace ("RWS"). 4418 o Rewrite ABNFs to spell out whitespace rules, factor out header 4419 field value format definitions. 4421 F.11. Since draft-ietf-httpbis-p3-payload-04 4423 Closed issues: 4425 o : "RFC 2822 is 4426 updated by RFC 5322" 4428 Ongoing work on ABNF conversion 4429 (): 4431 o Use "/" instead of "|" for alternatives. 4433 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 4434 whitespace ("OWS") and required whitespace ("RWS"). 4436 o Rewrite ABNFs to spell out whitespace rules, factor out header 4437 field value format definitions. 4439 F.12. Since draft-ietf-httpbis-p2-semantics-05 4441 Closed issues: 4443 o : "reason-phrase 4444 BNF" 4446 Final work on ABNF conversion 4447 (): 4449 o Add appendix containing collected and expanded ABNF, reorganize 4450 ABNF introduction. 4452 F.13. Since draft-ietf-httpbis-p3-payload-05 4454 Closed issues: 4456 o : "Join 4457 "Differences Between HTTP Entities and RFC 2045 Entities"?" 4459 Final work on ABNF conversion 4460 (): 4462 o Add appendix containing collected and expanded ABNF, reorganize 4463 ABNF introduction. 4465 Other changes: 4467 o Move definition of quality values into Part 1. 4469 F.14. Since draft-ietf-httpbis-p2-semantics-06 4471 Closed issues: 4473 o : "Clarify when 4474 Referer is sent" 4476 o : "status codes 4477 vs methods" 4479 o : "Do not 4480 require "updates" relation for specs that register status codes or 4481 method names" 4483 F.15. Since draft-ietf-httpbis-p3-payload-06 4485 Closed issues: 4487 o : "Content- 4488 Location isn't special" 4490 o : "Content 4491 Sniffing" 4493 F.16. Since draft-ietf-httpbis-p2-semantics-07 4495 Closed issues: 4497 o : "Idempotency" 4499 o : "TRACE security 4500 considerations" 4502 o : "Clarify rules 4503 for determining what entities a response carries" 4505 o : "update note 4506 citing RFC 1945 and 2068" 4508 o : "update note 4509 about redirect limit" 4511 o : "Location 4512 header field ABNF should use 'URI'" 4514 o : "fragments in 4515 Location vs status 303" 4517 o : "move IANA 4518 registrations for optional status codes" 4520 Partly resolved issues: 4522 o : "Are OPTIONS 4523 and TRACE safe?" 4525 F.17. Since draft-ietf-httpbis-p3-payload-07 4527 Closed issues: 4529 o : "Updated 4530 reference for language tags" 4532 o : "Clarify rules 4533 for determining what entities a response carries" 4535 o : "Content- 4536 Location base-setting problems" 4538 o : "Content 4539 Sniffing" 4541 o : "pick IANA 4542 policy (RFC5226) for Transfer Coding / Content Coding" 4544 o : "move 4545 definitions of gzip/deflate/compress to part 1" 4547 Partly resolved issues: 4549 o : "update IANA 4550 requirements wrt Transfer-Coding values" (add the IANA 4551 Considerations subsection) 4553 o : "update IANA 4554 requirements wrt Content-Coding values" (add the IANA 4555 Considerations subsection) 4557 F.18. Since draft-ietf-httpbis-p2-semantics-08 4559 Closed issues: 4561 o : "Safe Methods 4562 vs Redirection" (we missed the introduction to the 3xx status 4563 codes when fixing this previously) 4565 F.19. Since draft-ietf-httpbis-p3-payload-08 4567 Closed issues: 4569 o : "Content 4570 Negotiation for media types" 4572 o : "Accept- 4573 Language: which RFC4647 filtering?" 4575 F.20. Since draft-ietf-httpbis-p2-semantics-09 4577 Closed issues: 4579 o : "Fragment 4580 combination / precedence during redirects" 4582 Partly resolved issues: 4584 o : "Location 4585 header field payload handling" 4587 o : "Term for the 4588 requested resource's URI" 4590 F.21. Since draft-ietf-httpbis-p3-payload-09 4592 Closed issues: 4594 o : "MIME-Version 4595 not listed in P1, general header fields" 4597 o : "IANA registry 4598 for content/transfer encodings" 4600 o : "Content 4601 Sniffing" 4603 o : "use of term 4604 "word" when talking about header field structure" 4606 Partly resolved issues: 4608 o : "Term for the 4609 requested resource's URI" 4611 F.22. Since draft-ietf-httpbis-p2-semantics-10 4613 Closed issues: 4615 o : "Clarify 4616 'Requested Variant'" 4618 o : "Clarify 4619 entity / representation / variant terminology" 4621 o : "Methods and 4622 Caching" 4624 o : "OPTIONS vs 4625 Max-Forwards" 4627 o : "Status codes 4628 and caching" 4630 o : "consider 4631 removing the 'changes from 2068' sections" 4633 F.23. Since draft-ietf-httpbis-p3-payload-10 4635 Closed issues: 4637 o : "Clarify 4638 'Requested Variant'" 4640 o : "Content- 4641 Location isn't special" 4643 o : "Delimiting 4644 messages with multipart/byteranges" 4646 o : "Clarify 4647 entity / representation / variant terminology" 4649 o : "confusing 4650 req. language for Content-Location" 4652 o : "Content- 4653 Location on 304 responses" 4655 o : "'requested 4656 resource' in content-encoding definition" 4658 o : "consider 4659 removing the 'changes from 2068' sections" 4661 Partly resolved issues: 4663 o : "Content-MD5 4664 and partial responses" 4666 F.24. Since draft-ietf-httpbis-p2-semantics-11 4668 Closed issues: 4670 o : 4671 "Considerations for new status codes" 4673 o : 4674 "Considerations for new methods" 4676 o : "User-Agent 4677 guidelines" (relating to the 'User-Agent' header field) 4679 F.25. Since draft-ietf-httpbis-p3-payload-11 4681 Closed issues: 4683 o : "Factor out 4684 Content-Disposition" 4686 F.26. Since draft-ietf-httpbis-p2-semantics-12 4688 Closed issues: 4690 o : "Fragment 4691 combination / precedence during redirects" (added warning about 4692 having a fragid on the redirect might cause inconvenience in some 4693 cases) 4695 o : "Content-* vs. 4696 PUT" 4698 o : "205 Bodies" 4700 o : "Understanding 4701 Content-* on non-PUT requests" 4703 o : "Content-*" 4705 o : "Header field 4706 type defaulting" 4708 o : "PUT - 'store 4709 under' vs 'store at'" 4711 o : "duplicate 4712 ABNF for reason-phrase" 4714 o : "Note special 4715 status of Content-* prefix in header field registration 4716 procedures" 4718 o : "Max-Forwards 4719 vs extension methods" 4721 o : "What is the 4722 value space of HTTP status codes?" (actually fixed in 4723 draft-ietf-httpbis-p2-semantics-11) 4725 o : "Header Field 4726 Classification" 4728 o : "PUT side 4729 effect: invalidation or just stale?" 4731 o : "proxies not 4732 supporting certain methods" 4734 o : "Migrate 4735 CONNECT from RFC2817 to p2" 4737 o : "Migrate 4738 Upgrade details from RFC2817" 4740 o : "clarify PUT 4741 semantics'" 4743 o : "duplicate 4744 ABNF for 'Method'" 4746 o : "untangle 4747 ABNFs for header fields" 4749 F.27. Since draft-ietf-httpbis-p3-payload-12 4751 Closed issues: 4753 o : "Header Field 4754 Classification" 4756 o : "untangle 4757 ABNFs for header fields" 4759 o : "potentially 4760 misleading MAY in media-type def" 4762 F.28. Since draft-ietf-httpbis-p2-semantics-13 4764 Closed issues: 4766 o : "untangle 4767 ABNFs for header fields" 4769 o : "message body 4770 in CONNECT request" 4772 F.29. Since draft-ietf-httpbis-p3-payload-13 4774 Closed issues: 4776 o : "Default 4777 charsets for text media types" 4779 o : "Content-MD5 4780 and partial responses" 4782 o : "untangle 4783 ABNFs for header fields" 4785 o : "confusing 4786 undefined parameter in media range example" 4788 F.30. Since draft-ietf-httpbis-p2-semantics-14 4790 Closed issues: 4792 o : "Clarify 4793 status code for rate limiting" 4795 o : "clarify 403 4796 forbidden" 4798 o : "Clarify 203 4799 Non-Authoritative Information" 4801 o : "update 4802 default reason phrase for 413" 4804 F.31. Since draft-ietf-httpbis-p3-payload-14 4806 None. 4808 F.32. Since draft-ietf-httpbis-p2-semantics-15 4810 Closed issues: 4812 o : "Strength of 4813 requirements on Accept re: 406" 4815 o : "400 response 4816 isn't generic" 4818 F.33. Since draft-ietf-httpbis-p3-payload-15 4820 Closed issues: 4822 o : "Strength of 4823 requirements on Accept re: 406" 4825 F.34. Since draft-ietf-httpbis-p2-semantics-16 4827 Closed issues: 4829 o : "Redirects and 4830 non-GET methods" 4832 o : "Document 4833 HTTP's error-handling philosophy" 4835 o : 4836 "Considerations for new header fields" 4838 o : "clarify 303 4839 redirect on HEAD" 4841 F.35. Since draft-ietf-httpbis-p3-payload-16 4843 Closed issues: 4845 o : "Document 4846 HTTP's error-handling philosophy" 4848 F.36. Since draft-ietf-httpbis-p2-semantics-17 4850 Closed issues: 4852 o : "Location 4853 header field payload handling" 4855 o : "Clarify 4856 status code for rate limiting" (change backed out because a new 4857 status code is being defined for this purpose) 4859 o : "should there 4860 be a permanent variant of 307" 4862 o : "When are 4863 Location's semantics triggered?" 4865 o : "'expect' 4866 grammar missing OWS" 4868 o : "header field 4869 considerations: quoted-string vs use of double quotes" 4871 F.37. Since draft-ietf-httpbis-p3-payload-17 4873 Closed issues: 4875 o : "intended 4876 maturity level vs normative references" 4878 F.38. Since draft-ietf-httpbis-p2-semantics-18 4880 Closed issues: 4882 o : "Combining 4883 HEAD responses" 4885 o : "Requirements 4886 for user intervention during redirects" 4888 o : "message-body 4889 in CONNECT response" 4891 o : "Applying 4892 original fragment to 'plain' redirected URI" 4894 o : "Misplaced 4895 text on connection handling in p2" 4897 o : "clarify that 4898 201 doesn't require Location header fields" 4900 o : "relax 4901 requirements on hypertext in 3/4/5xx error responses" 4903 o : "example for 4904 426 response should have a payload" 4906 o : "drop 4907 indirection entries for status codes" 4909 F.39. Since draft-ietf-httpbis-p3-payload-18 4911 Closed issues: 4913 o : "is ETag a 4914 representation header field?" 4916 o : "Content- 4917 Location doesn't constrain the cardinality of representations" 4919 o : "make IANA 4920 policy definitions consistent" 4922 F.40. Since draft-ietf-httpbis-p2-semantics-19 and 4923 draft-ietf-httpbis-p3-payload-19 4925 Closed issues: 4927 o : "should there 4928 be a permanent variant of 307" 4930 o : "clarify that 4931 201 can imply *multiple* resources were created" 4933 o : "merge P2 and 4934 P3" 4936 o : "ABNF 4937 requirements for recipients" 4939 o : "Capturing 4940 more information in the method registry" 4942 o : "note 4943 introduction of new IANA registries as normative changes" 4945 F.41. Since draft-ietf-httpbis-p2-semantics-20 4947 Closed issues: 4949 o : "is 'q=' case- 4950 sensitive?" 4952 Other changes: 4954 o Conformance criteria and considerations regarding error handling 4955 are now defined in Part 1. 4957 o Properly explain what HTTP semantics are and why. Rewrite 4958 introductory description of methods. Rewrite definition of "safe" 4959 to be more operable and weaken the original same-origin 4960 restrictions to be more consistent with modern UAs. Rewrite 4961 definition of "idempotent", add definition of "cacheable". 4963 o Conneg terminology change: "server-driven" => "proactive" (UA 4964 sends Accept* fields), "agent-driven" => "reactive" (UA waits for 4965 300/Alternatives) 4967 o Move description of "100-continue" from Part 1 over here. 4969 o Move definition of "Vary" header field from Part 6 over here. 4971 o Rewrite definition of "representation". 4973 Index 4975 1 4976 1xx Informational (status code class) 49 4978 2 4979 2xx Successful (status code class) 50 4981 3 4982 3xx Redirection (status code class) 52 4984 4 4985 4xx Client Error (status code class) 56 4987 5 4988 5xx Server Error (status code class) 60 4990 1 4991 100 Continue (status code) 49 4992 100-continue (expect value) 35 4993 101 Switching Protocols (status code) 49 4995 2 4996 200 OK (status code) 50 4997 201 Created (status code) 50 4998 202 Accepted (status code) 51 4999 203 Non-Authoritative Information (status code) 51 5000 204 No Content (status code) 51 5001 205 Reset Content (status code) 52 5003 3 5004 300 Multiple Choices (status code) 54 5005 301 Moved Permanently (status code) 54 5006 302 Found (status code) 55 5007 303 See Other (status code) 55 5008 305 Use Proxy (status code) 56 5009 306 (Unused) (status code) 56 5010 307 Temporary Redirect (status code) 56 5012 4 5013 400 Bad Request (status code) 56 5014 402 Payment Required (status code) 56 5015 403 Forbidden (status code) 57 5016 404 Not Found (status code) 57 5017 405 Method Not Allowed (status code) 57 5018 406 Not Acceptable (status code) 57 5019 408 Request Timeout (status code) 58 5020 409 Conflict (status code) 58 5021 410 Gone (status code) 58 5022 411 Length Required (status code) 59 5023 413 Request Representation Too Large (status code) 59 5024 414 URI Too Long (status code) 59 5025 415 Unsupported Media Type (status code) 59 5026 417 Expectation Failed (status code) 60 5027 426 Upgrade Required (status code) 60 5029 5 5030 500 Internal Server Error (status code) 60 5031 501 Not Implemented (status code) 60 5032 502 Bad Gateway (status code) 61 5033 503 Service Unavailable (status code) 61 5034 504 Gateway Timeout (status code) 61 5035 505 HTTP Version Not Supported (status code) 61 5037 A 5038 Accept header field 38 5039 Accept-Charset header field 41 5040 Accept-Encoding header field 41 5041 Accept-Language header field 42 5042 Allow header field 69 5044 C 5045 cacheable 25 5046 compress (content coding) 12 5047 CONNECT method 30 5048 content coding 12 5049 content negotiation 7 5050 Content-Encoding header field 12 5051 Content-Language header field 14 5052 Content-Location header field 16 5053 Content-Transfer-Encoding header field 85 5054 Content-Type header field 11 5056 D 5057 Date header field 64 5058 deflate (content coding) 12 5059 DELETE method 30 5061 E 5062 Expect header field 34 5063 Expect Values 5064 100-continue 35 5066 F 5067 From header field 44 5069 G 5070 GET method 25 5071 Grammar 5072 Accept 39 5073 Accept-Charset 41 5074 Accept-Encoding 41 5075 accept-ext 39 5076 Accept-Language 43 5077 accept-params 39 5078 Allow 69 5079 asctime-date 64 5080 attribute 9 5081 charset 10 5082 codings 41 5083 content-coding 12 5084 Content-Encoding 13 5085 Content-Language 14 5086 Content-Location 16 5087 Content-Type 11 5088 Date 64 5089 date1 63 5090 day 63 5091 day-name 63 5092 day-name-l 63 5093 delta-seconds 66 5094 Expect 34 5095 expect-name 34 5096 expect-param 34 5097 expect-value 34 5098 expectation 34 5099 From 44 5100 GMT 63 5101 hour 63 5102 HTTP-date 62 5103 language-range 43 5104 language-tag 14 5105 Location 65 5106 Max-Forwards 34 5107 media-range 39 5108 media-type 9 5109 method 22 5110 MIME-Version 84 5111 minute 63 5112 month 63 5113 obs-date 63 5114 parameter 9 5115 product 22 5116 product-version 22 5117 qvalue 38 5118 Referer 45 5119 Retry-After 66 5120 rfc850-date 64 5121 rfc1123-date 63 5122 second 63 5123 Server 69 5124 subtype 9 5125 time-of-day 63 5126 type 9 5127 User-Agent 46 5128 value 9 5129 Vary 67 5130 weight 38 5131 year 63 5132 gzip (content coding) 12 5134 H 5135 HEAD method 26 5137 I 5138 idempotent 25 5140 L 5141 Location header field 65 5143 M 5144 Max-Forwards header field 34 5145 MIME-Version header field 84 5147 O 5148 OPTIONS method 32 5150 P 5151 payload 18 5152 POST method 27 5153 PUT method 28 5155 R 5156 Referer header field 45 5157 representation 8 5158 Retry-After header field 66 5160 S 5161 safe 24 5162 selected representation 67 5163 Server header field 69 5164 Status Codes Classes 5165 1xx Informational 49 5166 2xx Successful 50 5167 3xx Redirection 52 5168 4xx Client Error 56 5169 5xx Server Error 60 5171 T 5172 TRACE method 33 5174 U 5175 User-Agent header field 45 5177 V 5178 Vary header field 67 5180 X 5181 x-compress (content coding) 12 5182 x-gzip (content coding) 12 5184 Authors' Addresses 5186 Roy T. Fielding (editor) 5187 Adobe Systems Incorporated 5188 345 Park Ave 5189 San Jose, CA 95110 5190 USA 5192 EMail: fielding@gbiv.com 5193 URI: http://roy.gbiv.com/ 5195 Julian F. Reschke (editor) 5196 greenbytes GmbH 5197 Hafenweg 16 5198 Muenster, NW 48155 5199 Germany 5201 EMail: julian.reschke@greenbytes.de 5202 URI: http://greenbytes.de/tech/webdav/