idnits 2.17.1 draft-ietf-httpbis-p2-semantics-19.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 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 (March 12, 2012) is 4428 days in the past. Is this intentional? 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-19 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-19 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-19 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-19 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-19 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-19 -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- 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 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5987 (Obsoleted by RFC 8187) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 7 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) Y. Lafon, Ed. 5 Updates: 2817 (if approved) W3C 6 Intended status: Standards Track J. Reschke, Ed. 7 Expires: September 13, 2012 greenbytes 8 March 12, 2012 10 HTTP/1.1, part 2: Message Semantics 11 draft-ietf-httpbis-p2-semantics-19 13 Abstract 15 The Hypertext Transfer Protocol (HTTP) is an application-level 16 protocol for distributed, collaborative, hypertext information 17 systems. HTTP has been in use by the World Wide Web global 18 information initiative since 1990. This document is Part 2 of the 19 seven-part specification that defines the protocol referred to as 20 "HTTP/1.1" and, taken together, obsoletes RFC 2616. 22 Part 2 defines the semantics of HTTP messages as expressed by request 23 methods, request header fields, response status codes, and response 24 header fields. 26 Editorial Note (To be removed by RFC Editor) 28 Discussion of this draft should take place on the HTTPBIS working 29 group mailing list (ietf-http-wg@w3.org), which is archived at 30 . 32 The current issues list is at 33 and related 34 documents (including fancy diffs) can be found at 35 . 37 The changes in this draft are summarized in Appendix C.20. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on September 13, 2012. 56 Copyright Notice 58 Copyright (c) 2012 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 This document may contain material from IETF Documents or IETF 72 Contributions published or made publicly available before November 73 10, 2008. The person(s) controlling the copyright in some of this 74 material may not have granted the IETF Trust the right to allow 75 modifications of such material outside the IETF Standards Process. 76 Without obtaining an adequate license from the person(s) controlling 77 the copyright in such materials, this document may not be modified 78 outside the IETF Standards Process, and derivative works of it may 79 not be created outside the IETF Standards Process, except to format 80 it for publication as an RFC or to translate it into languages other 81 than English. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 86 1.1. Conformance and Error Handling . . . . . . . . . . . . . 6 87 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 88 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 89 1.2.2. ABNF Rules defined in other Parts of the 90 Specification . . . . . . . . . . . . . . . . . . . . 7 91 2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 92 2.1. Overview of Methods . . . . . . . . . . . . . . . . . . . 8 93 2.2. Method Registry . . . . . . . . . . . . . . . . . . . . . 8 94 2.2.1. Considerations for New Methods . . . . . . . . . . . . 9 95 3. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 9 96 3.1. Considerations for Creating Header Fields . . . . . . . . 9 97 3.2. Request Header Fields . . . . . . . . . . . . . . . . . . 11 98 3.3. Response Header Fields . . . . . . . . . . . . . . . . . 12 99 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 12 100 4.1. Overview of Status Codes . . . . . . . . . . . . . . . . 13 101 4.2. Status Code Registry . . . . . . . . . . . . . . . . . . 15 102 4.2.1. Considerations for New Status Codes . . . . . . . . . 15 103 5. Representation . . . . . . . . . . . . . . . . . . . . . . . . 16 104 5.1. Identifying the Resource Associated with a 105 Representation . . . . . . . . . . . . . . . . . . . . . 16 106 6. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 17 107 6.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 17 108 6.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 17 109 6.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 17 110 6.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 18 111 6.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 112 6.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 19 113 6.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 20 114 6.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 115 6.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 23 116 6.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 23 117 6.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 24 118 7. Status Code Definitions . . . . . . . . . . . . . . . . . . . 25 119 7.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 26 120 7.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 26 121 7.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 27 122 7.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 27 123 7.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 27 124 7.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 27 125 7.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 28 126 7.2.4. 203 Non-Authoritative Information . . . . . . . . . . 28 127 7.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 28 128 7.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 29 129 7.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 29 130 7.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 31 131 7.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 31 132 7.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 32 133 7.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 32 134 7.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 33 135 7.3.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 33 136 7.3.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 33 137 7.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 33 138 7.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 33 139 7.4.2. 402 Payment Required . . . . . . . . . . . . . . . . . 33 140 7.4.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 33 141 7.4.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 34 142 7.4.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 34 143 7.4.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 34 144 7.4.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 35 145 7.4.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 35 146 7.4.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 35 147 7.4.10. 411 Length Required . . . . . . . . . . . . . . . . . 36 148 7.4.11. 413 Request Representation Too Large . . . . . . . . . 36 149 7.4.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 36 150 7.4.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 36 151 7.4.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 36 152 7.4.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 37 153 7.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 37 154 7.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 37 155 7.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 37 156 7.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 37 157 7.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 38 158 7.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 38 159 7.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 38 160 8. Date/Time Formats . . . . . . . . . . . . . . . . . . . . . . 38 161 9. Product Tokens . . . . . . . . . . . . . . . . . . . . . . . . 41 162 10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 42 163 10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 42 164 10.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 42 165 10.3. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 43 166 10.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . 44 167 10.5. Location . . . . . . . . . . . . . . . . . . . . . . . . 45 168 10.6. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 46 169 10.7. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 46 170 10.8. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 47 171 10.9. Server . . . . . . . . . . . . . . . . . . . . . . . . . 47 172 10.10. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 48 173 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 174 11.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 49 175 11.2. Status Code Registry . . . . . . . . . . . . . . . . . . 49 176 11.3. Header Field Registration . . . . . . . . . . . . . . . . 50 177 12. Security Considerations . . . . . . . . . . . . . . . . . . . 51 178 12.1. Transfer of Sensitive Information . . . . . . . . . . . . 51 179 12.2. Encoding Sensitive Information in URIs . . . . . . . . . 52 180 12.3. Location Header Fields: Spoofing and Information 181 Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 53 182 12.4. Security Considerations for CONNECT . . . . . . . . . . . 53 183 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 184 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 185 14.1. Normative References . . . . . . . . . . . . . . . . . . 53 186 14.2. Informative References . . . . . . . . . . . . . . . . . 54 187 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 55 188 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 56 189 Appendix C. Change Log (to be removed by RFC Editor before 190 publication) . . . . . . . . . . . . . . . . . . . . 59 191 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . 59 192 C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . 59 193 C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . 60 194 C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . 60 195 C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . 61 196 C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . 61 197 C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . 62 198 C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . 62 199 C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . 62 200 C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . 63 201 C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . 63 202 C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . 63 203 C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . 64 204 C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . 64 205 C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . 66 206 C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . 66 207 C.17. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . 66 208 C.18. Since draft-ietf-httpbis-p2-semantics-16 . . . . . . . . 66 209 C.19. Since draft-ietf-httpbis-p2-semantics-17 . . . . . . . . 67 210 C.20. Since draft-ietf-httpbis-p2-semantics-18 . . . . . . . . 67 211 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 213 1. Introduction 215 This document defines HTTP/1.1 request and response semantics. Each 216 HTTP message, as defined in [Part1], is in the form of either a 217 request or a response. An HTTP server listens on a connection for 218 HTTP requests and responds to each request, in the order received on 219 that connection, with one or more HTTP response messages. This 220 document defines the commonly agreed upon semantics of the HTTP 221 uniform interface, the intentions defined by each request method, and 222 the various response messages that might be expected as a result of 223 applying that method to the target resource. 225 This document is currently disorganized in order to minimize the 226 changes between drafts and enable reviewers to see the smaller errata 227 changes. A future draft will reorganize the sections to better 228 reflect the content. In particular, the sections will be ordered 229 according to the typical processing of an HTTP request message (after 230 message parsing): resource mapping, methods, request modifying header 231 fields, response status, status modifying header fields, and resource 232 metadata. The current mess reflects how widely dispersed these 233 topics and associated requirements had become in [RFC2616]. 235 1.1. Conformance and Error Handling 237 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 238 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 239 document are to be interpreted as described in [RFC2119]. 241 This document defines conformance criteria for several roles in HTTP 242 communication, including Senders, Recipients, Clients, Servers, User- 243 Agents, Origin Servers, Intermediaries, Proxies and Gateways. See 244 Section 2 of [Part1] for definitions of these terms. 246 An implementation is considered conformant if it complies with all of 247 the requirements associated with its role(s). Note that SHOULD-level 248 requirements are relevant here, unless one of the documented 249 exceptions is applicable. 251 This document also uses ABNF to define valid protocol elements 252 (Section 1.2). In addition to the prose requirements placed upon 253 them, Senders MUST NOT generate protocol elements that are invalid. 255 Unless noted otherwise, Recipients MAY take steps to recover a usable 256 protocol element from an invalid construct. However, HTTP does not 257 define specific error handling mechanisms, except in cases where it 258 has direct impact on security. This is because different uses of the 259 protocol require different error handling strategies; for example, a 260 Web browser may wish to transparently recover from a response where 261 the Location header field doesn't parse according to the ABNF, 262 whereby in a systems control protocol using HTTP, this type of error 263 recovery could lead to dangerous consequences. 265 1.2. Syntax Notation 267 This specification uses the Augmented Backus-Naur Form (ABNF) 268 notation of [RFC5234] with the list rule extension defined in Section 269 1.2 of [Part1]. Appendix B shows the collected ABNF with the list 270 rule expanded. 272 The following core rules are included by reference, as defined in 273 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 274 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 275 HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line 276 feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any 277 visible US-ASCII character). 279 1.2.1. Core Rules 281 The core rules below are defined in [Part1]: 283 BWS = 284 OWS = 285 RWS = 286 obs-text = 287 quoted-string = 288 token = 290 1.2.2. ABNF Rules defined in other Parts of the Specification 292 The ABNF rules below are defined in other parts: 294 absolute-URI = 295 comment = 296 partial-URI = 297 URI-reference = 299 2. Method 301 The method token indicates the request method to be performed on the 302 target resource (Section 5.5 of [Part1]). The method is case- 303 sensitive. 305 method = token 307 The list of methods allowed by a resource can be specified in an 308 Allow header field (Section 10.1). The status code of the response 309 always notifies the client whether a method is currently allowed on a 310 resource, since the set of allowed methods can change dynamically. 311 An origin server SHOULD respond with the status code 405 (Method Not 312 Allowed) if the method is known by the origin server but not allowed 313 for the resource, and 501 (Not Implemented) if the method is 314 unrecognized or not implemented by the origin server. The methods 315 GET and HEAD MUST be supported by all general-purpose servers. All 316 other methods are OPTIONAL; however, if the above methods are 317 implemented, they MUST be implemented with the same semantics as 318 those specified in Section 6. 320 2.1. Overview of Methods 322 The methods listed below are defined in Section 6. 324 +-------------+---------------+ 325 | Method Name | Defined in... | 326 +-------------+---------------+ 327 | OPTIONS | Section 6.2 | 328 | GET | Section 6.3 | 329 | HEAD | Section 6.4 | 330 | POST | Section 6.5 | 331 | PUT | Section 6.6 | 332 | DELETE | Section 6.7 | 333 | TRACE | Section 6.8 | 334 | CONNECT | Section 6.9 | 335 +-------------+---------------+ 337 Note that this list is not exhaustive -- it does not include request 338 methods defined in other specifications. 340 2.2. Method Registry 342 The HTTP Method Registry defines the name space for the method token 343 in the Request line of an HTTP request. 345 Registrations MUST include the following fields: 347 o Method Name (see Section 2) 349 o Safe ("yes" or "no", see Section 6.1.1) 351 o Pointer to specification text 353 Values to be added to this name space require IETF Review (see 354 [RFC5226], Section 4.1). 356 The registry itself is maintained at 357 . 359 2.2.1. Considerations for New Methods 361 When it is necessary to express new semantics for a HTTP request that 362 aren't specific to a single application or media type, and currently 363 defined methods are inadequate, it may be appropriate to register a 364 new method. 366 HTTP methods are generic; that is, they are potentially applicable to 367 any resource, not just one particular media type, "type" of resource, 368 or application. As such, it is preferred that new HTTP methods be 369 registered in a document that isn't specific to a single application, 370 so that this is clear. 372 Due to the parsing rules defined in Section 3.3 of [Part1], 373 definitions of HTTP methods cannot prohibit the presence of a message 374 body on either the request or the response message (with responses to 375 HEAD requests being the single exception). Definitions of new 376 methods cannot change this rule, but they can specify that only zero- 377 length bodies (as opposed to absent bodies) are allowed. 379 New method definitions need to indicate whether they are safe 380 (Section 6.1.1), what semantics (if any) the request body has, and 381 whether they are idempotent (Section 6.1.2). They also need to state 382 whether they can be cached ([Part6]); in particular what conditions a 383 cache may store the response, and under what conditions such a stored 384 response may be used to satisfy a subsequent request. 386 3. Header Fields 388 Header fields are key value pairs that can be used to communicate 389 data about the message, its payload, the target resource, or about 390 the connection itself (i.e., control data). See Section 3.2 of 391 [Part1] for a general definition of their syntax. 393 3.1. Considerations for Creating Header Fields 395 New header fields are registered using the procedures described in 396 [RFC3864]. 398 The requirements for header field names are defined in Section 4.1 of 399 [RFC3864]. Authors of specifications defining new fields are advised 400 to keep the name as short as practical, and not to prefix them with 401 "X-" if they are to be registered (either immediately or in the 402 future). 404 New header field values typically have their syntax defined using 405 ABNF ([RFC5234]), using the extension defined in Section 3.2.5 of 406 [Part1] as necessary, and are usually constrained to the range of 407 ASCII characters. Header fields needing a greater range of 408 characters can use an encoding such as the one defined in [RFC5987]. 410 Because commas (",") are used as a generic delimiter between field- 411 values, they need to be treated with care if they are allowed in the 412 field-value's payload. Typically, components that might contain a 413 comma are protected with double-quotes using the quoted-string ABNF 414 production (Section 3.2.4 of [Part1]). 416 For example, a textual date and a URI (either of which might contain 417 a comma) could be safely carried in field-values like these: 419 Example-URI-Field: "http://example.com/a.html,foo", 420 "http://without-a-comma.example.com/" 421 Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" 423 Note that double quote delimiters almost always are used with the 424 quoted-string production; using a different syntax inside double 425 quotes will likely cause unnecessary confusion. 427 Many header fields use a format including (case-insensitively) named 428 parameters (for instance, Content-Type, defined in Section 6.8 of 429 [Part3]). Allowing both unquoted (token) and quoted (quoted-string) 430 syntax for the parameter value enables recipients to use existing 431 parser components. When allowing both forms, the meaning of a 432 parameter value ought to be independent of the syntax used for it 433 (for an example, see the notes on parameter handling for media types 434 in Section 2.3 of [Part3]). 436 Authors of specifications defining new header fields are advised to 437 consider documenting: 439 o Whether the field is a single value, or whether it can be a list 440 (delimited by commas; see Section 3.2 of [Part1]). 442 If it does not use the list syntax, document how to treat messages 443 where the header field occurs multiple times (a sensible default 444 would be to ignore the header field, but this might not always be 445 the right choice). 447 Note that intermediaries and software libraries might combine 448 multiple header field instances into a single one, despite the 449 header field not allowing this. A robust format enables 450 recipients to discover these situations (good example: "Content- 451 Type", as the comma can only appear inside quoted strings; bad 452 example: "Location", as a comma can occur inside a URI). 454 o Under what conditions the header field can be used; e.g., only in 455 responses or requests, in all messages, only on responses to a 456 particular request method. 458 o Whether it is appropriate to list the field-name in the Connection 459 header (i.e., if the header is to be hop-by-hop, see Section 6.1 460 of [Part1]). 462 o Under what conditions intermediaries are allowed to modify the 463 header field's value, insert or delete it. 465 o How the header might interact with caching (see [Part6]). 467 o Whether the header field is useful or allowable in trailers (see 468 Section 4.1 of [Part1]). 470 o Whether the header field should be preserved across redirects. 472 3.2. Request Header Fields 474 The request header fields allow the client to pass additional 475 information about the request, and about the client itself, to the 476 server. These fields act as request modifiers, with semantics 477 equivalent to the parameters on a programming language method 478 invocation. 480 +---------------------+------------------------+ 481 | Header Field Name | Defined in... | 482 +---------------------+------------------------+ 483 | Accept | Section 6.1 of [Part3] | 484 | Accept-Charset | Section 6.2 of [Part3] | 485 | Accept-Encoding | Section 6.3 of [Part3] | 486 | Accept-Language | Section 6.4 of [Part3] | 487 | Authorization | Section 4.1 of [Part7] | 488 | Expect | Section 10.3 | 489 | From | Section 10.4 | 490 | Host | Section 5.4 of [Part1] | 491 | If-Match | Section 3.1 of [Part4] | 492 | If-Modified-Since | Section 3.3 of [Part4] | 493 | If-None-Match | Section 3.2 of [Part4] | 494 | If-Range | Section 5.3 of [Part5] | 495 | If-Unmodified-Since | Section 3.4 of [Part4] | 496 | Max-Forwards | Section 10.6 | 497 | Proxy-Authorization | Section 4.3 of [Part7] | 498 | Range | Section 5.4 of [Part5] | 499 | Referer | Section 10.7 | 500 | TE | Section 4.3 of [Part1] | 501 | User-Agent | Section 10.10 | 502 +---------------------+------------------------+ 504 3.3. Response Header Fields 506 The response header fields allow the server to pass additional 507 information about the response which cannot be placed in the status- 508 line. These header fields give information about the server and 509 about further access to the target resource (Section 5.5 of [Part1]). 511 +--------------------+------------------------+ 512 | Header Field Name | Defined in... | 513 +--------------------+------------------------+ 514 | Accept-Ranges | Section 5.1 of [Part5] | 515 | Age | Section 3.1 of [Part6] | 516 | Allow | Section 10.1 | 517 | Date | Section 10.2 | 518 | ETag | Section 2.3 of [Part4] | 519 | Location | Section 10.5 | 520 | Proxy-Authenticate | Section 4.2 of [Part7] | 521 | Retry-After | Section 10.8 | 522 | Server | Section 10.9 | 523 | Vary | Section 3.5 of [Part6] | 524 | WWW-Authenticate | Section 4.4 of [Part7] | 525 +--------------------+------------------------+ 527 4. Status Code and Reason Phrase 529 The status-code element is a 3-digit integer result code of the 530 attempt to understand and satisfy the request. 532 The reason-phrase is intended to give a short textual description of 533 the status-code and is intended for a human user. The client does 534 not need to examine or display the reason-phrase. 536 status-code = 3DIGIT 537 reason-phrase = *( HTAB / SP / VCHAR / obs-text ) 539 HTTP status codes are extensible. HTTP applications are not required 540 to understand the meaning of all registered status codes, though such 541 understanding is obviously desirable. However, applications MUST 542 understand the class of any status code, as indicated by the first 543 digit, and treat any unrecognized response as being equivalent to the 544 x00 status code of that class, with the exception that an 545 unrecognized response MUST NOT be cached. For example, if an 546 unrecognized status code of 431 is received by the client, it can 547 safely assume that there was something wrong with its request and 548 treat the response as if it had received a 400 status code. In such 549 cases, user agents SHOULD present to the user the representation 550 enclosed with the response, since that representation is likely to 551 include human-readable information which will explain the unusual 552 status. 554 4.1. Overview of Status Codes 556 The status codes listed below are defined in Section 7 of this 557 specification, Section 4 of [Part4], Section 3 of [Part5], and 558 Section 3 of [Part7]. The reason phrases listed here are only 559 recommendations -- they can be replaced by local equivalents without 560 affecting the protocol. 562 +-------------+------------------------------+----------------------+ 563 | status-code | reason-phrase | Defined in... | 564 +-------------+------------------------------+----------------------+ 565 | 100 | Continue | Section 7.1.1 | 566 | 101 | Switching Protocols | Section 7.1.2 | 567 | 200 | OK | Section 7.2.1 | 568 | 201 | Created | Section 7.2.2 | 569 | 202 | Accepted | Section 7.2.3 | 570 | 203 | Non-Authoritative | Section 7.2.4 | 571 | | Information | | 572 | 204 | No Content | Section 7.2.5 | 573 | 205 | Reset Content | Section 7.2.6 | 574 | 206 | Partial Content | Section 3.1 of | 575 | | | [Part5] | 576 | 300 | Multiple Choices | Section 7.3.1 | 577 | 301 | Moved Permanently | Section 7.3.2 | 578 | 302 | Found | Section 7.3.3 | 579 | 303 | See Other | Section 7.3.4 | 580 | 304 | Not Modified | Section 4.1 of | 581 | | | [Part4] | 582 | 305 | Use Proxy | Section 7.3.5 | 583 | 307 | Temporary Redirect | Section 7.3.7 | 584 | 400 | Bad Request | Section 7.4.1 | 585 | 401 | Unauthorized | Section 3.1 of | 586 | | | [Part7] | 587 | 402 | Payment Required | Section 7.4.2 | 588 | 403 | Forbidden | Section 7.4.3 | 589 | 404 | Not Found | Section 7.4.4 | 590 | 405 | Method Not Allowed | Section 7.4.5 | 591 | 406 | Not Acceptable | Section 7.4.6 | 592 | 407 | Proxy Authentication | Section 3.2 of | 593 | | Required | [Part7] | 594 | 408 | Request Time-out | Section 7.4.7 | 595 | 409 | Conflict | Section 7.4.8 | 596 | 410 | Gone | Section 7.4.9 | 597 | 411 | Length Required | Section 7.4.10 | 598 | 412 | Precondition Failed | Section 4.2 of | 599 | | | [Part4] | 600 | 413 | Request Representation Too | Section 7.4.11 | 601 | | Large | | 602 | 414 | URI Too Long | Section 7.4.12 | 603 | 415 | Unsupported Media Type | Section 7.4.13 | 604 | 416 | Requested range not | Section 3.2 of | 605 | | satisfiable | [Part5] | 606 | 417 | Expectation Failed | Section 7.4.14 | 607 | 426 | Upgrade Required | Section 7.4.15 | 608 | 500 | Internal Server Error | Section 7.5.1 | 609 | 501 | Not Implemented | Section 7.5.2 | 610 | 502 | Bad Gateway | Section 7.5.3 | 611 | 503 | Service Unavailable | Section 7.5.4 | 612 | 504 | Gateway Time-out | Section 7.5.5 | 613 | 505 | HTTP Version not supported | Section 7.5.6 | 614 +-------------+------------------------------+----------------------+ 616 Note that this list is not exhaustive -- it does not include 617 extension status codes defined in other specifications. 619 4.2. Status Code Registry 621 The HTTP Status Code Registry defines the name space for the status- 622 code token in the status-line of an HTTP response. 624 Values to be added to this name space require IETF Review (see 625 [RFC5226], Section 4.1). 627 The registry itself is maintained at 628 . 630 4.2.1. Considerations for New Status Codes 632 When it is necessary to express new semantics for a HTTP response 633 that aren't specific to a single application or media type, and 634 currently defined status codes are inadequate, a new status code can 635 be registered. 637 HTTP status codes are generic; that is, they are potentially 638 applicable to any resource, not just one particular media type, 639 "type" of resource, or application. As such, it is preferred that 640 new HTTP status codes be registered in a document that isn't specific 641 to a single application, so that this is clear. 643 Definitions of new HTTP status codes typically explain the request 644 conditions that produce a response containing the status code (e.g., 645 combinations of request headers and/or method(s)), along with any 646 interactions with response headers (e.g., those that are required, 647 those that modify the semantics of the response). 649 New HTTP status codes are required to fall under one of the 650 categories defined in Section 7. To allow existing parsers to 651 properly handle them, new status codes cannot disallow a response 652 body, although they can mandate a zero-length response body. They 653 can require the presence of one or more particular HTTP response 654 header(s). 656 Likewise, their definitions can specify that caches are allowed to 657 use heuristics to determine their freshness (see [Part6]; by default, 658 it is not allowed), and can define how to determine the resource 659 which they carry a representation for (see Section 5.1; by default, 660 it is anonymous). 662 5. Representation 664 Request and Response messages MAY transfer a representation if not 665 otherwise restricted by the request method or response status code. 666 A representation consists of metadata (representation header fields) 667 and data (representation body). When a complete or partial 668 representation is enclosed in an HTTP message, it is referred to as 669 the payload of the message. HTTP representations are defined in 670 [Part3]. 672 A representation body is only present in a message when a message 673 body is present, as described in Section 3.3 of [Part1]. The 674 representation body is obtained from the message body by decoding any 675 Transfer-Encoding that might have been applied to ensure safe and 676 proper transfer of the message. 678 5.1. Identifying the Resource Associated with a Representation 680 It is sometimes necessary to determine an identifier for the resource 681 associated with a representation. 683 An HTTP request representation, when present, is always associated 684 with an anonymous (i.e., unidentified) resource. 686 In the common case, an HTTP response is a representation of the 687 target resource (see Section 5.5 of [Part1]). However, this is not 688 always the case. To determine the URI of the resource a response is 689 associated with, the following rules are used (with the first 690 applicable one being selected): 692 1. If the response status code is 200 or 203 and the request method 693 was GET, the response payload is a representation of the target 694 resource. 696 2. If the response status code is 204, 206, or 304 and the request 697 method was GET or HEAD, the response payload is a partial 698 representation of the target resource. 700 3. If the response has a Content-Location header field, and that URI 701 is the same as the effective request URI, the response payload is 702 a representation of the target resource. 704 4. If the response has a Content-Location header field, and that URI 705 is not the same as the effective request URI, then the response 706 asserts that its payload is a representation of the resource 707 identified by the Content-Location URI. However, such an 708 assertion cannot be trusted unless it can be verified by other 709 means (not defined by HTTP). 711 5. Otherwise, the response is a representation of an anonymous 712 (i.e., unidentified) resource. 714 [[TODO-req-uri: The comparison function is going to have to be 715 defined somewhere, because we already need to compare URIs for things 716 like cache invalidation.]] 718 6. Method Definitions 720 The set of common request methods for HTTP/1.1 is defined below. 721 Although this set can be expanded, additional methods cannot be 722 assumed to share the same semantics for separately extended clients 723 and servers. 725 6.1. Safe and Idempotent Methods 727 6.1.1. Safe Methods 729 Implementors need to be aware that the software represents the user 730 in their interactions over the Internet, and need to allow the user 731 to be aware of any actions they take which might have an unexpected 732 significance to themselves or others. 734 In particular, the convention has been established that the GET, 735 HEAD, OPTIONS, and TRACE request methods SHOULD NOT have the 736 significance of taking an action other than retrieval. These request 737 methods ought to be considered "safe". This allows user agents to 738 represent other methods, such as POST, PUT and DELETE, in a special 739 way, so that the user is made aware of the fact that a possibly 740 unsafe action is being requested. 742 Naturally, it is not possible to ensure that the server does not 743 generate side-effects as a result of performing a GET request; in 744 fact, some dynamic resources consider that a feature. The important 745 distinction here is that the user did not request the side-effects, 746 so therefore cannot be held accountable for them. 748 6.1.2. Idempotent Methods 750 Request methods can also have the property of "idempotence" in that, 751 aside from error or expiration issues, the intended effect of 752 multiple identical requests is the same as for a single request. 753 PUT, DELETE, and all safe request methods are idempotent. It is 754 important to note that idempotence refers only to changes requested 755 by the client: a server is free to change its state due to multiple 756 requests for the purpose of tracking those requests, versioning of 757 results, etc. 759 6.2. OPTIONS 761 The OPTIONS method requests information about the communication 762 options available on the request/response chain identified by the 763 effective request URI. This method allows a client to determine the 764 options and/or requirements associated with a resource, or the 765 capabilities of a server, without implying a resource action or 766 initiating a resource retrieval. 768 Responses to the OPTIONS method are not cacheable. 770 If the OPTIONS request includes a message body (as indicated by the 771 presence of Content-Length or Transfer-Encoding), then the media type 772 MUST be indicated by a Content-Type field. Although this 773 specification does not define any use for such a body, future 774 extensions to HTTP might use the OPTIONS body to make more detailed 775 queries on the server. 777 If the request-target (Section 5.3 of [Part1]) is an asterisk ("*"), 778 the OPTIONS request is intended to apply to the server in general 779 rather than to a specific resource. Since a server's communication 780 options typically depend on the resource, the "*" request is only 781 useful as a "ping" or "no-op" type of method; it does nothing beyond 782 allowing the client to test the capabilities of the server. For 783 example, this can be used to test a proxy for HTTP/1.1 conformance 784 (or lack thereof). 786 If the request-target is not an asterisk, the OPTIONS request applies 787 only to the options that are available when communicating with that 788 resource. 790 A 200 response SHOULD include any header fields that indicate 791 optional features implemented by the server and applicable to that 792 resource (e.g., Allow), possibly including extensions not defined by 793 this specification. The response body, if any, SHOULD also include 794 information about the communication options. The format for such a 795 body is not defined by this specification, but might be defined by 796 future extensions to HTTP. Content negotiation MAY be used to select 797 the appropriate response format. If no response body is included, 798 the response MUST include a Content-Length field with a field-value 799 of "0". 801 The Max-Forwards header field MAY be used to target a specific proxy 802 in the request chain (see Section 10.6). If no Max-Forwards field is 803 present in the request, then the forwarded request MUST NOT include a 804 Max-Forwards field. 806 6.3. GET 808 The GET method requests transfer of a current representation of the 809 target resource. 811 If the target resource is a data-producing process, it is the 812 produced data which shall be returned as the representation in the 813 response and not the source text of the process, unless that text 814 happens to be the output of the process. 816 The semantics of the GET method change to a "conditional GET" if the 817 request message includes an If-Modified-Since, If-Unmodified-Since, 818 If-Match, If-None-Match, or If-Range header field. A conditional GET 819 requests that the representation be transferred only under the 820 circumstances described by the conditional header field(s). The 821 conditional GET request is intended to reduce unnecessary network 822 usage by allowing cached representations to be refreshed without 823 requiring multiple requests or transferring data already held by the 824 client. 826 The semantics of the GET method change to a "partial GET" if the 827 request message includes a Range header field. A partial GET 828 requests that only part of the representation be transferred, as 829 described in Section 5.4 of [Part5]. The partial GET request is 830 intended to reduce unnecessary network usage by allowing partially- 831 retrieved representations to be completed without transferring data 832 already held by the client. 834 Bodies on GET requests have no defined semantics. Note that sending 835 a body on a GET request might cause some existing implementations to 836 reject the request. 838 The response to a GET request is cacheable and MAY be used to satisfy 839 subsequent GET and HEAD requests (see [Part6]). 841 See Section 12.2 for security considerations when used for forms. 843 6.4. HEAD 845 The HEAD method is identical to GET except that the server MUST NOT 846 return a message body in the response. The metadata contained in the 847 HTTP header fields in response to a HEAD request SHOULD be identical 848 to the information sent in response to a GET request. This method 849 can be used for obtaining metadata about the representation implied 850 by the request without transferring the representation body. This 851 method is often used for testing hypertext links for validity, 852 accessibility, and recent modification. 854 The response to a HEAD request is cacheable and MAY be used to 855 satisfy a subsequent HEAD request. It also has potential side 856 effects on previously stored responses to GET; see Section 2.5 of 857 [Part6]. 859 Bodies on HEAD requests have no defined semantics. Note that sending 860 a body on a HEAD request might cause some existing implementations to 861 reject the request. 863 6.5. POST 865 The POST method requests that the origin server accept the 866 representation enclosed in the request as data to be processed by the 867 target resource. POST is designed to allow a uniform method to cover 868 the following functions: 870 o Annotation of existing resources; 872 o Posting a message to a bulletin board, newsgroup, mailing list, or 873 similar group of articles; 875 o Providing a block of data, such as the result of submitting a 876 form, to a data-handling process; 878 o Extending a database through an append operation. 880 The actual function performed by the POST method is determined by the 881 server and is usually dependent on the effective request URI. 883 The action performed by the POST method might not result in a 884 resource that can be identified by a URI. In this case, either 200 885 (OK) or 204 (No Content) is the appropriate response status code, 886 depending on whether or not the response includes a representation 887 that describes the result. 889 If a resource has been created on the origin server, the response 890 SHOULD be 201 (Created) and contain a representation which describes 891 the status of the request and refers to the new resource, and a 892 Location header field (see Section 10.5). 894 Responses to POST requests are only cacheable when they include 895 explicit freshness information (see Section 2.3.1 of [Part6]). A 896 cached POST response with a Content-Location header field (see 897 Section 6.7 of [Part3]) whose value is the effective Request URI MAY 898 be used to satisfy subsequent GET and HEAD requests. 900 Note that POST caching is not widely implemented. However, the 303 901 (See Other) response can be used to direct the user agent to retrieve 902 a cacheable resource. 904 6.6. PUT 906 The PUT method requests that the state of the target resource be 907 created or replaced with the state defined by the representation 908 enclosed in the request message payload. A successful PUT of a given 909 representation would suggest that a subsequent GET on that same 910 target resource will result in an equivalent representation being 911 returned in a 200 (OK) response. However, there is no guarantee that 912 such a state change will be observable, since the target resource 913 might be acted upon by other user agents in parallel, or might be 914 subject to dynamic processing by the origin server, before any 915 subsequent GET is received. A successful response only implies that 916 the user agent's intent was achieved at the time of its processing by 917 the origin server. 919 If the target resource does not have a current representation and the 920 PUT successfully creates one, then the origin server MUST inform the 921 user agent by sending a 201 (Created) response. If the target 922 resource does have a current representation and that representation 923 is successfully modified in accordance with the state of the enclosed 924 representation, then either a 200 (OK) or 204 (No Content) response 925 SHOULD be sent to indicate successful completion of the request. 927 Unrecognized header fields SHOULD be ignored (i.e., not saved as part 928 of the resource state). 930 An origin server SHOULD verify that the PUT representation is 931 consistent with any constraints which the server has for the target 932 resource that cannot or will not be changed by the PUT. This is 933 particularly important when the origin server uses internal 934 configuration information related to the URI in order to set the 935 values for representation metadata on GET responses. When a PUT 936 representation is inconsistent with the target resource, the origin 937 server SHOULD either make them consistent, by transforming the 938 representation or changing the resource configuration, or respond 939 with an appropriate error message containing sufficient information 940 to explain why the representation is unsuitable. The 409 (Conflict) 941 or 415 (Unsupported Media Type) status codes are suggested, with the 942 latter being specific to constraints on Content-Type values. 944 For example, if the target resource is configured to always have a 945 Content-Type of "text/html" and the representation being PUT has a 946 Content-Type of "image/jpeg", then the origin server SHOULD do one 947 of: (a) reconfigure the target resource to reflect the new media 948 type; (b) transform the PUT representation to a format consistent 949 with that of the resource before saving it as the new resource state; 950 or, (c) reject the request with a 415 response indicating that the 951 target resource is limited to "text/html", perhaps including a link 952 to a different resource that would be a suitable target for the new 953 representation. 955 HTTP does not define exactly how a PUT method affects the state of an 956 origin server beyond what can be expressed by the intent of the user 957 agent request and the semantics of the origin server response. It 958 does not define what a resource might be, in any sense of that word, 959 beyond the interface provided via HTTP. It does not define how 960 resource state is "stored", nor how such storage might change as a 961 result of a change in resource state, nor how the origin server 962 translates resource state into representations. Generally speaking, 963 all implementation details behind the resource interface are 964 intentionally hidden by the server. 966 The fundamental difference between the POST and PUT methods is 967 highlighted by the different intent for the target resource. The 968 target resource in a POST request is intended to handle the enclosed 969 representation as a data-accepting process, such as for a gateway to 970 some other protocol or a document that accepts annotations. In 971 contrast, the target resource in a PUT request is intended to take 972 the enclosed representation as a new or replacement value. Hence, 973 the intent of PUT is idempotent and visible to intermediaries, even 974 though the exact effect is only known by the origin server. 976 Proper interpretation of a PUT request presumes that the user agent 977 knows what target resource is desired. A service that is intended to 978 select a proper URI on behalf of the client, after receiving a state- 979 changing request, SHOULD be implemented using the POST method rather 980 than PUT. If the origin server will not make the requested PUT state 981 change to the target resource and instead wishes to have it applied 982 to a different resource, such as when the resource has been moved to 983 a different URI, then the origin server MUST send a 301 (Moved 984 Permanently) response; the user agent MAY then make its own decision 985 regarding whether or not to redirect the request. 987 A PUT request applied to the target resource MAY have side-effects on 988 other resources. For example, an article might have a URI for 989 identifying "the current version" (a resource) which is separate from 990 the URIs identifying each particular version (different resources 991 that at one point shared the same state as the current version 992 resource). A successful PUT request on "the current version" URI 993 might therefore create a new version resource in addition to changing 994 the state of the target resource, and might also cause links to be 995 added between the related resources. 997 An origin server SHOULD reject any PUT request that contains a 998 Content-Range header field, since it might be misinterpreted as 999 partial content (or might be partial content that is being mistakenly 1000 PUT as a full representation). Partial content updates are possible 1001 by targeting a separately identified resource with state that 1002 overlaps a portion of the larger resource, or by using a different 1003 method that has been specifically defined for partial updates (for 1004 example, the PATCH method defined in [RFC5789]). 1006 Responses to the PUT method are not cacheable. If a PUT request 1007 passes through a cache that has one or more stored responses for the 1008 effective request URI, those stored responses will be invalidated 1009 (see Section 2.6 of [Part6]). 1011 6.7. DELETE 1013 The DELETE method requests that the origin server delete the target 1014 resource. This method MAY be overridden by human intervention (or 1015 other means) on the origin server. The client cannot be guaranteed 1016 that the operation has been carried out, even if the status code 1017 returned from the origin server indicates that the action has been 1018 completed successfully. However, the server SHOULD NOT indicate 1019 success unless, at the time the response is given, it intends to 1020 delete the resource or move it to an inaccessible location. 1022 A successful response SHOULD be 200 (OK) if the response includes an 1023 representation describing the status, 202 (Accepted) if the action 1024 has not yet been enacted, or 204 (No Content) if the action has been 1025 enacted but the response does not include a representation. 1027 Bodies on DELETE requests have no defined semantics. Note that 1028 sending a body on a DELETE request might cause some existing 1029 implementations to reject the request. 1031 Responses to the DELETE method are not cacheable. If a DELETE 1032 request passes through a cache that has one or more stored responses 1033 for the effective request URI, those stored responses will be 1034 invalidated (see Section 2.6 of [Part6]). 1036 6.8. TRACE 1038 The TRACE method requests a remote, application-layer loop-back of 1039 the request message. The final recipient of the request SHOULD 1040 reflect the message received back to the client as the message body 1041 of a 200 (OK) response. The final recipient is either the origin 1042 server or the first proxy to receive a Max-Forwards value of zero (0) 1043 in the request (see Section 10.6). A TRACE request MUST NOT include 1044 a message body. 1046 TRACE allows the client to see what is being received at the other 1047 end of the request chain and use that data for testing or diagnostic 1048 information. The value of the Via header field (Section 6.2 of 1049 [Part1]) is of particular interest, since it acts as a trace of the 1050 request chain. Use of the Max-Forwards header field allows the 1051 client to limit the length of the request chain, which is useful for 1052 testing a chain of proxies forwarding messages in an infinite loop. 1054 If the request is valid, the response SHOULD have a Content-Type of 1055 "message/http" (see Section 7.3.1 of [Part1]) and contain a message 1056 body that encloses a copy of the entire request message. Responses 1057 to the TRACE method are not cacheable. 1059 6.9. CONNECT 1061 The CONNECT method requests that the proxy establish a tunnel to the 1062 request-target and, if successful, thereafter restrict its behavior 1063 to blind forwarding of packets until the connection is closed. 1065 When using CONNECT, the request-target MUST use the authority form 1066 (Section 5.3 of [Part1]); i.e., the request-target consists of only 1067 the host name and port number of the tunnel destination, separated by 1068 a colon. For example, 1070 CONNECT server.example.com:80 HTTP/1.1 1071 Host: server.example.com:80 1073 Any successful (2xx) response to a CONNECT request indicates that the 1074 proxy has established a connection to the requested host and port, 1075 and has switched to tunneling the current connection to that server 1076 connection. The tunneled data from the server begins immediately 1077 after the blank line that concludes the successful response's header 1078 block. A server SHOULD NOT send any Transfer-Encoding or Content- 1079 Length header fields in a successful response. A client MUST ignore 1080 any Content-Length or Transfer-Encoding header fields received in a 1081 successful response. 1083 Any response other than a successful response indicates that the 1084 tunnel has not yet been formed and that the connection remains 1085 governed by HTTP. 1087 Proxy authentication might be used to establish the authority to 1088 create a tunnel: 1090 CONNECT server.example.com:80 HTTP/1.1 1091 Host: server.example.com:80 1092 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1094 A message body on a CONNECT request has no defined semantics. 1095 Sending a body on a CONNECT request might cause existing 1096 implementations to reject the request. 1098 Similar to a pipelined HTTP/1.1 request, data to be tunneled from 1099 client to server MAY be sent immediately after the request (before a 1100 response is received). The usual caveats also apply: data may be 1101 discarded if the eventual response is negative, and the connection 1102 may be reset with no response if more than one TCP segment is 1103 outstanding. 1105 It may be the case that the proxy itself can only reach the requested 1106 origin server through another proxy. In this case, the first proxy 1107 SHOULD make a CONNECT request of that next proxy, requesting a tunnel 1108 to the authority. A proxy MUST NOT respond with any 2xx status code 1109 unless it has either a direct or tunnel connection established to the 1110 authority. 1112 If at any point either one of the peers gets disconnected, any 1113 outstanding data that came from that peer will be passed to the other 1114 one, and after that also the other connection will be terminated by 1115 the proxy. If there is outstanding data to that peer undelivered, 1116 that data will be discarded. 1118 An origin server which receives a CONNECT request for itself MAY 1119 respond with a 2xx status code to indicate that a connection is 1120 established. However, most origin servers do not implement CONNECT. 1122 7. Status Code Definitions 1124 The first digit of the status-code defines the class of response. 1125 The last two digits do not have any categorization role. There are 5 1126 values for the first digit: 1128 o 1xx: Informational - Request received, continuing process 1130 o 2xx: Success - The action was successfully received, understood, 1131 and accepted 1133 o 3xx: Redirection - Further action must be taken in order to 1134 complete the request 1136 o 4xx: Client Error - The request contains bad syntax or cannot be 1137 fulfilled 1139 o 5xx: Server Error - The server failed to fulfill an apparently 1140 valid request 1142 Each status-code is described below, including any metadata required 1143 in the response. 1145 For most status codes the response can carry a payload, in which case 1146 a Content-Type header field indicates the payload's media type 1147 (Section 6.8 of [Part3]). 1149 7.1. Informational 1xx 1151 This class of status code indicates a provisional response, 1152 consisting only of the status-line and optional header fields, and is 1153 terminated by an empty line. There are no required header fields for 1154 this class of status code. Since HTTP/1.0 did not define any 1xx 1155 status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 1156 client except under experimental conditions. 1158 A client MUST be prepared to accept one or more 1xx status responses 1159 prior to a regular response, even if the client does not expect a 100 1160 (Continue) status message. Unexpected 1xx status responses MAY be 1161 ignored by a user agent. 1163 Proxies MUST forward 1xx responses, unless the connection between the 1164 proxy and its client has been closed, or unless the proxy itself 1165 requested the generation of the 1xx response. (For example, if a 1166 proxy adds a "Expect: 100-continue" field when it forwards a request, 1167 then it need not forward the corresponding 100 (Continue) 1168 response(s).) 1170 7.1.1. 100 Continue 1172 The client SHOULD continue with its request. This interim response 1173 is used to inform the client that the initial part of the request has 1174 been received and has not yet been rejected by the server. The 1175 client SHOULD continue by sending the remainder of the request or, if 1176 the request has already been completed, ignore this response. The 1177 server MUST send a final response after the request has been 1178 completed. See Section 6.4.3 of [Part1] for detailed discussion of 1179 the use and handling of this status code. 1181 7.1.2. 101 Switching Protocols 1183 The server understands and is willing to comply with the client's 1184 request, via the Upgrade message header field (Section 6.5 of 1185 [Part1]), for a change in the application protocol being used on this 1186 connection. The server will switch protocols to those defined by the 1187 response's Upgrade header field immediately after the empty line 1188 which terminates the 101 response. 1190 The protocol SHOULD be switched only when it is advantageous to do 1191 so. For example, switching to a newer version of HTTP is 1192 advantageous over older versions, and switching to a real-time, 1193 synchronous protocol might be advantageous when delivering resources 1194 that use such features. 1196 7.2. Successful 2xx 1198 This class of status code indicates that the client's request was 1199 successfully received, understood, and accepted. 1201 7.2.1. 200 OK 1203 The request has succeeded. The payload returned with the response is 1204 dependent on the method used in the request, for example: 1206 GET a representation of the target resource is sent in the response; 1208 HEAD the same representation as GET, except without the message 1209 body; 1211 POST a representation describing or containing the result of the 1212 action; 1214 TRACE a representation containing the request message as received by 1215 the end server. 1217 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1218 determine freshness for 200 responses. 1220 7.2.2. 201 Created 1222 The request has been fulfilled and has resulted in a new resource 1223 being created. 1225 The newly created resource is typically linked to from the response 1226 payload, with the most relevant URI also being carried in the 1227 Location header field. If the newly created resource's URI is the 1228 same as the Effective Request URI, this information can be omitted 1229 (e.g., in the case of a response to a PUT request). 1231 The origin server MUST create the resource before returning the 201 1232 status code. If the action cannot be carried out immediately, the 1233 server SHOULD respond with 202 (Accepted) response instead. 1235 A 201 response MAY contain an ETag response header field indicating 1236 the current value of the entity-tag for the representation of the 1237 resource just created (see Section 2.3 of [Part4]). 1239 7.2.3. 202 Accepted 1241 The request has been accepted for processing, but the processing has 1242 not been completed. The request might or might not eventually be 1243 acted upon, as it might be disallowed when processing actually takes 1244 place. There is no facility for re-sending a status code from an 1245 asynchronous operation such as this. 1247 The 202 response is intentionally non-committal. Its purpose is to 1248 allow a server to accept a request for some other process (perhaps a 1249 batch-oriented process that is only run once per day) without 1250 requiring that the user agent's connection to the server persist 1251 until the process is completed. The representation returned with 1252 this response SHOULD include an indication of the request's current 1253 status and either a pointer to a status monitor or some estimate of 1254 when the user can expect the request to be fulfilled. 1256 7.2.4. 203 Non-Authoritative Information 1258 The representation in the response has been transformed or otherwise 1259 modified by a transforming proxy (Section 2.3 of [Part1]). Note that 1260 the behavior of transforming intermediaries is controlled by the no- 1261 transform Cache-Control directive (Section 3.2 of [Part6]). 1263 This status code is only appropriate when the response status code 1264 would have been 200 (OK) otherwise. When the status code before 1265 transformation would have been different, the 214 Transformation 1266 Applied warn-code (Section 3.6 of [Part6]) is appropriate. 1268 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1269 determine freshness for 203 responses. 1271 7.2.5. 204 No Content 1273 The 204 (No Content) status code indicates that the server has 1274 successfully fulfilled the request and that there is no additional 1275 content to return in the response payload body. Metadata in the 1276 response header fields refer to the target resource and its current 1277 representation after the requested action. 1279 For example, if a 204 status code is received in response to a PUT 1280 request and the response contains an ETag header field, then the PUT 1281 was successful and the ETag field-value contains the entity-tag for 1282 the new representation of that target resource. 1284 The 204 response allows a server to indicate that the action has been 1285 successfully applied to the target resource while implying that the 1286 user agent SHOULD NOT traverse away from its current "document view" 1287 (if any). The server assumes that the user agent will provide some 1288 indication of the success to its user, in accord with its own 1289 interface, and apply any new or updated metadata in the response to 1290 the active representation. 1292 For example, a 204 status code is commonly used with document editing 1293 interfaces corresponding to a "save" action, such that the document 1294 being saved remains available to the user for editing. It is also 1295 frequently used with interfaces that expect automated data transfers 1296 to be prevalent, such as within distributed version control systems. 1298 The 204 response MUST NOT include a message body, and thus is always 1299 terminated by the first empty line after the header fields. 1301 7.2.6. 205 Reset Content 1303 The server has fulfilled the request and the user agent SHOULD reset 1304 the document view which caused the request to be sent. This response 1305 is primarily intended to allow input for actions to take place via 1306 user input, followed by a clearing of the form in which the input is 1307 given so that the user can easily initiate another input action. 1309 The message body included with the response MUST be empty. Note that 1310 receivers still need to parse the response according to the algorithm 1311 defined in Section 3.3 of [Part1]. 1313 7.3. Redirection 3xx 1315 This class of status code indicates that further action needs to be 1316 taken by the user agent in order to fulfill the request. If the 1317 required action involves a subsequent HTTP request, it MAY be carried 1318 out by the user agent without interaction with the user if and only 1319 if the method used in the second request is known to be "safe", as 1320 defined in Section 6.1.1. 1322 There are several types of redirects: 1324 1. Redirects of the request to another URI, either temporarily or 1325 permanently. The new URI is specified in the Location header 1326 field. In this specification, the status codes 301 (Moved 1327 Permanently), 302 (Found), and 307 (Temporary Redirect) fall 1328 under this category. 1330 2. Redirection to a new location that represents an indirect 1331 response to the request, such as the result of a POST operation 1332 to be retrieved with a subsequent GET request. This is status 1333 code 303 (See Other). 1335 3. Redirection offering a choice of matching resources for use by 1336 agent-driven content negotiation (Section 5.2 of [Part3]). This 1337 is status code 300 (Multiple Choices). 1339 4. Other kinds of redirection, such as to a cached result (status 1340 code 304 (Not Modified), see Section 4.1 of [Part4]). 1342 Note: In HTTP/1.0, only the status codes 301 (Moved Permanently) 1343 and 302 (Found) were defined for the first type of redirect, and 1344 the second type did not exist at all ([RFC1945], Section 9.3). 1345 However it turned out that web forms using POST expected redirects 1346 to change the operation for the subsequent request to retrieval 1347 (GET). To address this use case, HTTP/1.1 introduced the second 1348 type of redirect with the status code 303 (See Other) ([RFC2068], 1349 Section 10.3.4). As user agents did not change their behavior to 1350 maintain backwards compatibility, the first revision of HTTP/1.1 1351 added yet another status code, 307 (Temporary Redirect), for which 1352 the backwards compatibility problems did not apply ([RFC2616], 1353 Section 10.3.8). Over 10 years later, most user agents still do 1354 method rewriting for status codes 301 and 302, therefore this 1355 specification makes that behavior conformant in case the original 1356 request was POST. 1358 A Location header field on a 3xx response indicates that a client MAY 1359 automatically redirect to the URI provided; see Section 10.5. 1361 Note that for methods not known to be "safe", as defined in 1362 Section 6.1.1, automatic redirection needs to done with care, since 1363 the redirect might change the conditions under which the request was 1364 issued. 1366 Clients SHOULD detect and intervene in cyclical redirections (i.e., 1367 "infinite" redirection loops). 1369 Note: An earlier version of this specification recommended a 1370 maximum of five redirections ([RFC2068], Section 10.3). Content 1371 developers need to be aware that some clients might implement such 1372 a fixed limitation. 1374 7.3.1. 300 Multiple Choices 1376 The target resource has more than one representation, each with its 1377 own specific location, and agent-driven negotiation information 1378 (Section 5 of [Part3]) is being provided so that the user (or user 1379 agent) can select a preferred representation by redirecting its 1380 request to that location. 1382 Unless it was a HEAD request, the response SHOULD include a 1383 representation containing a list of representation metadata and 1384 location(s) from which the user or user agent can choose the one most 1385 appropriate. Depending upon the format and the capabilities of the 1386 user agent, selection of the most appropriate choice MAY be performed 1387 automatically. However, this specification does not define any 1388 standard for such automatic selection. 1390 If the server has a preferred choice of representation, it SHOULD 1391 include the specific URI for that representation in the Location 1392 field; user agents MAY use the Location field value for automatic 1393 redirection. 1395 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1396 determine freshness for 300 responses. 1398 7.3.2. 301 Moved Permanently 1400 The target resource has been assigned a new permanent URI and any 1401 future references to this resource SHOULD use one of the returned 1402 URIs. Clients with link editing capabilities ought to automatically 1403 re-link references to the effective request URI to one or more of the 1404 new references returned by the server, where possible. 1406 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1407 determine freshness for 301 responses. 1409 The new permanent URI SHOULD be given by the Location field in the 1410 response. A response payload can contain a short hypertext note with 1411 a hyperlink to the new URI(s). 1413 Note: For historic reasons, user agents MAY change the request 1414 method from POST to GET for the subsequent request. If this 1415 behavior is undesired, status code 307 (Temporary Redirect) can be 1416 used instead. 1418 7.3.3. 302 Found 1420 The target resource resides temporarily under a different URI. Since 1421 the redirection might be altered on occasion, the client SHOULD 1422 continue to use the effective request URI for future requests. 1424 The temporary URI SHOULD be given by the Location field in the 1425 response. A response payload can contain a short hypertext note with 1426 a hyperlink to the new URI(s). 1428 Note: For historic reasons, user agents MAY change the request 1429 method from POST to GET for the subsequent request. If this 1430 behavior is undesired, status code 307 (Temporary Redirect) can be 1431 used instead. 1433 7.3.4. 303 See Other 1435 The 303 status code indicates that the server is redirecting the user 1436 agent to a different resource, as indicated by a URI in the Location 1437 header field, that is intended to provide an indirect response to the 1438 original request. In order to satisfy the original request, a user 1439 agent SHOULD perform a retrieval request using the Location URI (a 1440 GET or HEAD request if using HTTP), which may itself be redirected 1441 further, and present the eventual result as an answer to the original 1442 request. Note that the new URI in the Location header field is not 1443 considered equivalent to the effective request URI. 1445 This status code is generally applicable to any HTTP method. It is 1446 primarily used to allow the output of a POST action to redirect the 1447 user agent to a selected resource, since doing so provides the 1448 information corresponding to the POST response in a form that can be 1449 separately identified, bookmarked, and cached independent of the 1450 original request. 1452 A 303 response to a GET request indicates that the requested resource 1453 does not have a representation of its own that can be transferred by 1454 the server over HTTP. The Location URI indicates a resource that is 1455 descriptive of the target resource, such that the follow-on 1456 representation might be useful to recipients without implying that it 1457 adequately represents the target resource. Note that answers to the 1458 questions of what can be represented, what representations are 1459 adequate, and what might be a useful description are outside the 1460 scope of HTTP and thus entirely determined by the URI owner(s). 1462 Except for responses to a HEAD request, the representation of a 303 1463 response SHOULD contain a short hypertext note with a hyperlink to 1464 the Location URI. 1466 7.3.5. 305 Use Proxy 1468 The 305 status code was defined in a previous version of this 1469 specification (see Appendix A), and is now deprecated. 1471 7.3.6. 306 (Unused) 1473 The 306 status code was used in a previous version of the 1474 specification, is no longer used, and the code is reserved. 1476 7.3.7. 307 Temporary Redirect 1478 The target resource resides temporarily under a different URI. Since 1479 the redirection can change over time, the client SHOULD continue to 1480 use the effective request URI for future requests. 1482 The temporary URI SHOULD be given by the Location field in the 1483 response. A response payload can contain a short hypertext note with 1484 a hyperlink to the new URI(s). 1486 Note: This status code is similar to 302 Found, except that it 1487 does not allow rewriting the request method from POST to GET. 1488 This specification defines no equivalent counterpart for 301 Moved 1489 Permanently. 1491 7.4. Client Error 4xx 1493 The 4xx class of status code is intended for cases in which the 1494 client seems to have erred. Except when responding to a HEAD 1495 request, the server SHOULD include a representation containing an 1496 explanation of the error situation, and whether it is a temporary or 1497 permanent condition. These status codes are applicable to any 1498 request method. User agents SHOULD display any included 1499 representation to the user. 1501 7.4.1. 400 Bad Request 1503 The server cannot or will not process the request, due to a client 1504 error (e.g., malformed syntax). 1506 7.4.2. 402 Payment Required 1508 This code is reserved for future use. 1510 7.4.3. 403 Forbidden 1512 The server understood the request, but refuses to authorize it. 1513 Providing different user authentication credentials might be 1514 successful, but any credentials that were provided in the request are 1515 insufficient. The request SHOULD NOT be repeated with the same 1516 credentials. 1518 If the request method was not HEAD and the server wishes to make 1519 public why the request has not been fulfilled, it SHOULD describe the 1520 reason for the refusal in the representation. If the server does not 1521 wish to make this information available to the client, the status 1522 code 404 (Not Found) MAY be used instead. 1524 7.4.4. 404 Not Found 1526 The server has not found anything matching the effective request URI. 1527 No indication is given of whether the condition is temporary or 1528 permanent. The 410 (Gone) status code SHOULD be used if the server 1529 knows, through some internally configurable mechanism, that an old 1530 resource is permanently unavailable and has no forwarding address. 1531 This status code is commonly used when the server does not wish to 1532 reveal exactly why the request has been refused, or when no other 1533 response is applicable. 1535 7.4.5. 405 Method Not Allowed 1537 The method specified in the request-line is not allowed for the 1538 target resource. The response MUST include an Allow header field 1539 containing a list of valid methods for the requested resource. 1541 7.4.6. 406 Not Acceptable 1543 The resource identified by the request is only capable of generating 1544 response representations which have content characteristics not 1545 acceptable according to the Accept and Accept-* header fields sent in 1546 the request (see Section 6 of [Part3]). 1548 Unless it was a HEAD request, the response SHOULD include a 1549 representation containing a list of available representation 1550 characteristics and location(s) from which the user or user agent can 1551 choose the one most appropriate. Depending upon the format and the 1552 capabilities of the user agent, selection of the most appropriate 1553 choice MAY be performed automatically. However, this specification 1554 does not define any standard for such automatic selection. 1556 Note: HTTP/1.1 servers are allowed to return responses which are 1557 not acceptable according to the accept header fields sent in the 1558 request. In some cases, this might even be preferable to sending 1559 a 406 response. User agents are encouraged to inspect the header 1560 fields of an incoming response to determine if it is acceptable. 1562 If the response could be unacceptable, a user agent SHOULD 1563 temporarily stop receipt of more data and query the user for a 1564 decision on further actions. 1566 7.4.7. 408 Request Timeout 1568 The client did not produce a request within the time that the server 1569 was prepared to wait. The client MAY repeat the request without 1570 modifications at any later time. 1572 7.4.8. 409 Conflict 1574 The request could not be completed due to a conflict with the current 1575 state of the resource. This code is only allowed in situations where 1576 it is expected that the user might be able to resolve the conflict 1577 and resubmit the request. The response body SHOULD include enough 1578 information for the user to recognize the source of the conflict. 1579 Ideally, the response representation would include enough information 1580 for the user or user agent to fix the problem; however, that might 1581 not be possible and is not required. 1583 Conflicts are most likely to occur in response to a PUT request. For 1584 example, if versioning were being used and the representation being 1585 PUT included changes to a resource which conflict with those made by 1586 an earlier (third-party) request, the server might use the 409 1587 response to indicate that it can't complete the request. In this 1588 case, the response representation would likely contain a list of the 1589 differences between the two versions. 1591 7.4.9. 410 Gone 1593 The target resource is no longer available at the server and no 1594 forwarding address is known. This condition is expected to be 1595 considered permanent. Clients with link editing capabilities SHOULD 1596 delete references to the effective request URI after user approval. 1597 If the server does not know, or has no facility to determine, whether 1598 or not the condition is permanent, the status code 404 (Not Found) 1599 SHOULD be used instead. 1601 The 410 response is primarily intended to assist the task of web 1602 maintenance by notifying the recipient that the resource is 1603 intentionally unavailable and that the server owners desire that 1604 remote links to that resource be removed. Such an event is common 1605 for limited-time, promotional services and for resources belonging to 1606 individuals no longer working at the server's site. It is not 1607 necessary to mark all permanently unavailable resources as "gone" or 1608 to keep the mark for any length of time -- that is left to the 1609 discretion of the server owner. 1611 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1612 determine freshness for 410 responses. 1614 7.4.10. 411 Length Required 1616 The server refuses to accept the request without a defined Content- 1617 Length. The client MAY repeat the request if it adds a valid 1618 Content-Length header field containing the length of the message body 1619 in the request message. 1621 7.4.11. 413 Request Representation Too Large 1623 The server is refusing to process a request because the request 1624 representation is larger than the server is willing or able to 1625 process. The server MAY close the connection to prevent the client 1626 from continuing the request. 1628 If the condition is temporary, the server SHOULD include a Retry- 1629 After header field to indicate that it is temporary and after what 1630 time the client MAY try again. 1632 7.4.12. 414 URI Too Long 1634 The server is refusing to service the request because the effective 1635 request URI is longer than the server is willing to interpret. This 1636 rare condition is only likely to occur when a client has improperly 1637 converted a POST request to a GET request with long query 1638 information, when the client has descended into a URI "black hole" of 1639 redirection (e.g., a redirected URI prefix that points to a suffix of 1640 itself), or when the server is under attack by a client attempting to 1641 exploit security holes present in some servers using fixed-length 1642 buffers for reading or manipulating the request-target. 1644 7.4.13. 415 Unsupported Media Type 1646 The server is refusing to service the request because the request 1647 payload is in a format not supported by this request method on the 1648 target resource. 1650 7.4.14. 417 Expectation Failed 1652 The expectation given in an Expect header field (see Section 10.3) 1653 could not be met by this server, or, if the server is a proxy, the 1654 server has unambiguous evidence that the request could not be met by 1655 the next-hop server. 1657 7.4.15. 426 Upgrade Required 1659 The request can not be completed without a prior protocol upgrade. 1660 This response MUST include an Upgrade header field (Section 6.5 of 1661 [Part1]) specifying the required protocols. 1663 Example: 1665 HTTP/1.1 426 Upgrade Required 1666 Upgrade: HTTP/3.0 1667 Connection: Upgrade 1668 Content-Length: 53 1669 Content-Type: text/plain 1671 This service requires use of the HTTP/3.0 protocol. 1673 The server SHOULD include a message body in the 426 response which 1674 indicates in human readable form the reason for the error and 1675 describes any alternative courses which may be available to the user. 1677 7.5. Server Error 5xx 1679 Response status codes beginning with the digit "5" indicate cases in 1680 which the server is aware that it has erred or is incapable of 1681 performing the request. Except when responding to a HEAD request, 1682 the server SHOULD include a representation containing an explanation 1683 of the error situation, and whether it is a temporary or permanent 1684 condition. User agents SHOULD display any included representation to 1685 the user. These response codes are applicable to any request method. 1687 7.5.1. 500 Internal Server Error 1689 The server encountered an unexpected condition which prevented it 1690 from fulfilling the request. 1692 7.5.2. 501 Not Implemented 1694 The server does not support the functionality required to fulfill the 1695 request. This is the appropriate response when the server does not 1696 recognize the request method and is not capable of supporting it for 1697 any resource. 1699 7.5.3. 502 Bad Gateway 1701 The server, while acting as a gateway or proxy, received an invalid 1702 response from the upstream server it accessed in attempting to 1703 fulfill the request. 1705 7.5.4. 503 Service Unavailable 1707 The server is currently unable to handle the request due to a 1708 temporary overloading or maintenance of the server. 1710 The implication is that this is a temporary condition which will be 1711 alleviated after some delay. If known, the length of the delay MAY 1712 be indicated in a Retry-After header field (Section 10.8). If no 1713 Retry-After is given, the client SHOULD handle the response as it 1714 would for a 500 response. 1716 Note: The existence of the 503 status code does not imply that a 1717 server must use it when becoming overloaded. Some servers might 1718 wish to simply refuse the connection. 1720 7.5.5. 504 Gateway Timeout 1722 The server, while acting as a gateway or proxy, did not receive a 1723 timely response from the upstream server specified by the URI (e.g., 1724 HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed 1725 to access in attempting to complete the request. 1727 Note to implementors: some deployed proxies are known to return 1728 400 or 500 when DNS lookups time out. 1730 7.5.6. 505 HTTP Version Not Supported 1732 The server does not support, or refuses to support, the protocol 1733 version that was used in the request message. The server is 1734 indicating that it is unable or unwilling to complete the request 1735 using the same major version as the client, as described in Section 1736 2.6 of [Part1], other than with this error message. The response 1737 SHOULD contain a representation describing why that version is not 1738 supported and what other protocols are supported by that server. 1740 8. Date/Time Formats 1742 HTTP applications have historically allowed three different formats 1743 for date/time stamps. However, the preferred format is a fixed- 1744 length subset of that defined by [RFC1123]: 1746 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 1748 The other formats are described here only for compatibility with 1749 obsolete implementations. 1751 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1752 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1754 HTTP/1.1 clients and servers that parse a date value MUST accept all 1755 three formats (for compatibility with HTTP/1.0), though they MUST 1756 only generate the RFC 1123 format for representing HTTP-date values 1757 in header fields. 1759 All HTTP date/time stamps MUST be represented in Greenwich Mean Time 1760 (GMT), without exception. For the purposes of HTTP, GMT is exactly 1761 equal to UTC (Coordinated Universal Time). This is indicated in the 1762 first two formats by the inclusion of "GMT" as the three-letter 1763 abbreviation for time zone, and MUST be assumed when reading the 1764 asctime format. HTTP-date is case sensitive and MUST NOT include 1765 additional whitespace beyond that specifically included as SP in the 1766 grammar. 1768 HTTP-date = rfc1123-date / obs-date 1770 Preferred format: 1772 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT 1773 ; fixed length subset of the format defined in 1774 ; Section 5.2.14 of [RFC1123] 1776 day-name = %x4D.6F.6E ; "Mon", case-sensitive 1777 / %x54.75.65 ; "Tue", case-sensitive 1778 / %x57.65.64 ; "Wed", case-sensitive 1779 / %x54.68.75 ; "Thu", case-sensitive 1780 / %x46.72.69 ; "Fri", case-sensitive 1781 / %x53.61.74 ; "Sat", case-sensitive 1782 / %x53.75.6E ; "Sun", case-sensitive 1784 date1 = day SP month SP year 1785 ; e.g., 02 Jun 1982 1787 day = 2DIGIT 1788 month = %x4A.61.6E ; "Jan", case-sensitive 1789 / %x46.65.62 ; "Feb", case-sensitive 1790 / %x4D.61.72 ; "Mar", case-sensitive 1791 / %x41.70.72 ; "Apr", case-sensitive 1792 / %x4D.61.79 ; "May", case-sensitive 1793 / %x4A.75.6E ; "Jun", case-sensitive 1794 / %x4A.75.6C ; "Jul", case-sensitive 1795 / %x41.75.67 ; "Aug", case-sensitive 1796 / %x53.65.70 ; "Sep", case-sensitive 1797 / %x4F.63.74 ; "Oct", case-sensitive 1798 / %x4E.6F.76 ; "Nov", case-sensitive 1799 / %x44.65.63 ; "Dec", case-sensitive 1800 year = 4DIGIT 1802 GMT = %x47.4D.54 ; "GMT", case-sensitive 1804 time-of-day = hour ":" minute ":" second 1805 ; 00:00:00 - 23:59:59 1807 hour = 2DIGIT 1808 minute = 2DIGIT 1809 second = 2DIGIT 1811 The semantics of day-name, day, month, year, and time-of-day are the 1812 same as those defined for the RFC 5322 constructs with the 1813 corresponding name ([RFC5322], Section 3.3). 1815 Obsolete formats: 1817 obs-date = rfc850-date / asctime-date 1818 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 1819 date2 = day "-" month "-" 2DIGIT 1820 ; day-month-year (e.g., 02-Jun-82) 1822 day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive 1823 / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive 1824 / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive 1825 / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive 1826 / %x46.72.69.64.61.79 ; "Friday", case-sensitive 1827 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 1828 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 1830 asctime-date = day-name SP date3 SP time-of-day SP year 1831 date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) 1832 ; month day (e.g., Jun 2) 1834 Note: Recipients of date values are encouraged to be robust in 1835 accepting date values that might have been sent by non-HTTP 1836 applications, as is sometimes the case when retrieving or posting 1837 messages via proxies/gateways to SMTP or NNTP. 1839 Note: HTTP requirements for the date/time stamp format apply only 1840 to their usage within the protocol stream. Clients and servers 1841 are not required to use these formats for user presentation, 1842 request logging, etc. 1844 9. Product Tokens 1846 Product tokens are used to allow communicating applications to 1847 identify themselves by software name and version. Most fields using 1848 product tokens also allow sub-products which form a significant part 1849 of the application to be listed, separated by whitespace. By 1850 convention, the products are listed in order of their significance 1851 for identifying the application. 1853 product = token ["/" product-version] 1854 product-version = token 1856 Examples: 1858 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1859 Server: Apache/0.8.4 1861 Product tokens SHOULD be short and to the point. They MUST NOT be 1862 used for advertising or other non-essential information. Although 1863 any token octet MAY appear in a product-version, this token SHOULD 1864 only be used for a version identifier (i.e., successive versions of 1865 the same product SHOULD only differ in the product-version portion of 1866 the product value). 1868 10. Header Field Definitions 1870 This section defines the syntax and semantics of HTTP/1.1 header 1871 fields related to request and response semantics. 1873 10.1. Allow 1875 The "Allow" header field lists the set of methods advertised as 1876 supported by the target resource. The purpose of this field is 1877 strictly to inform the recipient of valid request methods associated 1878 with the resource. 1880 Allow = #method 1882 Example of use: 1884 Allow: GET, HEAD, PUT 1886 The actual set of allowed methods is defined by the origin server at 1887 the time of each request. 1889 A proxy MUST NOT modify the Allow header field -- it does not need to 1890 understand all the methods specified in order to handle them 1891 according to the generic message handling rules. 1893 10.2. Date 1895 The "Date" header field represents the date and time at which the 1896 message was originated, having the same semantics as the Origination 1897 Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The 1898 field value is an HTTP-date, as defined in Section 8; it MUST be sent 1899 in rfc1123-date format. 1901 Date = HTTP-date 1903 An example is 1905 Date: Tue, 15 Nov 1994 08:12:31 GMT 1907 Origin servers MUST include a Date header field in all responses, 1908 except in these cases: 1910 1. If the response status code is 100 (Continue) or 101 (Switching 1911 Protocols), the response MAY include a Date header field, at the 1912 server's option. 1914 2. If the response status code conveys a server error, e.g., 500 1915 (Internal Server Error) or 503 (Service Unavailable), and it is 1916 inconvenient or impossible to generate a valid Date. 1918 3. If the server does not have a clock that can provide a reasonable 1919 approximation of the current time, its responses MUST NOT include 1920 a Date header field. 1922 A received message that does not have a Date header field MUST be 1923 assigned one by the recipient if the message will be cached by that 1924 recipient. 1926 Clients can use the Date header field as well; in order to keep 1927 request messages small, they are advised not to include it when it 1928 doesn't convey any useful information (as is usually the case for 1929 requests that do not contain a payload). 1931 The HTTP-date sent in a Date header field SHOULD NOT represent a date 1932 and time subsequent to the generation of the message. It SHOULD 1933 represent the best available approximation of the date and time of 1934 message generation, unless the implementation has no means of 1935 generating a reasonably accurate date and time. In theory, the date 1936 ought to represent the moment just before the payload is generated. 1937 In practice, the date can be generated at any time during the message 1938 origination without affecting its semantic value. 1940 10.3. Expect 1942 The "Expect" header field is used to indicate that particular server 1943 behaviors are required by the client. 1945 Expect = 1#expectation 1947 expectation = expect-name [ BWS "=" BWS expect-value ] 1948 *( OWS ";" [ OWS expect-param ] ) 1949 expect-param = expect-name [ BWS "=" BWS expect-value ] 1951 expect-name = token 1952 expect-value = token / quoted-string 1954 If all received Expect header field(s) are syntactically valid but 1955 contain an expectation that the recipient does not understand or 1956 cannot comply with, the recipient MUST respond with a 417 1957 (Expectation Failed) status code. A recipient of a syntactically 1958 invalid Expectation header field MUST respond with a 4xx status code 1959 other than 417. 1961 The only expectation defined by this specification is: 1963 100-continue 1965 The "100-continue" expectation is defined Section 6.4.3 of 1966 [Part1]. It does not support any expect-params. 1968 Comparison is case-insensitive for names (expect-name), and case- 1969 sensitive for values (expect-value). 1971 The Expect mechanism is hop-by-hop: the above requirements apply to 1972 any server, including proxies. However, the Expect header field 1973 itself is end-to-end; it MUST be forwarded if the request is 1974 forwarded. 1976 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the 1977 Expect header field. 1979 10.4. From 1981 The "From" header field, if given, SHOULD contain an Internet e-mail 1982 address for the human user who controls the requesting user agent. 1983 The address SHOULD be machine-usable, as defined by "mailbox" in 1984 Section 3.4 of [RFC5322]: 1986 From = mailbox 1988 mailbox = 1990 An example is: 1992 From: webmaster@example.org 1994 This header field MAY be used for logging purposes and as a means for 1995 identifying the source of invalid or unwanted requests. It SHOULD 1996 NOT be used as an insecure form of access protection. The 1997 interpretation of this field is that the request is being performed 1998 on behalf of the person given, who accepts responsibility for the 1999 method performed. In particular, robot agents SHOULD include this 2000 header field so that the person responsible for running the robot can 2001 be contacted if problems occur on the receiving end. 2003 The Internet e-mail address in this field MAY be separate from the 2004 Internet host which issued the request. For example, when a request 2005 is passed through a proxy the original issuer's address SHOULD be 2006 used. 2008 The client SHOULD NOT send the From header field without the user's 2009 approval, as it might conflict with the user's privacy interests or 2010 their site's security policy. It is strongly recommended that the 2011 user be able to disable, enable, and modify the value of this field 2012 at any time prior to a request. 2014 10.5. Location 2016 The "Location" header field MAY be sent in responses to refer to a 2017 specific resource in accordance with the semantics of the status 2018 code. 2020 Location = URI-reference 2022 For 201 (Created) responses, the Location is the URI of the new 2023 resource which was created by the request. For 3xx responses, the 2024 location SHOULD indicate the server's preferred URI for automatic 2025 redirection to the resource. 2027 The field value consists of a single URI-reference. When it has the 2028 form of a relative reference ([RFC3986], Section 4.2), the final 2029 value is computed by resolving it against the effective request URI 2030 ([RFC3986], Section 5). If the original URI, as navigated to by the 2031 user agent, did contain a fragment identifier, and the final value 2032 does not, then the original URI's fragment identifier is added to the 2033 final value. 2035 For example, the original URI "http://www.example.org/~tim", combined 2036 with a field value given as: 2038 Location: /pub/WWW/People.html#tim 2040 would result in a final value of 2041 "http://www.example.org/pub/WWW/People.html#tim" 2043 An original URI "http://www.example.org/index.html#larry", combined 2044 with a field value given as: 2046 Location: http://www.example.net/index.html 2048 would result in a final value of 2049 "http://www.example.net/index.html#larry", preserving the original 2050 fragment identifier. 2052 Note: Some recipients attempt to recover from Location fields that 2053 are not valid URI references. This specification does not mandate 2054 or define such processing, but does allow it (see Section 1.1). 2056 There are circumstances in which a fragment identifier in a Location 2057 URI would not be appropriate. For instance, when it appears in a 201 2058 Created response, where the Location header field specifies the URI 2059 for the entire created resource. 2061 Note: The Content-Location header field (Section 6.7 of [Part3]) 2062 differs from Location in that the Content-Location identifies the 2063 most specific resource corresponding to the enclosed 2064 representation. It is therefore possible for a response to 2065 contain header fields for both Location and Content-Location. 2067 10.6. Max-Forwards 2069 The "Max-Forwards" header field provides a mechanism with the TRACE 2070 (Section 6.8) and OPTIONS (Section 6.2) methods to limit the number 2071 of times that the request is forwarded by proxies. This can be 2072 useful when the client is attempting to trace a request which appears 2073 to be failing or looping mid-chain. 2075 Max-Forwards = 1*DIGIT 2077 The Max-Forwards value is a decimal integer indicating the remaining 2078 number of times this request message can be forwarded. 2080 Each recipient of a TRACE or OPTIONS request containing a Max- 2081 Forwards header field MUST check and update its value prior to 2082 forwarding the request. If the received value is zero (0), the 2083 recipient MUST NOT forward the request; instead, it MUST respond as 2084 the final recipient. If the received Max-Forwards value is greater 2085 than zero, then the forwarded message MUST contain an updated Max- 2086 Forwards field with a value decremented by one (1). 2088 The Max-Forwards header field MAY be ignored for all other request 2089 methods. 2091 10.7. Referer 2093 The "Referer" [sic] header field allows the client to specify the URI 2094 of the resource from which the target URI was obtained (the 2095 "referrer", although the header field is misspelled.). 2097 The Referer header field allows servers to generate lists of back- 2098 links to resources for interest, logging, optimized caching, etc. It 2099 also allows obsolete or mistyped links to be traced for maintenance. 2100 Some servers use Referer as a means of controlling where they allow 2101 links from (so-called "deep linking"), but legitimate requests do not 2102 always contain a Referer header field. 2104 If the target URI was obtained from a source that does not have its 2105 own URI (e.g., input from the user keyboard), the Referer field MUST 2106 either be sent with the value "about:blank", or not be sent at all. 2108 Note that this requirement does not apply to sources with non-HTTP 2109 URIs (e.g., FTP). 2111 Referer = absolute-URI / partial-URI 2113 Example: 2115 Referer: http://www.example.org/hypertext/Overview.html 2117 If the field value is a relative URI, it SHOULD be interpreted 2118 relative to the effective request URI. The URI MUST NOT include a 2119 fragment. See Section 12.2 for security considerations. 2121 10.8. Retry-After 2123 The header "Retry-After" field can be used with a 503 (Service 2124 Unavailable) response to indicate how long the service is expected to 2125 be unavailable to the requesting client. This field MAY also be used 2126 with any 3xx (Redirection) response to indicate the minimum time the 2127 user-agent is asked to wait before issuing the redirected request. 2129 The value of this field can be either an HTTP-date or an integer 2130 number of seconds (in decimal) after the time of the response. 2132 Retry-After = HTTP-date / delta-seconds 2134 Time spans are non-negative decimal integers, representing time in 2135 seconds. 2137 delta-seconds = 1*DIGIT 2139 Two examples of its use are 2141 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 2142 Retry-After: 120 2144 In the latter example, the delay is 2 minutes. 2146 10.9. Server 2148 The "Server" header field contains information about the software 2149 used by the origin server to handle the request. 2151 The field can contain multiple product tokens (Section 9) and 2152 comments (Section 3.2 of [Part1]) identifying the server and any 2153 significant subproducts. The product tokens are listed in order of 2154 their significance for identifying the application. 2156 Server = product *( RWS ( product / comment ) ) 2158 Example: 2160 Server: CERN/3.0 libwww/2.17 2162 If the response is being forwarded through a proxy, the proxy 2163 application MUST NOT modify the Server header field. Instead, it 2164 MUST include a Via field (as described in Section 6.2 of [Part1]). 2166 Note: Revealing the specific software version of the server might 2167 allow the server machine to become more vulnerable to attacks 2168 against software that is known to contain security holes. Server 2169 implementors are encouraged to make this field a configurable 2170 option. 2172 10.10. User-Agent 2174 The "User-Agent" header field contains information about the user 2175 agent originating the request. User agents SHOULD include this field 2176 with requests. 2178 Typically, it is used for statistical purposes, the tracing of 2179 protocol violations, and tailoring responses to avoid particular user 2180 agent limitations. 2182 The field can contain multiple product tokens (Section 9) and 2183 comments (Section 3.2 of [Part1]) identifying the agent and its 2184 significant subproducts. By convention, the product tokens are 2185 listed in order of their significance for identifying the 2186 application. 2188 Because this field is usually sent on every request a user agent 2189 makes, implementations are encouraged not to include needlessly fine- 2190 grained detail, and to limit (or even prohibit) the addition of 2191 subproducts by third parties. Overly long and detailed User-Agent 2192 field values make requests larger and can also be used to identify 2193 ("fingerprint") the user against their wishes. 2195 Likewise, implementations are encouraged not to use the product 2196 tokens of other implementations in order to declare compatibility 2197 with them, as this circumvents the purpose of the field. Finally, 2198 they are encouraged not to use comments to identify products; doing 2199 so makes the field value more difficult to parse. 2201 User-Agent = product *( RWS ( product / comment ) ) 2203 Example: 2205 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 2207 11. IANA Considerations 2209 11.1. Method Registry 2211 The registration procedure for HTTP request methods is defined by 2212 Section 2.2 of this document. 2214 The HTTP Method Registry shall be created at 2215 and be populated with 2216 the registrations below: 2218 +---------+------+-------------+ 2219 | Method | Safe | Reference | 2220 +---------+------+-------------+ 2221 | CONNECT | no | Section 6.9 | 2222 | DELETE | no | Section 6.7 | 2223 | GET | yes | Section 6.3 | 2224 | HEAD | yes | Section 6.4 | 2225 | OPTIONS | yes | Section 6.2 | 2226 | POST | no | Section 6.5 | 2227 | PUT | no | Section 6.6 | 2228 | TRACE | yes | Section 6.8 | 2229 +---------+------+-------------+ 2231 11.2. Status Code Registry 2233 The registration procedure for HTTP Status Codes -- previously 2234 defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.2 2235 of this document. 2237 The HTTP Status Code Registry located at 2238 shall be updated 2239 with the registrations below: 2241 +-------+----------------------------------+----------------+ 2242 | Value | Description | Reference | 2243 +-------+----------------------------------+----------------+ 2244 | 100 | Continue | Section 7.1.1 | 2245 | 101 | Switching Protocols | Section 7.1.2 | 2246 | 200 | OK | Section 7.2.1 | 2247 | 201 | Created | Section 7.2.2 | 2248 | 202 | Accepted | Section 7.2.3 | 2249 | 203 | Non-Authoritative Information | Section 7.2.4 | 2250 | 204 | No Content | Section 7.2.5 | 2251 | 205 | Reset Content | Section 7.2.6 | 2252 | 300 | Multiple Choices | Section 7.3.1 | 2253 | 301 | Moved Permanently | Section 7.3.2 | 2254 | 302 | Found | Section 7.3.3 | 2255 | 303 | See Other | Section 7.3.4 | 2256 | 305 | Use Proxy | Section 7.3.5 | 2257 | 306 | (Unused) | Section 7.3.6 | 2258 | 307 | Temporary Redirect | Section 7.3.7 | 2259 | 400 | Bad Request | Section 7.4.1 | 2260 | 402 | Payment Required | Section 7.4.2 | 2261 | 403 | Forbidden | Section 7.4.3 | 2262 | 404 | Not Found | Section 7.4.4 | 2263 | 405 | Method Not Allowed | Section 7.4.5 | 2264 | 406 | Not Acceptable | Section 7.4.6 | 2265 | 408 | Request Timeout | Section 7.4.7 | 2266 | 409 | Conflict | Section 7.4.8 | 2267 | 410 | Gone | Section 7.4.9 | 2268 | 411 | Length Required | Section 7.4.10 | 2269 | 413 | Request Representation Too Large | Section 7.4.11 | 2270 | 414 | URI Too Long | Section 7.4.12 | 2271 | 415 | Unsupported Media Type | Section 7.4.13 | 2272 | 417 | Expectation Failed | Section 7.4.14 | 2273 | 426 | Upgrade Required | Section 7.4.15 | 2274 | 500 | Internal Server Error | Section 7.5.1 | 2275 | 501 | Not Implemented | Section 7.5.2 | 2276 | 502 | Bad Gateway | Section 7.5.3 | 2277 | 503 | Service Unavailable | Section 7.5.4 | 2278 | 504 | Gateway Timeout | Section 7.5.5 | 2279 | 505 | HTTP Version Not Supported | Section 7.5.6 | 2280 +-------+----------------------------------+----------------+ 2282 11.3. Header Field Registration 2284 The Message Header Field Registry located at shall be 2286 updated with the permanent registrations below (see [RFC3864]): 2288 +-------------------+----------+----------+---------------+ 2289 | Header Field Name | Protocol | Status | Reference | 2290 +-------------------+----------+----------+---------------+ 2291 | Allow | http | standard | Section 10.1 | 2292 | Date | http | standard | Section 10.2 | 2293 | Expect | http | standard | Section 10.3 | 2294 | From | http | standard | Section 10.4 | 2295 | Location | http | standard | Section 10.5 | 2296 | Max-Forwards | http | standard | Section 10.6 | 2297 | Referer | http | standard | Section 10.7 | 2298 | Retry-After | http | standard | Section 10.8 | 2299 | Server | http | standard | Section 10.9 | 2300 | User-Agent | http | standard | Section 10.10 | 2301 +-------------------+----------+----------+---------------+ 2303 The change controller is: "IETF (iesg@ietf.org) - Internet 2304 Engineering Task Force". 2306 12. Security Considerations 2308 This section is meant to inform application developers, information 2309 providers, and users of the security limitations in HTTP/1.1 as 2310 described by this document. The discussion does not include 2311 definitive solutions to the problems revealed, though it does make 2312 some suggestions for reducing security risks. 2314 12.1. Transfer of Sensitive Information 2316 Like any generic data transfer protocol, HTTP cannot regulate the 2317 content of the data that is transferred, nor is there any a priori 2318 method of determining the sensitivity of any particular piece of 2319 information within the context of any given request. Therefore, 2320 applications SHOULD supply as much control over this information as 2321 possible to the provider of that information. Four header fields are 2322 worth special mention in this context: Server, Via, Referer and From. 2324 Revealing the specific software version of the server might allow the 2325 server machine to become more vulnerable to attacks against software 2326 that is known to contain security holes. Implementors SHOULD make 2327 the Server header field a configurable option. 2329 Proxies which serve as a portal through a network firewall SHOULD 2330 take special precautions regarding the transfer of header information 2331 that identifies the hosts behind the firewall. In particular, they 2332 SHOULD remove, or replace with sanitized versions, any Via fields 2333 generated behind the firewall. 2335 The Referer header field allows reading patterns to be studied and 2336 reverse links drawn. Although it can be very useful, its power can 2337 be abused if user details are not separated from the information 2338 contained in the Referer. Even when the personal information has 2339 been removed, the Referer header field might indicate a private 2340 document's URI whose publication would be inappropriate. 2342 The information sent in the From field might conflict with the user's 2343 privacy interests or their site's security policy, and hence it 2344 SHOULD NOT be transmitted without the user being able to disable, 2345 enable, and modify the contents of the field. The user MUST be able 2346 to set the contents of this field within a user preference or 2347 application defaults configuration. 2349 We suggest, though do not require, that a convenient toggle interface 2350 be provided for the user to enable or disable the sending of From and 2351 Referer information. 2353 The User-Agent (Section 10.10) or Server (Section 10.9) header fields 2354 can sometimes be used to determine that a specific client or server 2355 has a particular security hole which might be exploited. 2356 Unfortunately, this same information is often used for other valuable 2357 purposes for which HTTP currently has no better mechanism. 2359 Furthermore, the User-Agent header field may contain enough entropy 2360 to be used, possibly in conjunction with other material, to uniquely 2361 identify the user. 2363 Some request methods, like TRACE (Section 6.8), expose information 2364 that was sent in request header fields within the body of their 2365 response. Clients SHOULD be careful with sensitive information, like 2366 Cookies, Authorization credentials, and other header fields that 2367 might be used to collect data from the client. 2369 12.2. Encoding Sensitive Information in URIs 2371 Because the source of a link might be private information or might 2372 reveal an otherwise private information source, it is strongly 2373 recommended that the user be able to select whether or not the 2374 Referer field is sent. For example, a browser client could have a 2375 toggle switch for browsing openly/anonymously, which would 2376 respectively enable/disable the sending of Referer and From 2377 information. 2379 Clients SHOULD NOT include a Referer header field in a (non-secure) 2380 HTTP request if the referring page was transferred with a secure 2381 protocol. 2383 Authors of services SHOULD NOT use GET-based forms for the submission 2384 of sensitive data because that data will be placed in the request- 2385 target. Many existing servers, proxies, and user agents log or 2386 display the request-target in places where it might be visible to 2387 third parties. Such services can use POST-based form submission 2388 instead. 2390 12.3. Location Header Fields: Spoofing and Information Leakage 2392 If a single server supports multiple organizations that do not trust 2393 one another, then it MUST check the values of Location and Content- 2394 Location header fields in responses that are generated under control 2395 of said organizations to make sure that they do not attempt to 2396 invalidate resources over which they have no authority. 2398 Furthermore, appending the fragment identifier from one URI to 2399 another one obtained from a Location header field might leak 2400 confidential information to the target server -- although the 2401 fragment identifier is not transmitted in the final request, it might 2402 be visible to the user agent through other means, such as scripting. 2404 12.4. Security Considerations for CONNECT 2406 Since tunneled data is opaque to the proxy, there are additional 2407 risks to tunneling to other well-known or reserved ports. A HTTP 2408 client CONNECTing to port 25 could relay spam via SMTP, for example. 2409 As such, proxies SHOULD restrict CONNECT access to a small number of 2410 known ports. 2412 13. Acknowledgments 2414 See Section 9 of [Part1]. 2416 14. References 2418 14.1. Normative References 2420 [Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 2421 "HTTP/1.1, part 1: URIs, Connections, and Message 2422 Parsing", draft-ietf-httpbis-p1-messaging-19 (work in 2423 progress), March 2012. 2425 [Part3] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 2426 "HTTP/1.1, part 3: Message Payload and Content 2427 Negotiation", draft-ietf-httpbis-p3-payload-19 (work in 2428 progress), March 2012. 2430 [Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 2431 "HTTP/1.1, part 4: Conditional Requests", 2432 draft-ietf-httpbis-p4-conditional-19 (work in progress), 2433 March 2012. 2435 [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 2436 "HTTP/1.1, part 5: Range Requests and Partial Responses", 2437 draft-ietf-httpbis-p5-range-19 (work in progress), 2438 March 2012. 2440 [Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed., 2441 and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", 2442 draft-ietf-httpbis-p6-cache-19 (work in progress), 2443 March 2012. 2445 [Part7] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 2446 "HTTP/1.1, part 7: Authentication", 2447 draft-ietf-httpbis-p7-auth-19 (work in progress), 2448 March 2012. 2450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2451 Requirement Levels", BCP 14, RFC 2119, March 1997. 2453 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2454 Resource Identifier (URI): Generic Syntax", STD 66, 2455 RFC 3986, January 2005. 2457 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2458 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2460 14.2. Informative References 2462 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 2463 and Support", STD 3, RFC 1123, October 1989. 2465 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 2466 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 2468 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 2469 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 2470 RFC 2068, January 1997. 2472 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2473 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2474 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2476 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 2477 HTTP/1.1", RFC 2817, May 2000. 2479 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 2480 Procedures for Message Header Fields", BCP 90, RFC 3864, 2481 September 2004. 2483 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2484 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2485 May 2008. 2487 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 2488 October 2008. 2490 [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", 2491 RFC 5789, March 2010. 2493 [RFC5987] Reschke, J., "Character Set and Language Encoding for 2494 Hypertext Transfer Protocol (HTTP) Header Field 2495 Parameters", RFC 5987, August 2010. 2497 Appendix A. Changes from RFC 2616 2499 This document takes over the Status Code Registry, previously defined 2500 in Section 7.1 of [RFC2817]. (Section 4.2) 2502 Clarify definition of POST. (Section 6.5) 2504 Remove requirement to handle all Content-* header fields; ban use of 2505 Content-Range with PUT. (Section 6.6) 2507 Take over definition of CONNECT method from [RFC2817]. (Section 6.9) 2509 Broadened the definition of 203 (Non-Authoritative Information) to 2510 include cases of payload transformations as well. (Section 7.2.4) 2512 Status codes 301, 302, and 307: removed the normative requirements on 2513 both response payloads and user interaction. (Section 7.3) 2515 Failed to consider that there are many other request methods that are 2516 safe to automatically redirect, and further that the user agent is 2517 able to make that determination based on the request method 2518 semantics. Furthermore, allow user agents to rewrite the method from 2519 POST to GET for status codes 301 and 302. (Sections 7.3.2, 7.3.3 and 2520 7.3.7) 2522 Deprecate 305 Use Proxy status code, because user agents did not 2523 implement it. It used to indicate that the target resource must be 2524 accessed through the proxy given by the Location field. The Location 2525 field gave the URI of the proxy. The recipient was expected to 2526 repeat this single request via the proxy. (Section 7.3.5) 2527 Define status 426 (Upgrade Required) (this was incorporated from 2528 [RFC2817]). (Section 7.4.15) 2530 Change ABNF productions for header fields to only define the field 2531 value. (Section 10) 2533 Reclassify "Allow" as response header field, removing the option to 2534 specify it in a PUT request. Relax the server requirement on the 2535 contents of the Allow header field and remove requirement on clients 2536 to always trust the header field value. (Section 10.1) 2538 The ABNF for the Expect header field has been both fixed (allowing 2539 parameters for value-less expectations as well) and simplified 2540 (allowing trailing semicolons after "100-continue" when they were 2541 invalid before). (Section 10.3) 2543 Correct syntax of Location header field to allow URI references 2544 (including relative references and fragments), as referred symbol 2545 "absoluteURI" wasn't what was expected, and add some clarifications 2546 as to when use of fragments would not be appropriate. (Section 10.5) 2548 Restrict Max-Forwards header field to OPTIONS and TRACE (previously, 2549 extension methods could have used it as well). (Section 10.6) 2551 Allow Referer field value of "about:blank" as alternative to not 2552 specifying it. (Section 10.7) 2554 In the description of the Server header field, the Via field was 2555 described as a SHOULD. The requirement was and is stated correctly 2556 in the description of the Via header field in Section 6.2 of [Part1]. 2557 (Section 10.9) 2559 Appendix B. Collected ABNF 2561 Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ] 2563 BWS = 2565 Date = HTTP-date 2567 Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) 2569 From = mailbox 2571 GMT = %x47.4D.54 ; GMT 2573 HTTP-date = rfc1123-date / obs-date 2574 Location = URI-reference 2576 Max-Forwards = 1*DIGIT 2578 OWS = 2580 RWS = 2581 Referer = absolute-URI / partial-URI 2582 Retry-After = HTTP-date / delta-seconds 2584 Server = product *( RWS ( product / comment ) ) 2586 URI-reference = 2587 User-Agent = product *( RWS ( product / comment ) ) 2589 absolute-URI = 2590 asctime-date = day-name SP date3 SP time-of-day SP year 2592 comment = 2594 date1 = day SP month SP year 2595 date2 = day "-" month "-" 2DIGIT 2596 date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) 2597 day = 2DIGIT 2598 day-name = %x4D.6F.6E ; Mon 2599 / %x54.75.65 ; Tue 2600 / %x57.65.64 ; Wed 2601 / %x54.68.75 ; Thu 2602 / %x46.72.69 ; Fri 2603 / %x53.61.74 ; Sat 2604 / %x53.75.6E ; Sun 2605 day-name-l = %x4D.6F.6E.64.61.79 ; Monday 2606 / %x54.75.65.73.64.61.79 ; Tuesday 2607 / %x57.65.64.6E.65.73.64.61.79 ; Wednesday 2608 / %x54.68.75.72.73.64.61.79 ; Thursday 2609 / %x46.72.69.64.61.79 ; Friday 2610 / %x53.61.74.75.72.64.61.79 ; Saturday 2611 / %x53.75.6E.64.61.79 ; Sunday 2612 delta-seconds = 1*DIGIT 2614 expect-name = token 2615 expect-param = expect-name [ BWS "=" BWS expect-value ] 2616 expect-value = token / quoted-string 2617 expectation = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [ 2618 OWS expect-param ] ) 2620 hour = 2DIGIT 2621 mailbox = 2622 method = token 2623 minute = 2DIGIT 2624 month = %x4A.61.6E ; Jan 2625 / %x46.65.62 ; Feb 2626 / %x4D.61.72 ; Mar 2627 / %x41.70.72 ; Apr 2628 / %x4D.61.79 ; May 2629 / %x4A.75.6E ; Jun 2630 / %x4A.75.6C ; Jul 2631 / %x41.75.67 ; Aug 2632 / %x53.65.70 ; Sep 2633 / %x4F.63.74 ; Oct 2634 / %x4E.6F.76 ; Nov 2635 / %x44.65.63 ; Dec 2637 obs-date = rfc850-date / asctime-date 2638 obs-text = 2640 partial-URI = 2641 product = token [ "/" product-version ] 2642 product-version = token 2644 quoted-string = 2646 reason-phrase = *( HTAB / SP / VCHAR / obs-text ) 2647 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT 2648 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 2650 second = 2DIGIT 2651 status-code = 3DIGIT 2653 time-of-day = hour ":" minute ":" second 2654 token = 2656 year = 4DIGIT 2657 ABNF diagnostics: 2659 ; Allow defined but not used 2660 ; Date defined but not used 2661 ; Expect defined but not used 2662 ; From defined but not used 2663 ; Location defined but not used 2664 ; Max-Forwards defined but not used 2665 ; Referer defined but not used 2666 ; Retry-After defined but not used 2667 ; Server defined but not used 2668 ; User-Agent defined but not used 2669 ; reason-phrase defined but not used 2670 ; status-code defined but not used 2672 Appendix C. Change Log (to be removed by RFC Editor before publication) 2674 C.1. Since RFC 2616 2676 Extracted relevant partitions from [RFC2616]. 2678 C.2. Since draft-ietf-httpbis-p2-semantics-00 2680 Closed issues: 2682 o : "Via is a MUST" 2683 () 2685 o : "Fragments 2686 allowed in Location" 2687 () 2689 o : "Safe Methods 2690 vs Redirection" () 2692 o : "Revise 2693 description of the POST method" 2694 () 2696 o : "Normative and 2697 Informative references" 2699 o : "RFC2606 2700 Compliance" 2702 o : "Informative 2703 references" 2705 o : "Redundant 2706 cross-references" 2708 Other changes: 2710 o Move definitions of 304 and 412 condition codes to [Part4] 2712 C.3. Since draft-ietf-httpbis-p2-semantics-01 2714 Closed issues: 2716 o : "PUT side 2717 effects" 2719 o : "Duplicate Host 2720 header requirements" 2722 Ongoing work on ABNF conversion 2723 (): 2725 o Move "Product Tokens" section (back) into Part 1, as "token" is 2726 used in the definition of the Upgrade header field. 2728 o Add explicit references to BNF syntax and rules imported from 2729 other parts of the specification. 2731 o Copy definition of delta-seconds from Part6 instead of referencing 2732 it. 2734 C.4. Since draft-ietf-httpbis-p2-semantics-02 2736 Closed issues: 2738 o : "Requiring 2739 Allow in 405 responses" 2741 o : "Status Code 2742 Registry" 2744 o : "Redirection 2745 vs. Location" 2747 o : "Cacheability 2748 of 303 response" 2750 o : "305 Use Proxy" 2751 o : 2752 "Classification for Allow header" 2754 o : "PUT - 'store 2755 under' vs 'store at'" 2757 Ongoing work on IANA Message Header Field Registration 2758 (): 2760 o Reference RFC 3984, and update header field registrations for 2761 headers defined in this document. 2763 Ongoing work on ABNF conversion 2764 (): 2766 o Replace string literals when the string really is case-sensitive 2767 (method). 2769 C.5. Since draft-ietf-httpbis-p2-semantics-03 2771 Closed issues: 2773 o : "OPTIONS 2774 request bodies" 2776 o : "Description 2777 of CONNECT should refer to RFC2817" 2779 o : "Location 2780 Content-Location reference request/response mixup" 2782 Ongoing work on Method Registry 2783 (): 2785 o Added initial proposal for registration process, plus initial 2786 content (non-HTTP/1.1 methods to be added by a separate 2787 specification). 2789 C.6. Since draft-ietf-httpbis-p2-semantics-04 2791 Closed issues: 2793 o : "Content-*" 2795 o : "RFC 2822 is 2796 updated by RFC 5322" 2798 Ongoing work on ABNF conversion 2799 (): 2801 o Use "/" instead of "|" for alternatives. 2803 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 2804 whitespace ("OWS") and required whitespace ("RWS"). 2806 o Rewrite ABNFs to spell out whitespace rules, factor out header 2807 field value format definitions. 2809 C.7. Since draft-ietf-httpbis-p2-semantics-05 2811 Closed issues: 2813 o : "reason-phrase 2814 BNF" 2816 Final work on ABNF conversion 2817 (): 2819 o Add appendix containing collected and expanded ABNF, reorganize 2820 ABNF introduction. 2822 C.8. Since draft-ietf-httpbis-p2-semantics-06 2824 Closed issues: 2826 o : "Clarify when 2827 Referer is sent" 2829 o : "status codes 2830 vs methods" 2832 o : "Do not 2833 require "updates" relation for specs that register status codes or 2834 method names" 2836 C.9. Since draft-ietf-httpbis-p2-semantics-07 2838 Closed issues: 2840 o : "Idempotency" 2842 o : "TRACE security 2843 considerations" 2845 o : "Clarify rules 2846 for determining what entities a response carries" 2848 o : "update note 2849 citing RFC 1945 and 2068" 2851 o : "update note 2852 about redirect limit" 2854 o : "Location 2855 header ABNF should use 'URI'" 2857 o : "fragments in 2858 Location vs status 303" 2860 o : "move IANA 2861 registrations for optional status codes" 2863 Partly resolved issues: 2865 o : "Are OPTIONS 2866 and TRACE safe?" 2868 C.10. Since draft-ietf-httpbis-p2-semantics-08 2870 Closed issues: 2872 o : "Safe Methods 2873 vs Redirection" (we missed the introduction to the 3xx status 2874 codes when fixing this previously) 2876 C.11. Since draft-ietf-httpbis-p2-semantics-09 2878 Closed issues: 2880 o : "Fragment 2881 combination / precedence during redirects" 2883 Partly resolved issues: 2885 o : "Location 2886 header payload handling" 2888 o : "Term for the 2889 requested resource's URI" 2891 C.12. Since draft-ietf-httpbis-p2-semantics-10 2893 Closed issues: 2895 o : "Clarify 2896 'Requested Variant'" 2898 o : "Clarify 2899 entity / representation / variant terminology" 2901 o : "Methods and 2902 Caching" 2904 o : "OPTIONS vs 2905 Max-Forwards" 2907 o : "Status codes 2908 and caching" 2910 o : "consider 2911 removing the 'changes from 2068' sections" 2913 C.13. Since draft-ietf-httpbis-p2-semantics-11 2915 Closed issues: 2917 o : 2918 "Considerations for new status codes" 2920 o : 2921 "Considerations for new methods" 2923 o : "User-Agent 2924 guidelines" (relating to the 'User-Agent' header field) 2926 C.14. Since draft-ietf-httpbis-p2-semantics-12 2928 Closed issues: 2930 o : "Fragment 2931 combination / precedence during redirects" (added warning about 2932 having a fragid on the redirect may cause inconvenience in some 2933 cases) 2935 o : "Content-* vs. 2936 PUT" 2938 o : "205 Bodies" 2940 o : "Understanding 2941 Content-* on non-PUT requests" 2943 o : "Content-*" 2945 o : "Header type 2946 defaulting" 2948 o : "PUT - 'store 2949 under' vs 'store at'" 2951 o : "duplicate 2952 ABNF for reason-phrase" 2954 o : "Note special 2955 status of Content-* prefix in header registration procedures" 2957 o : "Max-Forwards 2958 vs extension methods" 2960 o : "What is the 2961 value space of HTTP status codes?" (actually fixed in 2962 draft-ietf-httpbis-p2-semantics-11) 2964 o : "Header 2965 Classification" 2967 o : "PUT side 2968 effect: invalidation or just stale?" 2970 o : "proxies not 2971 supporting certain methods" 2973 o : "Migrate 2974 CONNECT from RFC2817 to p2" 2976 o : "Migrate 2977 Upgrade details from RFC2817" 2979 o : "clarify PUT 2980 semantics'" 2982 o : "duplicate 2983 ABNF for 'Method'" 2985 o : "untangle 2986 ABNFs for header fields" 2988 C.15. Since draft-ietf-httpbis-p2-semantics-13 2990 Closed issues: 2992 o : "untangle 2993 ABNFs for header fields" 2995 o : "message body 2996 in CONNECT request" 2998 C.16. Since draft-ietf-httpbis-p2-semantics-14 3000 Closed issues: 3002 o : "Clarify 3003 status code for rate limiting" 3005 o : "clarify 403 3006 forbidden" 3008 o : "Clarify 203 3009 Non-Authoritative Information" 3011 o : "update 3012 default reason phrase for 413" 3014 C.17. Since draft-ietf-httpbis-p2-semantics-15 3016 Closed issues: 3018 o : "Strength of 3019 requirements on Accept re: 406" 3021 o : "400 response 3022 isn't generic" 3024 C.18. Since draft-ietf-httpbis-p2-semantics-16 3026 Closed issues: 3028 o : "Redirects and 3029 non-GET methods" 3031 o : "Document 3032 HTTP's error-handling philosophy" 3034 o : 3035 "Considerations for new headers" 3037 o : "clarify 303 3038 redirect on HEAD" 3040 C.19. Since draft-ietf-httpbis-p2-semantics-17 3042 Closed issues: 3044 o : "Location 3045 header payload handling" 3047 o : "Clarify 3048 status code for rate limiting" (change backed out because a new 3049 status code is being defined for this purpose) 3051 o : "should there 3052 be a permanent variant of 307" 3054 o : "When are 3055 Location's semantics triggered?" 3057 o : "'expect' 3058 grammar missing OWS" 3060 o : "header field 3061 considerations: quoted-string vs use of double quotes" 3063 C.20. Since draft-ietf-httpbis-p2-semantics-18 3065 Closed issues: 3067 o : "Combining 3068 HEAD responses" 3070 o : "Requirements 3071 for user intervention during redirects" 3073 o : "message-body 3074 in CONNECT response" 3076 o : "Applying 3077 original fragment to 'plain' redirected URI" 3079 o : "Misplaced 3080 text on connection handling in p2" 3082 o : "clarify that 3083 201 doesn't require Location header fields" 3085 o : "relax 3086 requirements on hypertext in 3/4/5xx error responses" 3088 o : "example for 3089 426 response should have a payload" 3091 o : "drop 3092 indirection entries for status codes" 3094 Index 3096 1 3097 100 Continue (status code) 26 3098 100-continue (expect value) 44 3099 101 Switching Protocols (status code) 27 3101 2 3102 200 OK (status code) 27 3103 201 Created (status code) 27 3104 202 Accepted (status code) 28 3105 203 Non-Authoritative Information (status code) 28 3106 204 No Content (status code) 28 3107 205 Reset Content (status code) 29 3109 3 3110 300 Multiple Choices (status code) 31 3111 301 Moved Permanently (status code) 31 3112 302 Found (status code) 32 3113 303 See Other (status code) 32 3114 305 Use Proxy (status code) 33 3115 306 (Unused) (status code) 33 3116 307 Temporary Redirect (status code) 33 3118 4 3119 400 Bad Request (status code) 33 3120 402 Payment Required (status code) 33 3121 403 Forbidden (status code) 33 3122 404 Not Found (status code) 34 3123 405 Method Not Allowed (status code) 34 3124 406 Not Acceptable (status code) 34 3125 408 Request Timeout (status code) 35 3126 409 Conflict (status code) 35 3127 410 Gone (status code) 35 3128 411 Length Required (status code) 36 3129 413 Request Representation Too Large (status code) 36 3130 414 URI Too Long (status code) 36 3131 415 Unsupported Media Type (status code) 36 3132 417 Expectation Failed (status code) 36 3133 426 Upgrade Required (status code) 37 3135 5 3136 500 Internal Server Error (status code) 37 3137 501 Not Implemented (status code) 37 3138 502 Bad Gateway (status code) 37 3139 503 Service Unavailable (status code) 38 3140 504 Gateway Timeout (status code) 38 3141 505 HTTP Version Not Supported (status code) 38 3143 A 3144 Allow header field 42 3146 C 3147 CONNECT method 24 3149 D 3150 Date header field 42 3151 DELETE method 23 3153 E 3154 Expect header field 43 3155 Expect Values 3156 100-continue 44 3158 F 3159 From header field 44 3161 G 3162 GET method 19 3163 Grammar 3164 Allow 42 3165 asctime-date 41 3166 Date 42 3167 date1 40 3168 day 40 3169 day-name 40 3170 day-name-l 40 3171 delta-seconds 47 3172 Expect 43 3173 expect-name 43 3174 expect-param 43 3175 expect-value 43 3176 expectation 43 3177 extension-code 12 3178 From 44 3179 GMT 40 3180 hour 40 3181 HTTP-date 39 3182 Location 45 3183 Max-Forwards 46 3184 method 7 3185 minute 40 3186 month 40 3187 obs-date 40 3188 product 41 3189 product-version 41 3190 reason-phrase 12 3191 Referer 47 3192 Retry-After 47 3193 rfc850-date 41 3194 rfc1123-date 40 3195 second 40 3196 Server 47 3197 status-code 12 3198 time-of-day 40 3199 User-Agent 48 3200 year 40 3202 H 3203 HEAD method 19 3204 Header Fields 3205 Allow 42 3206 Date 42 3207 Expect 43 3208 From 44 3209 Location 45 3210 Max-Forwards 46 3211 Referer 46 3212 Retry-After 47 3213 Server 47 3214 User-Agent 48 3216 I 3217 Idempotent Methods 17 3219 L 3220 Location header field 45 3222 M 3223 Max-Forwards header field 46 3224 Methods 3225 CONNECT 24 3226 DELETE 23 3227 GET 19 3228 HEAD 19 3229 OPTIONS 18 3230 POST 20 3231 PUT 21 3232 TRACE 23 3234 O 3235 OPTIONS method 18 3237 P 3238 POST method 20 3239 PUT method 21 3241 R 3242 Referer header field 46 3243 Retry-After header field 47 3245 S 3246 Safe Methods 17 3247 Server header field 47 3248 Status Codes 3249 100 Continue 26 3250 101 Switching Protocols 27 3251 200 OK 27 3252 201 Created 27 3253 202 Accepted 28 3254 203 Non-Authoritative Information 28 3255 204 No Content 28 3256 205 Reset Content 29 3257 300 Multiple Choices 31 3258 301 Moved Permanently 31 3259 302 Found 32 3260 303 See Other 32 3261 305 Use Proxy 33 3262 306 (Unused) 33 3263 307 Temporary Redirect 33 3264 400 Bad Request 33 3265 402 Payment Required 33 3266 403 Forbidden 33 3267 404 Not Found 34 3268 405 Method Not Allowed 34 3269 406 Not Acceptable 34 3270 408 Request Timeout 35 3271 409 Conflict 35 3272 410 Gone 35 3273 411 Length Required 36 3274 413 Request Representation Too Large 36 3275 414 URI Too Long 36 3276 415 Unsupported Media Type 36 3277 417 Expectation Failed 36 3278 426 Upgrade Required 37 3279 500 Internal Server Error 37 3280 501 Not Implemented 37 3281 502 Bad Gateway 37 3282 503 Service Unavailable 38 3283 504 Gateway Timeout 38 3284 505 HTTP Version Not Supported 38 3286 T 3287 TRACE method 23 3289 U 3290 User-Agent header field 48 3292 Authors' Addresses 3294 Roy T. Fielding (editor) 3295 Adobe Systems Incorporated 3296 345 Park Ave 3297 San Jose, CA 95110 3298 USA 3300 EMail: fielding@gbiv.com 3301 URI: http://roy.gbiv.com/ 3303 Yves Lafon (editor) 3304 World Wide Web Consortium 3305 W3C / ERCIM 3306 2004, rte des Lucioles 3307 Sophia-Antipolis, AM 06902 3308 France 3310 EMail: ylafon@w3.org 3311 URI: http://www.raubacapeu.net/people/yves/ 3312 Julian F. Reschke (editor) 3313 greenbytes GmbH 3314 Hafenweg 16 3315 Muenster, NW 48155 3316 Germany 3318 Phone: +49 251 2807760 3319 Fax: +49 251 2807761 3320 EMail: julian.reschke@greenbytes.de 3321 URI: http://greenbytes.de/tech/webdav/