idnits 2.17.1 draft-ietf-httpbis-p2-semantics-10.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 (July 12, 2010) is 5036 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-10 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-10 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-10 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-10 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-10 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-10 -- 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) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 6 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 Day Software 4 Obsoletes: 2616 (if approved) J. Gettys 5 Updates: 2817 (if approved) Alcatel-Lucent 6 Intended status: Standards Track J. Mogul 7 Expires: January 13, 2011 HP 8 H. Frystyk 9 Microsoft 10 L. Masinter 11 Adobe Systems 12 P. Leach 13 Microsoft 14 T. Berners-Lee 15 W3C/MIT 16 Y. Lafon, Ed. 17 W3C 18 J. Reschke, Ed. 19 greenbytes 20 July 12, 2010 22 HTTP/1.1, part 2: Message Semantics 23 draft-ietf-httpbis-p2-semantics-10 25 Abstract 27 The Hypertext Transfer Protocol (HTTP) is an application-level 28 protocol for distributed, collaborative, hypermedia information 29 systems. HTTP has been in use by the World Wide Web global 30 information initiative since 1990. This document is Part 2 of the 31 seven-part specification that defines the protocol referred to as 32 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines 33 the semantics of HTTP messages as expressed by request methods, 34 request-header fields, response status codes, and response-header 35 fields. 37 Editorial Note (To be removed by RFC Editor) 39 Discussion of this draft should take place on the HTTPBIS working 40 group mailing list (ietf-http-wg@w3.org). The current issues list is 41 at and related 42 documents (including fancy diffs) can be found at 43 . 45 The changes in this draft are summarized in Appendix C.11. 47 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on January 13, 2011. 63 Copyright Notice 65 Copyright (c) 2010 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 This document may contain material from IETF Documents or IETF 79 Contributions published or made publicly available before November 80 10, 2008. The person(s) controlling the copyright in some of this 81 material may not have granted the IETF Trust the right to allow 82 modifications of such material outside the IETF Standards Process. 83 Without obtaining an adequate license from the person(s) controlling 84 the copyright in such materials, this document may not be modified 85 outside the IETF Standards Process, and derivative works of it may 86 not be created outside the IETF Standards Process, except to format 87 it for publication as an RFC or to translate it into languages other 88 than English. 90 Table of Contents 92 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 93 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 94 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 95 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 96 1.2.2. ABNF Rules defined in other Parts of the 97 Specification . . . . . . . . . . . . . . . . . . . . 7 98 2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 99 2.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 8 100 3. Request Header Fields . . . . . . . . . . . . . . . . . . . . 9 101 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 10 102 4.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 12 103 5. Response Header Fields . . . . . . . . . . . . . . . . . . . . 12 104 6. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 105 6.1. Identifying the Resource Associated with a 106 Representation . . . . . . . . . . . . . . . . . . . . . . 13 107 7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 14 108 7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 14 109 7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 14 110 7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 14 111 7.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 14 112 7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 113 7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 114 7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 115 7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 116 7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 117 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 118 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 20 119 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 20 120 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 20 121 8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 20 122 8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 20 123 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 21 124 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 21 125 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 21 126 8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 22 127 8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 22 128 8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 22 129 8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 23 130 8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 23 131 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 23 132 8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 23 133 8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 24 134 8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 24 135 8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 25 136 8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 25 137 8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 26 138 8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 26 139 8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 26 140 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 26 141 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 27 142 8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 27 143 8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 27 144 8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 27 145 8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 27 146 8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 27 147 8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 28 148 8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 28 149 8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 28 150 8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 28 151 8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 29 152 8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 29 153 8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 29 154 8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 29 155 8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 30 156 8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 30 157 8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 30 158 8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 30 159 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 30 160 8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 31 161 8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 31 162 8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 31 163 8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 31 164 8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 31 165 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 31 166 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 32 167 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 32 168 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 32 169 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 170 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 34 171 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 35 172 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 35 173 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 36 174 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 37 175 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 37 176 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 177 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 38 178 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 38 179 10.3. Message Header Registration . . . . . . . . . . . . . . . 39 180 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 181 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 40 182 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 41 183 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 42 184 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 185 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 186 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42 187 13.2. Informative References . . . . . . . . . . . . . . . . . . 43 188 Appendix A. Compatibility with Previous Versions . . . . . . . . 43 189 A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 43 190 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 44 191 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 45 192 Appendix C. Change Log (to be removed by RFC Editor before 193 publication) . . . . . . . . . . . . . . . . . . . . 48 194 C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 48 195 C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 48 196 C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 49 197 C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 49 198 C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 50 199 C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 50 200 C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 51 201 C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 51 202 C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 51 203 C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 52 204 C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 52 205 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 207 1. Introduction 209 This document defines HTTP/1.1 request and response semantics. Each 210 HTTP message, as defined in [Part1], is in the form of either a 211 request or a response. An HTTP server listens on a connection for 212 HTTP requests and responds to each request, in the order received on 213 that connection, with one or more HTTP response messages. This 214 document defines the commonly agreed upon semantics of the HTTP 215 uniform interface, the intentions defined by each request method, and 216 the various response messages that might be expected as a result of 217 applying that method for the requested resource. 219 This document is currently disorganized in order to minimize the 220 changes between drafts and enable reviewers to see the smaller errata 221 changes. The next draft will reorganize the sections to better 222 reflect the content. In particular, the sections will be ordered 223 according to the typical processing of an HTTP request message (after 224 message parsing): resource mapping, general header fields, methods, 225 request modifiers, response status, and resource metadata. The 226 current mess reflects how widely dispersed these topics and 227 associated requirements had become in [RFC2616]. 229 1.1. Requirements 231 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 232 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 233 document are to be interpreted as described in [RFC2119]. 235 An implementation is not compliant if it fails to satisfy one or more 236 of the "MUST" or "REQUIRED" level requirements for the protocols it 237 implements. An implementation that satisfies all the "MUST" or 238 "REQUIRED" level and all the "SHOULD" level requirements for its 239 protocols is said to be "unconditionally compliant"; one that 240 satisfies all the "MUST" level requirements but not all the "SHOULD" 241 level requirements for its protocols is said to be "conditionally 242 compliant". 244 1.2. Syntax Notation 246 This specification uses the ABNF syntax defined in Section 1.2 of 247 [Part1] (which extends the syntax defined in [RFC5234] with a list 248 rule). Appendix B shows the collected ABNF, with the list rule 249 expanded. 251 The following core rules are included by reference, as defined in 252 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 253 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 254 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 255 sequence of data), SP (space), VCHAR (any visible USASCII character), 256 and WSP (whitespace). 258 1.2.1. Core Rules 260 The core rules below are defined in Section 1.2.2 of [Part1]: 262 quoted-string = 263 token = 264 OWS = 265 RWS = 266 obs-text = 268 1.2.2. ABNF Rules defined in other Parts of the Specification 270 The ABNF rules below are defined in other parts: 272 absolute-URI = 273 comment = 274 Host = 275 HTTP-date = 276 partial-URI = 277 product = 278 TE = 279 URI-reference = 281 Accept = 282 Accept-Charset = 283 284 Accept-Encoding = 285 286 Accept-Language = 287 289 ETag = 290 If-Match = 291 If-Modified-Since = 292 293 If-None-Match = 294 If-Unmodified-Since = 295 297 Accept-Ranges = 298 If-Range = 299 Range = 300 Age = 301 Vary = 303 Authorization = 304 Proxy-Authenticate = 305 306 Proxy-Authorization = 307 308 WWW-Authenticate = 309 311 2. Method 313 The Method token indicates the method to be performed on the resource 314 identified by the Effective Request URI (Section 4.3 of [Part1]). 315 The method is case-sensitive. 317 Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 7.2 318 / %x47.45.54 ; "GET", Section 7.3 319 / %x48.45.41.44 ; "HEAD", Section 7.4 320 / %x50.4F.53.54 ; "POST", Section 7.5 321 / %x50.55.54 ; "PUT", Section 7.6 322 / %x44.45.4C.45.54.45 ; "DELETE", Section 7.7 323 / %x54.52.41.43.45 ; "TRACE", Section 7.8 324 / %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 7.9 325 / extension-method 326 extension-method = token 328 The list of methods allowed by a resource can be specified in an 329 Allow header field (Section 9.1). The return code of the response 330 always notifies the client whether a method is currently allowed on a 331 resource, since the set of allowed methods can change dynamically. 332 An origin server SHOULD return the status code 405 (Method Not 333 Allowed) if the method is known by the origin server but not allowed 334 for the requested resource, and 501 (Not Implemented) if the method 335 is unrecognized or not implemented by the origin server. The methods 336 GET and HEAD MUST be supported by all general-purpose servers. All 337 other methods are OPTIONAL; however, if the above methods are 338 implemented, they MUST be implemented with the same semantics as 339 those specified in Section 7. 341 2.1. Method Registry 343 The HTTP Method Registry defines the name space for the Method token 344 in the Request line of an HTTP request. 346 Registrations MUST include the following fields: 348 o Method Name (see Section 2) 350 o Safe ("yes" or "no", see Section 7.1.1) 352 o Pointer to specification text 354 Values to be added to this name space are subject to IETF review 355 ([RFC5226], Section 4.1). 357 The registry itself is maintained at 358 . 360 3. Request Header Fields 362 The request-header fields allow the client to pass additional 363 information about the request, and about the client itself, to the 364 server. These fields act as request modifiers, with semantics 365 equivalent to the parameters on a programming language method 366 invocation. 368 request-header = Accept ; [Part3], Section 5.1 369 / Accept-Charset ; [Part3], Section 5.2 370 / Accept-Encoding ; [Part3], Section 5.3 371 / Accept-Language ; [Part3], Section 5.4 372 / Authorization ; [Part7], Section 3.1 373 / Expect ; Section 9.2 374 / From ; Section 9.3 375 / Host ; [Part1], Section 9.4 376 / If-Match ; [Part4], Section 6.2 377 / If-Modified-Since ; [Part4], Section 6.3 378 / If-None-Match ; [Part4], Section 6.4 379 / If-Range ; [Part5], Section 5.3 380 / If-Unmodified-Since ; [Part4], Section 6.5 381 / Max-Forwards ; Section 9.5 382 / Proxy-Authorization ; [Part7], Section 3.3 383 / Range ; [Part5], Section 5.4 384 / Referer ; Section 9.6 385 / TE ; [Part1], Section 9.5 386 / User-Agent ; Section 9.9 388 Request-header field names can be extended reliably only in 389 combination with a change in the protocol version. However, new or 390 experimental header fields MAY be given the semantics of request- 391 header fields if all parties in the communication recognize them to 392 be request-header fields. Unrecognized header fields are treated as 393 entity-header fields. 395 4. Status Code and Reason Phrase 397 The Status-Code element is a 3-digit integer result code of the 398 attempt to understand and satisfy the request. The status codes 399 listed below are defined in Section 8, Section 3 of [Part4], Section 400 3 of [Part5], and Section 2 of [Part7]. 402 The Reason-Phrase is intended to give a short textual description of 403 the Status-Code. The Status-Code is intended for use by automata and 404 the Reason-Phrase is intended for the human user. The client is not 405 required to examine or display the Reason-Phrase. 407 The individual values of the numeric status codes defined for 408 HTTP/1.1, and an example set of corresponding Reason-Phrase values, 409 are presented below. The reason phrases listed here are only 410 recommendations -- they MAY be replaced by local equivalents without 411 affecting the protocol. 413 Status-Code = 414 "100" ; Section 8.1.1: Continue 415 / "101" ; Section 8.1.2: Switching Protocols 416 / "200" ; Section 8.2.1: OK 417 / "201" ; Section 8.2.2: Created 418 / "202" ; Section 8.2.3: Accepted 419 / "203" ; Section 8.2.4: Non-Authoritative Information 420 / "204" ; Section 8.2.5: No Content 421 / "205" ; Section 8.2.6: Reset Content 422 / "206" ; [Part5], Section 3.1: Partial Content 423 / "300" ; Section 8.3.1: Multiple Choices 424 / "301" ; Section 8.3.2: Moved Permanently 425 / "302" ; Section 8.3.3: Found 426 / "303" ; Section 8.3.4: See Other 427 / "304" ; [Part4], Section 3.1: Not Modified 428 / "305" ; Section 8.3.6: Use Proxy 429 / "307" ; Section 8.3.8: Temporary Redirect 430 / "400" ; Section 8.4.1: Bad Request 431 / "401" ; [Part7], Section 2.1: Unauthorized 432 / "402" ; Section 8.4.3: Payment Required 433 / "403" ; Section 8.4.4: Forbidden 434 / "404" ; Section 8.4.5: Not Found 435 / "405" ; Section 8.4.6: Method Not Allowed 436 / "406" ; Section 8.4.7: Not Acceptable 437 / "407" ; [Part7], Section 2.2: Proxy Authentication Required 438 / "408" ; Section 8.4.9: Request Time-out 439 / "409" ; Section 8.4.10: Conflict 440 / "410" ; Section 8.4.11: Gone 441 / "411" ; Section 8.4.12: Length Required 442 / "412" ; [Part4], Section 3.2: Precondition Failed 443 / "413" ; Section 8.4.14: Request Entity Too Large 444 / "414" ; Section 8.4.15: URI Too Long 445 / "415" ; Section 8.4.16: Unsupported Media Type 446 / "416" ; [Part5], Section 3.2: Requested range not satisfiable 447 / "417" ; Section 8.4.18: Expectation Failed 448 / "500" ; Section 8.5.1: Internal Server Error 449 / "501" ; Section 8.5.2: Not Implemented 450 / "502" ; Section 8.5.3: Bad Gateway 451 / "503" ; Section 8.5.4: Service Unavailable 452 / "504" ; Section 8.5.5: Gateway Time-out 453 / "505" ; Section 8.5.6: HTTP Version not supported 454 / extension-code 456 extension-code = 3DIGIT 457 Reason-Phrase = *( WSP / VCHAR / obs-text ) 459 HTTP status codes are extensible. HTTP applications are not required 460 to understand the meaning of all registered status codes, though such 461 understanding is obviously desirable. However, applications MUST 462 understand the class of any status code, as indicated by the first 463 digit, and treat any unrecognized response as being equivalent to the 464 x00 status code of that class, with the exception that an 465 unrecognized response MUST NOT be cached. For example, if an 466 unrecognized status code of 431 is received by the client, it can 467 safely assume that there was something wrong with its request and 468 treat the response as if it had received a 400 status code. In such 469 cases, user agents SHOULD present to the user the entity returned 470 with the response, since that entity is likely to include human- 471 readable information which will explain the unusual status. 473 4.1. Status Code Registry 475 The HTTP Status Code Registry defines the name space for the Status- 476 Code token in the Status line of an HTTP response. 478 Values to be added to this name space are subject to IETF review 479 ([RFC5226], Section 4.1). 481 The registry itself is maintained at 482 . 484 5. Response Header Fields 486 The response-header fields allow the server to pass additional 487 information about the response which cannot be placed in the Status- 488 Line. These header fields give information about the server and 489 about further access to the resource identified by the Effective 490 Request URI (Section 4.3 of [Part1]). 492 response-header = Accept-Ranges ; [Part5], Section 5.1 493 / Age ; [Part6], Section 3.1 494 / Allow ; Section 9.1 495 / ETag ; [Part4], Section 6.1 496 / Location ; Section 9.4 497 / Proxy-Authenticate ; [Part7], Section 3.2 498 / Retry-After ; Section 9.7 499 / Server ; Section 9.8 500 / Vary ; [Part6], Section 3.5 501 / WWW-Authenticate ; [Part7], Section 3.4 503 Response-header field names can be extended reliably only in 504 combination with a change in the protocol version. However, new or 505 experimental header fields MAY be given the semantics of response- 506 header fields if all parties in the communication recognize them to 507 be response-header fields. Unrecognized header fields are treated as 508 entity-header fields. 510 6. Entity 512 Request and Response messages MAY transfer an entity if not otherwise 513 restricted by the request method or response status code. An entity 514 consists of entity-header fields and an entity-body, although some 515 responses will only include the entity-headers. HTTP entity-body and 516 entity-header fields are defined in [Part3]. 518 An entity-body is only present in a message when a message-body is 519 present, as described in Section 3.3 of [Part1]. The entity-body is 520 obtained from the message-body by decoding any Transfer-Encoding that 521 might have been applied to ensure safe and proper transfer of the 522 message. 524 6.1. Identifying the Resource Associated with a Representation 526 It is sometimes necessary to determine the identity of the resource 527 associated with a representation. 529 An HTTP request representation, when present, is always associated 530 with an anonymous (i.e., unidentified) resource. 532 In the common case, an HTTP response is a representation of the 533 resource located at the Effective Request URI (see Section 4.3 of 534 [Part1]). However, this is not always the case. To determine the 535 URI of the resource a response is associated with, the following 536 rules are used (with the first applicable one being selected): 538 1. If the response status code is 200 or 203 and the request method 539 was GET, the response is a representation of the resource at the 540 Effective Request URI. 542 2. If the response status is 204, 206, or 304 and the request method 543 was GET or HEAD, the response is a partial representation of the 544 resource at the Effective Request URI (see Section 2.8 of 545 [Part6]). 547 3. If the response has a Content-Location header, and that URI is 548 the same as the Effective Request URI, the response is a 549 representation of the resource at the Effective Request URI. 551 4. If the response has a Content-Location header, and that URI is 552 not the same as the Effective Request URI, the response asserts 553 that it is a representation of the resource at the Content- 554 Location URI (but it may not be). 556 5. Otherwise, the response is a representation of an anonymous 557 (i.e., unidentified) resource. 559 [[TODO-req-uri: The comparison function is going to have to be 560 defined somewhere, because we already need to compare URIs for things 561 like cache invalidation.]] 563 7. Method Definitions 565 The set of common methods for HTTP/1.1 is defined below. Although 566 this set can be expanded, additional methods cannot be assumed to 567 share the same semantics for separately extended clients and servers. 569 7.1. Safe and Idempotent Methods 571 7.1.1. Safe Methods 573 Implementors should be aware that the software represents the user in 574 their interactions over the Internet, and should be careful to allow 575 the user to be aware of any actions they might take which may have an 576 unexpected significance to themselves or others. 578 In particular, the convention has been established that the GET, 579 HEAD, OPTIONS, and TRACE methods SHOULD NOT have the significance of 580 taking an action other than retrieval. These methods ought to be 581 considered "safe". This allows user agents to represent other 582 methods, such as POST, PUT and DELETE, in a special way, so that the 583 user is made aware of the fact that a possibly unsafe action is being 584 requested. 586 Naturally, it is not possible to ensure that the server does not 587 generate side-effects as a result of performing a GET request; in 588 fact, some dynamic resources consider that a feature. The important 589 distinction here is that the user did not request the side-effects, 590 so therefore cannot be held accountable for them. 592 7.1.2. Idempotent Methods 594 Methods can also have the property of "idempotence" in that, aside 595 from error or expiration issues, the intended effect of multiple 596 identical requests is the same as for a single request. The methods 597 PUT, DELETE, and all safe methods are idempotent. It is important to 598 note that idempotence refers only to changes requested by the client: 599 a server is free to change its state due to multiple requests for the 600 purpose of tracking those requests, versioning of results, etc. 602 7.2. OPTIONS 604 The OPTIONS method represents a request for information about the 605 communication options available on the request/response chain 606 identified by the Effective Request URI. This method allows the 607 client to determine the options and/or requirements associated with a 608 resource, or the capabilities of a server, without implying a 609 resource action or initiating a resource retrieval. 611 Responses to this method are not cacheable. 613 If the OPTIONS request includes an entity-body (as indicated by the 614 presence of Content-Length or Transfer-Encoding), then the media type 615 MUST be indicated by a Content-Type field. Although this 616 specification does not define any use for such a body, future 617 extensions to HTTP might use the OPTIONS body to make more detailed 618 queries on the server. 620 If the request-target is an asterisk ("*"), the OPTIONS request is 621 intended to apply to the server in general rather than to a specific 622 resource. Since a server's communication options typically depend on 623 the resource, the "*" request is only useful as a "ping" or "no-op" 624 type of method; it does nothing beyond allowing the client to test 625 the capabilities of the server. For example, this can be used to 626 test a proxy for HTTP/1.1 compliance (or lack thereof). 628 If the request-target is not an asterisk, the OPTIONS request applies 629 only to the options that are available when communicating with that 630 resource. 632 A 200 response SHOULD include any header fields that indicate 633 optional features implemented by the server and applicable to that 634 resource (e.g., Allow), possibly including extensions not defined by 635 this specification. The response body, if any, SHOULD also include 636 information about the communication options. The format for such a 637 body is not defined by this specification, but might be defined by 638 future extensions to HTTP. Content negotiation MAY be used to select 639 the appropriate response format. If no response body is included, 640 the response MUST include a Content-Length field with a field-value 641 of "0". 643 The Max-Forwards request-header field MAY be used to target a 644 specific proxy in the request chain. When a proxy receives an 645 OPTIONS request on an absolute-URI for which request forwarding is 646 permitted, the proxy MUST check for a Max-Forwards field. If the 647 Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward 648 the message; instead, the proxy SHOULD respond with its own 649 communication options. If the Max-Forwards field-value is an integer 650 greater than zero, the proxy MUST decrement the field-value when it 651 forwards the request. If no Max-Forwards field is present in the 652 request, then the forwarded request MUST NOT include a Max-Forwards 653 field. 655 7.3. GET 657 The GET method means retrieve whatever information (in the form of an 658 entity) currently corresponds to the resource identified by the 659 Effective Request URI. 661 If the Effective Request URI identifies a data-producing process, it 662 is the produced data which shall be returned as the entity in the 663 response and not the source text of the process, unless that text 664 happens to be the output of the process. 666 The semantics of the GET method change to a "conditional GET" if the 667 request message includes an If-Modified-Since, If-Unmodified-Since, 668 If-Match, If-None-Match, or If-Range header field. A conditional GET 669 method requests that the entity be transferred only under the 670 circumstances described by the conditional header field(s). The 671 conditional GET method is intended to reduce unnecessary network 672 usage by allowing cached entities to be refreshed without requiring 673 multiple requests or transferring data already held by the client. 675 The semantics of the GET method change to a "partial GET" if the 676 request message includes a Range header field. A partial GET 677 requests that only part of the entity be transferred, as described in 678 Section 5.4 of [Part5]. The partial GET method is intended to reduce 679 unnecessary network usage by allowing partially-retrieved entities to 680 be completed without transferring data already held by the client. 682 The response to a GET request is cacheable if and only if it meets 683 the requirements for HTTP caching described in [Part6]. 685 See Section 11.2 for security considerations when used for forms. 687 7.4. HEAD 689 The HEAD method is identical to GET except that the server MUST NOT 690 return a message-body in the response. The metainformation contained 691 in the HTTP headers in response to a HEAD request SHOULD be identical 692 to the information sent in response to a GET request. This method 693 can be used for obtaining metainformation about the entity implied by 694 the request without transferring the entity-body itself. This method 695 is often used for testing hypertext links for validity, 696 accessibility, and recent modification. 698 The response to a HEAD request MAY be cacheable in the sense that the 699 information contained in the response MAY be used to update a 700 previously cached entity from that resource. If the new field values 701 indicate that the cached entity differs from the current entity (as 702 would be indicated by a change in Content-Length, Content-MD5, ETag 703 or Last-Modified), then the cache MUST treat the cache entry as 704 stale. 706 7.5. POST 708 The POST method is used to request that the origin server accept the 709 entity enclosed in the request as data to be processed by the 710 resource identified by the Effective Request URI. POST is designed 711 to allow a uniform method to cover the following functions: 713 o Annotation of existing resources; 715 o Posting a message to a bulletin board, newsgroup, mailing list, or 716 similar group of articles; 718 o Providing a block of data, such as the result of submitting a 719 form, to a data-handling process; 721 o Extending a database through an append operation. 723 The actual function performed by the POST method is determined by the 724 server and is usually dependent on the Effective Request URI. 726 The action performed by the POST method might not result in a 727 resource that can be identified by a URI. In this case, either 200 728 (OK) or 204 (No Content) is the appropriate response status, 729 depending on whether or not the response includes an entity that 730 describes the result. 732 If a resource has been created on the origin server, the response 733 SHOULD be 201 (Created) and contain an entity which describes the 734 status of the request and refers to the new resource, and a Location 735 header (see Section 9.4). 737 Responses to this method are not cacheable, unless the response 738 includes appropriate Cache-Control or Expires header fields. 739 However, the 303 (See Other) response can be used to direct the user 740 agent to retrieve a cacheable resource. 742 7.6. PUT 744 The PUT method requests that the enclosed entity be stored at the 745 Effective Request URI. If the Effective Request URI refers to an 746 already existing resource, the enclosed entity SHOULD be considered 747 as a modified version of the one residing on the origin server. 748 Otherwise, if the Effective Request URI does not point to an existing 749 resource, and that URI is capable of being defined as a new resource 750 by the requesting user agent, the origin server can create the 751 resource with that URI. 753 If a new resource is created at the Effective Request URI, the origin 754 server MUST inform the user agent via the 201 (Created) response. If 755 an existing resource is modified, either the 200 (OK) or 204 (No 756 Content) response codes SHOULD be sent to indicate successful 757 completion of the request. 759 If the resource could not be created or modified with the Effective 760 Request URI, an appropriate error response SHOULD be given that 761 reflects the nature of the problem. The recipient of the entity MUST 762 NOT ignore any Content-* headers (headers starting with the prefix 763 "Content-") that it does not understand or implement and MUST return 764 a 501 (Not Implemented) response in such cases. 766 If the request passes through a cache and the Effective Request URI 767 identifies one or more currently cached entities, those entries 768 SHOULD be treated as stale. Responses to this method are not 769 cacheable. 771 The fundamental difference between the POST and PUT requests is 772 reflected in the different meaning of the Effective Request URI. The 773 URI in a POST request identifies the resource that will handle the 774 enclosed entity. That resource might be a data-accepting process, a 775 gateway to some other protocol, or a separate entity that accepts 776 annotations. In contrast, the URI in a PUT request identifies the 777 entity enclosed with the request -- the user agent knows what URI is 778 intended and the server MUST NOT attempt to apply the request to some 779 other resource. If the server desires that the request be applied to 780 a different URI, it MUST send a 301 (Moved Permanently) response; the 781 user agent MAY then make its own decision regarding whether or not to 782 redirect the request. 784 A single resource MAY be identified by many different URIs. For 785 example, an article might have a URI for identifying "the current 786 version" which is separate from the URI identifying each particular 787 version. In this case, a PUT request on a general URI might result 788 in several other URIs being defined by the origin server. 790 HTTP/1.1 does not define how a PUT method affects the state of an 791 origin server. 793 Unless otherwise specified for a particular entity-header, the 794 entity-headers in the PUT request SHOULD be applied to the resource 795 created or modified by the PUT. 797 7.7. DELETE 799 The DELETE method requests that the origin server delete the resource 800 identified by the Effective Request URI. This method MAY be 801 overridden by human intervention (or other means) on the origin 802 server. The client cannot be guaranteed that the operation has been 803 carried out, even if the status code returned from the origin server 804 indicates that the action has been completed successfully. However, 805 the server SHOULD NOT indicate success unless, at the time the 806 response is given, it intends to delete the resource or move it to an 807 inaccessible location. 809 A successful response SHOULD be 200 (OK) if the response includes an 810 entity describing the status, 202 (Accepted) if the action has not 811 yet been enacted, or 204 (No Content) if the action has been enacted 812 but the response does not include an entity. 814 If the request passes through a cache and the Effective Request URI 815 identifies one or more currently cached entities, those entries 816 SHOULD be treated as stale. Responses to this method are not 817 cacheable. 819 7.8. TRACE 821 The TRACE method is used to invoke a remote, application-layer loop- 822 back of the request message. The final recipient of the request 823 SHOULD reflect the message received back to the client as the entity- 824 body of a 200 (OK) response. The final recipient is either the 825 origin server or the first proxy or gateway to receive a Max-Forwards 826 value of zero (0) in the request (see Section 9.5). A TRACE request 827 MUST NOT include an entity. 829 TRACE allows the client to see what is being received at the other 830 end of the request chain and use that data for testing or diagnostic 831 information. The value of the Via header field (Section 9.9 of 832 [Part1]) is of particular interest, since it acts as a trace of the 833 request chain. Use of the Max-Forwards header field allows the 834 client to limit the length of the request chain, which is useful for 835 testing a chain of proxies forwarding messages in an infinite loop. 837 If the request is valid, the response SHOULD contain the entire 838 request message in the entity-body, with a Content-Type of "message/ 839 http" (see Section 10.3.1 of [Part1]). Responses to this method MUST 840 NOT be cached. 842 7.9. CONNECT 844 This specification reserves the method name CONNECT for use with a 845 proxy that can dynamically switch to being a tunnel (e.g., SSL 846 tunneling [RFC2817]). 848 8. Status Code Definitions 850 Each Status-Code is described below, including any metainformation 851 required in the response. 853 8.1. Informational 1xx 855 This class of status code indicates a provisional response, 856 consisting only of the Status-Line and optional headers, and is 857 terminated by an empty line. There are no required headers for this 858 class of status code. Since HTTP/1.0 did not define any 1xx status 859 codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client 860 except under experimental conditions. 862 A client MUST be prepared to accept one or more 1xx status responses 863 prior to a regular response, even if the client does not expect a 100 864 (Continue) status message. Unexpected 1xx status responses MAY be 865 ignored by a user agent. 867 Proxies MUST forward 1xx responses, unless the connection between the 868 proxy and its client has been closed, or unless the proxy itself 869 requested the generation of the 1xx response. (For example, if a 870 proxy adds a "Expect: 100-continue" field when it forwards a request, 871 then it need not forward the corresponding 100 (Continue) 872 response(s).) 874 8.1.1. 100 Continue 876 The client SHOULD continue with its request. This interim response 877 is used to inform the client that the initial part of the request has 878 been received and has not yet been rejected by the server. The 879 client SHOULD continue by sending the remainder of the request or, if 880 the request has already been completed, ignore this response. The 881 server MUST send a final response after the request has been 882 completed. See Section 7.2.3 of [Part1] for detailed discussion of 883 the use and handling of this status code. 885 8.1.2. 101 Switching Protocols 887 The server understands and is willing to comply with the client's 888 request, via the Upgrade message header field (Section 9.8 of 889 [Part1]), for a change in the application protocol being used on this 890 connection. The server will switch protocols to those defined by the 891 response's Upgrade header field immediately after the empty line 892 which terminates the 101 response. 894 The protocol SHOULD be switched only when it is advantageous to do 895 so. For example, switching to a newer version of HTTP is 896 advantageous over older versions, and switching to a real-time, 897 synchronous protocol might be advantageous when delivering resources 898 that use such features. 900 8.2. Successful 2xx 902 This class of status code indicates that the client's request was 903 successfully received, understood, and accepted. 905 8.2.1. 200 OK 907 The request has succeeded. The information returned with the 908 response is dependent on the method used in the request, for example: 910 GET an entity corresponding to the requested resource is sent in the 911 response; 913 HEAD the entity-header fields corresponding to the requested 914 resource are sent in the response without any message-body; 916 POST an entity describing or containing the result of the action; 918 TRACE an entity containing the request message as received by the 919 end server. 921 8.2.2. 201 Created 923 The request has been fulfilled and has resulted in a new resource 924 being created. The newly created resource can be referenced by the 925 URI(s) returned in the entity of the response, with the most specific 926 URI for the resource given by a Location header field. The response 927 SHOULD include an entity containing a list of resource 928 characteristics and location(s) from which the user or user agent can 929 choose the one most appropriate. The entity format is specified by 930 the media type given in the Content-Type header field. The origin 931 server MUST create the resource before returning the 201 status code. 932 If the action cannot be carried out immediately, the server SHOULD 933 respond with 202 (Accepted) response instead. 935 A 201 response MAY contain an ETag response header field indicating 936 the current value of the entity tag for the requested variant just 937 created, see Section 6.1 of [Part4]. 939 8.2.3. 202 Accepted 941 The request has been accepted for processing, but the processing has 942 not been completed. The request might or might not eventually be 943 acted upon, as it might be disallowed when processing actually takes 944 place. There is no facility for re-sending a status code from an 945 asynchronous operation such as this. 947 The 202 response is intentionally non-committal. Its purpose is to 948 allow a server to accept a request for some other process (perhaps a 949 batch-oriented process that is only run once per day) without 950 requiring that the user agent's connection to the server persist 951 until the process is completed. The entity returned with this 952 response SHOULD include an indication of the request's current status 953 and either a pointer to a status monitor or some estimate of when the 954 user can expect the request to be fulfilled. 956 8.2.4. 203 Non-Authoritative Information 958 The returned metainformation in the entity-header is not the 959 definitive set as available from the origin server, but is gathered 960 from a local or a third-party copy. The set presented MAY be a 961 subset or superset of the original version. For example, including 962 local annotation information about the resource might result in a 963 superset of the metainformation known by the origin server. Use of 964 this response code is not required and is only appropriate when the 965 response would otherwise be 200 (OK). 967 8.2.5. 204 No Content 969 The server has fulfilled the request but does not need to return an 970 entity-body, and might want to return updated metainformation. The 971 response MAY include new or updated metainformation in the form of 972 entity-headers, which if present SHOULD be associated with the 973 requested variant. 975 If the client is a user agent, it SHOULD NOT change its document view 976 from that which caused the request to be sent. This response is 977 primarily intended to allow input for actions to take place without 978 causing a change to the user agent's active document view, although 979 any new or updated metainformation SHOULD be applied to the document 980 currently in the user agent's active view. 982 The 204 response MUST NOT include a message-body, and thus is always 983 terminated by the first empty line after the header fields. 985 8.2.6. 205 Reset Content 987 The server has fulfilled the request and the user agent SHOULD reset 988 the document view which caused the request to be sent. This response 989 is primarily intended to allow input for actions to take place via 990 user input, followed by a clearing of the form in which the input is 991 given so that the user can easily initiate another input action. The 992 response MUST NOT include an entity. 994 8.2.7. 206 Partial Content 996 The server has fulfilled the partial GET request for the resource and 997 the enclosed entity is a partial representation as defined in Section 998 3.1 of [Part5]. 1000 8.3. Redirection 3xx 1002 This class of status code indicates that further action needs to be 1003 taken by the user agent in order to fulfill the request. The action 1004 required MAY be carried out by the user agent without interaction 1005 with the user if and only if the method used in the second request is 1006 known to be "safe", as defined in Section 7.1.1. A client SHOULD 1007 detect infinite redirection loops, since such loops generate network 1008 traffic for each redirection. 1010 Note: An earlier version of this specification recommended a 1011 maximum of five redirections ([RFC2068], Section 10.3). Content 1012 developers should be aware that there might be clients that 1013 implement such a fixed limitation. 1015 8.3.1. 300 Multiple Choices 1017 The requested resource corresponds to any one of a set of 1018 representations, each with its own specific location, and agent- 1019 driven negotiation information (Section 4 of [Part3]) is being 1020 provided so that the user (or user agent) can select a preferred 1021 representation and redirect its request to that location. 1023 Unless it was a HEAD request, the response SHOULD include an entity 1024 containing a list of resource characteristics and location(s) from 1025 which the user or user agent can choose the one most appropriate. 1026 The entity format is specified by the media type given in the 1027 Content-Type header field. Depending upon the format and the 1028 capabilities of the user agent, selection of the most appropriate 1029 choice MAY be performed automatically. However, this specification 1030 does not define any standard for such automatic selection. 1032 If the server has a preferred choice of representation, it SHOULD 1033 include the specific URI for that representation in the Location 1034 field; user agents MAY use the Location field value for automatic 1035 redirection. This response is cacheable unless indicated otherwise. 1037 8.3.2. 301 Moved Permanently 1039 The requested resource has been assigned a new permanent URI and any 1040 future references to this resource SHOULD use one of the returned 1041 URIs. Clients with link editing capabilities ought to automatically 1042 re-link references to the Effective Request URI to one or more of the 1043 new references returned by the server, where possible. This response 1044 is cacheable unless indicated otherwise. 1046 The new permanent URI SHOULD be given by the Location field in the 1047 response. Unless the request method was HEAD, the entity of the 1048 response SHOULD contain a short hypertext note with a hyperlink to 1049 the new URI(s). 1051 If the 301 status code is received in response to a request method 1052 that is known to be "safe", as defined in Section 7.1.1, then the 1053 request MAY be automatically redirected by the user agent without 1054 confirmation. Otherwise, the user agent MUST NOT automatically 1055 redirect the request unless it can be confirmed by the user, since 1056 this might change the conditions under which the request was issued. 1058 Note: When automatically redirecting a POST request after 1059 receiving a 301 status code, some existing HTTP/1.0 user agents 1060 will erroneously change it into a GET request. 1062 8.3.3. 302 Found 1064 The requested resource resides temporarily under a different URI. 1065 Since the redirection might be altered on occasion, the client SHOULD 1066 continue to use the Effectice Request URI for future requests. This 1067 response is only cacheable if indicated by a Cache-Control or Expires 1068 header field. 1070 The temporary URI SHOULD be given by the Location field in the 1071 response. Unless the request method was HEAD, the entity of the 1072 response SHOULD contain a short hypertext note with a hyperlink to 1073 the new URI(s). 1075 If the 302 status code is received in response to a request method 1076 that is known to be "safe", as defined in Section 7.1.1, then the 1077 request MAY be automatically redirected by the user agent without 1078 confirmation. Otherwise, the user agent MUST NOT automatically 1079 redirect the request unless it can be confirmed by the user, since 1080 this might change the conditions under which the request was issued. 1082 Note: HTTP/1.0 ([RFC1945], Section 9.3) and the first version of 1083 HTTP/1.1 ([RFC2068], Section 10.3.3) specify that the client is 1084 not allowed to change the method on the redirected request. 1085 However, most existing user agent implementations treat 302 as if 1086 it were a 303 response, performing a GET on the Location field- 1087 value regardless of the original request method. Therefore, a 1088 previous version of this specification ([RFC2616], Section 10.3.3) 1089 has added the status codes 303 and 307 for servers that wish to 1090 make unambiguously clear which kind of reaction is expected of the 1091 client. 1093 8.3.4. 303 See Other 1095 The server directs the user agent to a different resource, indicated 1096 by a URI in the Location header field, that provides an indirect 1097 response to the original request. The user agent MAY perform a GET 1098 request on the URI in the Location field in order to obtain a 1099 representation corresponding to the response, be redirected again, or 1100 end with an error status. The Location URI is not a substitute 1101 reference for the originally requested resource. 1103 The 303 status is generally applicable to any HTTP method. It is 1104 primarily used to allow the output of a POST action to redirect the 1105 user agent to a selected resource, since doing so provides the 1106 information corresponding to the POST response in a form that can be 1107 separately identified, bookmarked, and cached independent of the 1108 original request. 1110 A 303 response to a GET request indicates that the requested resource 1111 does not have a representation of its own that can be transferred by 1112 the server over HTTP. The Location URI indicates a resource that is 1113 descriptive of the requested resource such that the follow-on 1114 representation may be useful without implying that it adequately 1115 represents the previously requested resource. Note that answers to 1116 the questions of what can be represented, what representations are 1117 adequate, and what might be a useful description are outside the 1118 scope of HTTP and thus entirely determined by the URI owner(s). 1120 A 303 response SHOULD NOT be cached unless it is indicated as 1121 cacheable by Cache-Control or Expires header fields. Except for 1122 responses to a HEAD request, the entity of a 303 response SHOULD 1123 contain a short hypertext note with a hyperlink to the Location URI. 1125 8.3.5. 304 Not Modified 1127 The response to the request has not been modified since the 1128 conditions indicated by the client's conditional GET request, as 1129 defined in Section 3.1 of [Part4]. 1131 8.3.6. 305 Use Proxy 1133 The 305 status was defined in a previous version of this 1134 specification (see Appendix A.2), and is now deprecated. 1136 8.3.7. 306 (Unused) 1138 The 306 status code was used in a previous version of the 1139 specification, is no longer used, and the code is reserved. 1141 8.3.8. 307 Temporary Redirect 1143 The requested resource resides temporarily under a different URI. 1144 Since the redirection MAY be altered on occasion, the client SHOULD 1145 continue to use the Effective Request URI for future requests. This 1146 response is only cacheable if indicated by a Cache-Control or Expires 1147 header field. 1149 The temporary URI SHOULD be given by the Location field in the 1150 response. Unless the request method was HEAD, the entity of the 1151 response SHOULD contain a short hypertext note with a hyperlink to 1152 the new URI(s) , since many pre-HTTP/1.1 user agents do not 1153 understand the 307 status. Therefore, the note SHOULD contain the 1154 information necessary for a user to repeat the original request on 1155 the new URI. 1157 If the 307 status code is received in response to a request method 1158 that is known to be "safe", as defined in Section 7.1.1, then the 1159 request MAY be automatically redirected by the user agent without 1160 confirmation. Otherwise, the user agent MUST NOT automatically 1161 redirect the request unless it can be confirmed by the user, since 1162 this might change the conditions under which the request was issued. 1164 8.4. Client Error 4xx 1166 The 4xx class of status code is intended for cases in which the 1167 client seems to have erred. Except when responding to a HEAD 1168 request, the server SHOULD include an entity containing an 1169 explanation of the error situation, and whether it is a temporary or 1170 permanent condition. These status codes are applicable to any 1171 request method. User agents SHOULD display any included entity to 1172 the user. 1174 If the client is sending data, a server implementation using TCP 1175 SHOULD be careful to ensure that the client acknowledges receipt of 1176 the packet(s) containing the response, before the server closes the 1177 input connection. If the client continues sending data to the server 1178 after the close, the server's TCP stack will send a reset packet to 1179 the client, which may erase the client's unacknowledged input buffers 1180 before they can be read and interpreted by the HTTP application. 1182 8.4.1. 400 Bad Request 1184 The request could not be understood by the server due to malformed 1185 syntax. The client SHOULD NOT repeat the request without 1186 modifications. 1188 8.4.2. 401 Unauthorized 1190 The request requires user authentication (see Section 2.1 of 1191 [Part7]). 1193 8.4.3. 402 Payment Required 1195 This code is reserved for future use. 1197 8.4.4. 403 Forbidden 1199 The server understood the request, but is refusing to fulfill it. 1200 Authorization will not help and the request SHOULD NOT be repeated. 1201 If the request method was not HEAD and the server wishes to make 1202 public why the request has not been fulfilled, it SHOULD describe the 1203 reason for the refusal in the entity. If the server does not wish to 1204 make this information available to the client, the status code 404 1205 (Not Found) can be used instead. 1207 8.4.5. 404 Not Found 1209 The server has not found anything matching the Effective Request URI. 1210 No indication is given of whether the condition is temporary or 1211 permanent. The 410 (Gone) status code SHOULD be used if the server 1212 knows, through some internally configurable mechanism, that an old 1213 resource is permanently unavailable and has no forwarding address. 1214 This status code is commonly used when the server does not wish to 1215 reveal exactly why the request has been refused, or when no other 1216 response is applicable. 1218 8.4.6. 405 Method Not Allowed 1220 The method specified in the Request-Line is not allowed for the 1221 resource identified by the Effective Request URI. The response MUST 1222 include an Allow header containing a list of valid methods for the 1223 requested resource. 1225 8.4.7. 406 Not Acceptable 1227 The resource identified by the request is only capable of generating 1228 response entities which have content characteristics not acceptable 1229 according to the accept headers sent in the request. 1231 Unless it was a HEAD request, the response SHOULD include an entity 1232 containing a list of available entity characteristics and location(s) 1233 from which the user or user agent can choose the one most 1234 appropriate. The entity format is specified by the media type given 1235 in the Content-Type header field. Depending upon the format and the 1236 capabilities of the user agent, selection of the most appropriate 1237 choice MAY be performed automatically. However, this specification 1238 does not define any standard for such automatic selection. 1240 Note: HTTP/1.1 servers are allowed to return responses which are 1241 not acceptable according to the accept headers sent in the 1242 request. In some cases, this may even be preferable to sending a 1243 406 response. User agents are encouraged to inspect the headers 1244 of an incoming response to determine if it is acceptable. 1246 If the response could be unacceptable, a user agent SHOULD 1247 temporarily stop receipt of more data and query the user for a 1248 decision on further actions. 1250 8.4.8. 407 Proxy Authentication Required 1252 This code is similar to 401 (Unauthorized), but indicates that the 1253 client must first authenticate itself with the proxy (see Section 2.2 1254 of [Part7]). 1256 8.4.9. 408 Request Timeout 1258 The client did not produce a request within the time that the server 1259 was prepared to wait. The client MAY repeat the request without 1260 modifications at any later time. 1262 8.4.10. 409 Conflict 1264 The request could not be completed due to a conflict with the current 1265 state of the resource. This code is only allowed in situations where 1266 it is expected that the user might be able to resolve the conflict 1267 and resubmit the request. The response body SHOULD include enough 1268 information for the user to recognize the source of the conflict. 1269 Ideally, the response entity would include enough information for the 1270 user or user agent to fix the problem; however, that might not be 1271 possible and is not required. 1273 Conflicts are most likely to occur in response to a PUT request. For 1274 example, if versioning were being used and the entity being PUT 1275 included changes to a resource which conflict with those made by an 1276 earlier (third-party) request, the server might use the 409 response 1277 to indicate that it can't complete the request. In this case, the 1278 response entity would likely contain a list of the differences 1279 between the two versions in a format defined by the response Content- 1280 Type. 1282 8.4.11. 410 Gone 1284 The requested resource is no longer available at the server and no 1285 forwarding address is known. This condition is expected to be 1286 considered permanent. Clients with link editing capabilities SHOULD 1287 delete references to the Effective Request URI after user approval. 1288 If the server does not know, or has no facility to determine, whether 1289 or not the condition is permanent, the status code 404 (Not Found) 1290 SHOULD be used instead. This response is cacheable unless indicated 1291 otherwise. 1293 The 410 response is primarily intended to assist the task of web 1294 maintenance by notifying the recipient that the resource is 1295 intentionally unavailable and that the server owners desire that 1296 remote links to that resource be removed. Such an event is common 1297 for limited-time, promotional services and for resources belonging to 1298 individuals no longer working at the server's site. It is not 1299 necessary to mark all permanently unavailable resources as "gone" or 1300 to keep the mark for any length of time -- that is left to the 1301 discretion of the server owner. 1303 8.4.12. 411 Length Required 1305 The server refuses to accept the request without a defined Content- 1306 Length. The client MAY repeat the request if it adds a valid 1307 Content-Length header field containing the length of the message-body 1308 in the request message. 1310 8.4.13. 412 Precondition Failed 1312 The precondition given in one or more of the request-header fields 1313 evaluated to false when it was tested on the server, as defined in 1314 Section 3.2 of [Part4]. 1316 8.4.14. 413 Request Entity Too Large 1318 The server is refusing to process a request because the request 1319 entity is larger than the server is willing or able to process. The 1320 server MAY close the connection to prevent the client from continuing 1321 the request. 1323 If the condition is temporary, the server SHOULD include a Retry- 1324 After header field to indicate that it is temporary and after what 1325 time the client MAY try again. 1327 8.4.15. 414 URI Too Long 1329 The server is refusing to service the request because the Effective 1330 Request URI is longer than the server is willing to interpret. This 1331 rare condition is only likely to occur when a client has improperly 1332 converted a POST request to a GET request with long query 1333 information, when the client has descended into a URI "black hole" of 1334 redirection (e.g., a redirected URI prefix that points to a suffix of 1335 itself), or when the server is under attack by a client attempting to 1336 exploit security holes present in some servers using fixed-length 1337 buffers for reading or manipulating the Effective Request URI. 1339 8.4.16. 415 Unsupported Media Type 1341 The server is refusing to service the request because the entity of 1342 the request is in a format not supported by the requested resource 1343 for the requested method. 1345 8.4.17. 416 Requested Range Not Satisfiable 1347 The request included a Range request-header field (Section 5.4 of 1348 [Part5]) and none of the range-specifier values in this field overlap 1349 the current extent of the selected resource. See Section 3.2 of 1350 [Part5] 1352 8.4.18. 417 Expectation Failed 1354 The expectation given in an Expect request-header field (see 1355 Section 9.2) could not be met by this server, or, if the server is a 1356 proxy, the server has unambiguous evidence that the request could not 1357 be met by the next-hop server. 1359 8.5. Server Error 5xx 1361 Response status codes beginning with the digit "5" indicate cases in 1362 which the server is aware that it has erred or is incapable of 1363 performing the request. Except when responding to a HEAD request, 1364 the server SHOULD include an entity containing an explanation of the 1365 error situation, and whether it is a temporary or permanent 1366 condition. User agents SHOULD display any included entity to the 1367 user. These response codes are applicable to any request method. 1369 8.5.1. 500 Internal Server Error 1371 The server encountered an unexpected condition which prevented it 1372 from fulfilling the request. 1374 8.5.2. 501 Not Implemented 1376 The server does not support the functionality required to fulfill the 1377 request. This is the appropriate response when the server does not 1378 recognize the request method and is not capable of supporting it for 1379 any resource. 1381 8.5.3. 502 Bad Gateway 1383 The server, while acting as a gateway or proxy, received an invalid 1384 response from the upstream server it accessed in attempting to 1385 fulfill the request. 1387 8.5.4. 503 Service Unavailable 1389 The server is currently unable to handle the request due to a 1390 temporary overloading or maintenance of the server. The implication 1391 is that this is a temporary condition which will be alleviated after 1392 some delay. If known, the length of the delay MAY be indicated in a 1393 Retry-After header. If no Retry-After is given, the client SHOULD 1394 handle the response as it would for a 500 response. 1396 Note: The existence of the 503 status code does not imply that a 1397 server must use it when becoming overloaded. Some servers may 1398 wish to simply refuse the connection. 1400 8.5.5. 504 Gateway Timeout 1402 The server, while acting as a gateway or proxy, did not receive a 1403 timely response from the upstream server specified by the URI (e.g., 1404 HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed 1405 to access in attempting to complete the request. 1407 Note to implementors: some deployed proxies are known to return 1408 400 or 500 when DNS lookups time out. 1410 8.5.6. 505 HTTP Version Not Supported 1412 The server does not support, or refuses to support, the protocol 1413 version that was used in the request message. The server is 1414 indicating that it is unable or unwilling to complete the request 1415 using the same major version as the client, as described in Section 1416 2.5 of [Part1], other than with this error message. The response 1417 SHOULD contain an entity describing why that version is not supported 1418 and what other protocols are supported by that server. 1420 9. Header Field Definitions 1422 This section defines the syntax and semantics of HTTP/1.1 header 1423 fields related to request and response semantics. 1425 For entity-header fields, both sender and recipient refer to either 1426 the client or the server, depending on who sends and who receives the 1427 entity. 1429 9.1. Allow 1431 The "Allow" response-header field lists the set of methods advertised 1432 as supported by the resource identified by the Effective Request URI. 1433 The purpose of this field is strictly to inform the recipient of 1434 valid methods associated with the resource. 1436 Allow = "Allow" ":" OWS Allow-v 1437 Allow-v = #Method 1439 Example of use: 1441 Allow: GET, HEAD, PUT 1443 The actual set of allowed methods is defined by the origin server at 1444 the time of each request. 1446 A proxy MUST NOT modify the Allow header field even if it does not 1447 understand all the methods specified, since the user agent might have 1448 other means of communicating with the origin server. 1450 9.2. Expect 1452 The "Expect" request-header field is used to indicate that particular 1453 server behaviors are required by the client. 1455 Expect = "Expect" ":" OWS Expect-v 1456 Expect-v = 1#expectation 1458 expectation = "100-continue" / expectation-extension 1459 expectation-extension = token [ "=" ( token / quoted-string ) 1460 *expect-params ] 1461 expect-params = ";" token [ "=" ( token / quoted-string ) ] 1463 A server that does not understand or is unable to comply with any of 1464 the expectation values in the Expect field of a request MUST respond 1465 with appropriate error status. The server MUST respond with a 417 1466 (Expectation Failed) status if any of the expectations cannot be met 1467 or, if there are other problems with the request, some other 4xx 1468 status. 1470 This header field is defined with extensible syntax to allow for 1471 future extensions. If a server receives a request containing an 1472 Expect field that includes an expectation-extension that it does not 1473 support, it MUST respond with a 417 (Expectation Failed) status. 1475 Comparison of expectation values is case-insensitive for unquoted 1476 tokens (including the 100-continue token), and is case-sensitive for 1477 quoted-string expectation-extensions. 1479 The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST 1480 return a 417 (Expectation Failed) status if it receives a request 1481 with an expectation that it cannot meet. However, the Expect 1482 request-header itself is end-to-end; it MUST be forwarded if the 1483 request is forwarded. 1485 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the 1486 Expect header. 1488 See Section 7.2.3 of [Part1] for the use of the 100 (Continue) 1489 status. 1491 9.3. From 1493 The "From" request-header field, if given, SHOULD contain an Internet 1494 e-mail address for the human user who controls the requesting user 1495 agent. The address SHOULD be machine-usable, as defined by "mailbox" 1496 in Section 3.4 of [RFC5322]: 1498 From = "From" ":" OWS From-v 1499 From-v = mailbox 1501 mailbox = 1503 An example is: 1505 From: webmaster@example.org 1507 This header field MAY be used for logging purposes and as a means for 1508 identifying the source of invalid or unwanted requests. It SHOULD 1509 NOT be used as an insecure form of access protection. The 1510 interpretation of this field is that the request is being performed 1511 on behalf of the person given, who accepts responsibility for the 1512 method performed. In particular, robot agents SHOULD include this 1513 header so that the person responsible for running the robot can be 1514 contacted if problems occur on the receiving end. 1516 The Internet e-mail address in this field MAY be separate from the 1517 Internet host which issued the request. For example, when a request 1518 is passed through a proxy the original issuer's address SHOULD be 1519 used. 1521 The client SHOULD NOT send the From header field without the user's 1522 approval, as it might conflict with the user's privacy interests or 1523 their site's security policy. It is strongly recommended that the 1524 user be able to disable, enable, and modify the value of this field 1525 at any time prior to a request. 1527 9.4. Location 1529 The "Location" response-header field is used to identify a newly 1530 created resource, or to redirect the recipient to a different 1531 location for completion of the request. 1533 For 201 (Created) responses, the Location is the URI of the new 1534 resource which was created by the request. For 3xx responses, the 1535 location SHOULD indicate the server's preferred URI for automatic 1536 redirection to the resource. 1538 The field value consists of a single URI-reference. When it has the 1539 form of a relative reference ([RFC3986], Section 4.2), the final 1540 value is computed by resolving it against the effective request URI 1541 ([RFC3986], Section 5). 1543 Location = "Location" ":" OWS Location-v 1544 Location-v = URI-reference 1546 Examples are: 1548 Location: http://www.example.org/pub/WWW/People.html#tim 1550 Location: /index.html 1552 There are circumstances in which a fragment identifier in a Location 1553 URI would not be appropriate: 1555 o With a 201 Created response, because in this usage the Location 1556 header specifies the URI for the entire created resource. 1558 o With 305 Use Proxy. 1560 Note: This specification does not define precedence rules for the 1561 case where the original URI, as navigated to by the user agent, 1562 and the Location header field value both contain fragment 1563 identifiers. 1565 Note: The Content-Location header field (Section 5.7 of [Part3]) 1566 differs from Location in that the Content-Location identifies the 1567 original location of the entity enclosed in the response. It is 1568 therefore possible for a response to contain header fields for 1569 both Location and Content-Location. 1571 9.5. Max-Forwards 1573 The "Max-Forwards" request-header field provides a mechanism with the 1574 TRACE (Section 7.8) and OPTIONS (Section 7.2) methods to limit the 1575 number of times that the request is forwarded by proxies or gateways. 1576 This can be useful when the client is attempting to trace a request 1577 which appears to be failing or looping in mid-chain. 1579 Max-Forwards = "Max-Forwards" ":" OWS Max-Forwards-v 1580 Max-Forwards-v = 1*DIGIT 1582 The Max-Forwards value is a decimal integer indicating the remaining 1583 number of times this request message may be forwarded. 1585 Each proxy or gateway recipient of a TRACE or OPTIONS request 1586 containing a Max-Forwards header field MUST check and update its 1587 value prior to forwarding the request. If the received value is zero 1588 (0), the recipient MUST NOT forward the request; instead, it MUST 1589 respond as the final recipient. If the received Max-Forwards value 1590 is greater than zero, then the forwarded message MUST contain an 1591 updated Max-Forwards field with a value decremented by one (1). 1593 The Max-Forwards header field MAY be ignored for all other methods 1594 defined by this specification and for any extension methods for which 1595 it is not explicitly referred to as part of that method definition. 1597 9.6. Referer 1599 The "Referer" [sic] request-header field allows the client to specify 1600 the URI of the resource from which the Effective Request URI was 1601 obtained (the "referrer", although the header field is misspelled.). 1603 The Referer header allows servers to generate lists of back-links to 1604 resources for interest, logging, optimized caching, etc. It also 1605 allows obsolete or mistyped links to be traced for maintenance. Some 1606 servers use Referer as a means of controlling where they allow links 1607 from (so-called "deep linking"), but it should be noted that 1608 legitimate requests are not required to contain a Referer header 1609 field. 1611 If the Effective Request URI was obtained from a source that does not 1612 have its own URI (e.g., input from the user keyboard), the Referer 1613 field MUST either be sent with the value "about:blank", or not be 1614 sent at all. Note that this requirement does not apply to sources 1615 with non-HTTP URIs (e.g., FTP). 1617 Referer = "Referer" ":" OWS Referer-v 1618 Referer-v = absolute-URI / partial-URI 1620 Example: 1622 Referer: http://www.example.org/hypertext/Overview.html 1624 If the field value is a relative URI, it SHOULD be interpreted 1625 relative to the Effective Request URI. The URI MUST NOT include a 1626 fragment. See Section 11.2 for security considerations. 1628 9.7. Retry-After 1630 The response-header "Retry-After" field can be used with a 503 1631 (Service Unavailable) response to indicate how long the service is 1632 expected to be unavailable to the requesting client. This field MAY 1633 also be used with any 3xx (Redirection) response to indicate the 1634 minimum time the user-agent is asked wait before issuing the 1635 redirected request. 1637 The value of this field can be either an HTTP-date or an integer 1638 number of seconds (in decimal) after the time of the response. 1640 Retry-After = "Retry-After" ":" OWS Retry-After-v 1641 Retry-After-v = HTTP-date / delta-seconds 1643 Time spans are non-negative decimal integers, representing time in 1644 seconds. 1646 delta-seconds = 1*DIGIT 1648 Two examples of its use are 1650 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 1651 Retry-After: 120 1653 In the latter example, the delay is 2 minutes. 1655 9.8. Server 1657 The "Server" response-header field contains information about the 1658 software used by the origin server to handle the request. 1660 The field can contain multiple product tokens (Section 6.3 of 1661 [Part1]) and comments (Section 3.2 of [Part1]) identifying the server 1662 and any significant subproducts. The product tokens are listed in 1663 order of their significance for identifying the application. 1665 Server = "Server" ":" OWS Server-v 1666 Server-v = product 1667 *( RWS ( product / comment ) ) 1669 Example: 1671 Server: CERN/3.0 libwww/2.17 1673 If the response is being forwarded through a proxy, the proxy 1674 application MUST NOT modify the Server response-header. Instead, it 1675 MUST include a Via field (as described in Section 9.9 of [Part1]). 1677 Note: Revealing the specific software version of the server might 1678 allow the server machine to become more vulnerable to attacks 1679 against software that is known to contain security holes. Server 1680 implementors are encouraged to make this field a configurable 1681 option. 1683 9.9. User-Agent 1685 The "User-Agent" request-header field contains information about the 1686 user agent originating the request. This is for statistical 1687 purposes, the tracing of protocol violations, and automated 1688 recognition of user agents for the sake of tailoring responses to 1689 avoid particular user agent limitations. 1691 User agents SHOULD include this field with requests. The field can 1692 contain multiple product tokens (Section 6.3 of [Part1]) and comments 1693 (Section 3.2 of [Part1]) identifying the agent and any subproducts 1694 which form a significant part of the user agent. By convention, the 1695 product tokens are listed in order of their significance for 1696 identifying the application. 1698 User-Agent = "User-Agent" ":" OWS User-Agent-v 1699 User-Agent-v = product 1700 *( RWS ( product / comment ) ) 1702 Example: 1704 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1706 10. IANA Considerations 1708 10.1. Method Registry 1710 The registration procedure for HTTP Methods is defined by Section 2.1 1711 of this document. 1713 The HTTP Method Registry should be created at 1714 and be populated with 1715 the registrations below: 1717 +---------+------+-------------+ 1718 | Method | Safe | Reference | 1719 +---------+------+-------------+ 1720 | CONNECT | no | Section 7.9 | 1721 | DELETE | no | Section 7.7 | 1722 | GET | yes | Section 7.3 | 1723 | HEAD | yes | Section 7.4 | 1724 | OPTIONS | yes | Section 7.2 | 1725 | POST | no | Section 7.5 | 1726 | PUT | no | Section 7.6 | 1727 | TRACE | yes | Section 7.8 | 1728 +---------+------+-------------+ 1730 10.2. Status Code Registry 1732 The registration procedure for HTTP Status Codes -- previously 1733 defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.1 1734 of this document. 1736 The HTTP Status Code Registry located at 1737 should be updated 1738 with the registrations below: 1740 +-------+-------------------------------+----------------+ 1741 | Value | Description | Reference | 1742 +-------+-------------------------------+----------------+ 1743 | 100 | Continue | Section 8.1.1 | 1744 | 101 | Switching Protocols | Section 8.1.2 | 1745 | 200 | OK | Section 8.2.1 | 1746 | 201 | Created | Section 8.2.2 | 1747 | 202 | Accepted | Section 8.2.3 | 1748 | 203 | Non-Authoritative Information | Section 8.2.4 | 1749 | 204 | No Content | Section 8.2.5 | 1750 | 205 | Reset Content | Section 8.2.6 | 1751 | 300 | Multiple Choices | Section 8.3.1 | 1752 | 301 | Moved Permanently | Section 8.3.2 | 1753 | 302 | Found | Section 8.3.3 | 1754 | 303 | See Other | Section 8.3.4 | 1755 | 305 | Use Proxy | Section 8.3.6 | 1756 | 306 | (Unused) | Section 8.3.7 | 1757 | 307 | Temporary Redirect | Section 8.3.8 | 1758 | 400 | Bad Request | Section 8.4.1 | 1759 | 402 | Payment Required | Section 8.4.3 | 1760 | 403 | Forbidden | Section 8.4.4 | 1761 | 404 | Not Found | Section 8.4.5 | 1762 | 405 | Method Not Allowed | Section 8.4.6 | 1763 | 406 | Not Acceptable | Section 8.4.7 | 1764 | 407 | Proxy Authentication Required | Section 8.4.8 | 1765 | 408 | Request Timeout | Section 8.4.9 | 1766 | 409 | Conflict | Section 8.4.10 | 1767 | 410 | Gone | Section 8.4.11 | 1768 | 411 | Length Required | Section 8.4.12 | 1769 | 413 | Request Entity Too Large | Section 8.4.14 | 1770 | 414 | URI Too Long | Section 8.4.15 | 1771 | 415 | Unsupported Media Type | Section 8.4.16 | 1772 | 417 | Expectation Failed | Section 8.4.18 | 1773 | 500 | Internal Server Error | Section 8.5.1 | 1774 | 501 | Not Implemented | Section 8.5.2 | 1775 | 502 | Bad Gateway | Section 8.5.3 | 1776 | 503 | Service Unavailable | Section 8.5.4 | 1777 | 504 | Gateway Timeout | Section 8.5.5 | 1778 | 505 | HTTP Version Not Supported | Section 8.5.6 | 1779 +-------+-------------------------------+----------------+ 1781 10.3. Message Header Registration 1783 The Message Header Registry located at should be 1785 updated with the permanent registrations below (see [RFC3864]): 1787 +-------------------+----------+----------+-------------+ 1788 | Header Field Name | Protocol | Status | Reference | 1789 +-------------------+----------+----------+-------------+ 1790 | Allow | http | standard | Section 9.1 | 1791 | Expect | http | standard | Section 9.2 | 1792 | From | http | standard | Section 9.3 | 1793 | Location | http | standard | Section 9.4 | 1794 | Max-Forwards | http | standard | Section 9.5 | 1795 | Referer | http | standard | Section 9.6 | 1796 | Retry-After | http | standard | Section 9.7 | 1797 | Server | http | standard | Section 9.8 | 1798 | User-Agent | http | standard | Section 9.9 | 1799 +-------------------+----------+----------+-------------+ 1801 The change controller is: "IETF (iesg@ietf.org) - Internet 1802 Engineering Task Force". 1804 11. Security Considerations 1806 This section is meant to inform application developers, information 1807 providers, and users of the security limitations in HTTP/1.1 as 1808 described by this document. The discussion does not include 1809 definitive solutions to the problems revealed, though it does make 1810 some suggestions for reducing security risks. 1812 11.1. Transfer of Sensitive Information 1814 Like any generic data transfer protocol, HTTP cannot regulate the 1815 content of the data that is transferred, nor is there any a priori 1816 method of determining the sensitivity of any particular piece of 1817 information within the context of any given request. Therefore, 1818 applications SHOULD supply as much control over this information as 1819 possible to the provider of that information. Four header fields are 1820 worth special mention in this context: Server, Via, Referer and From. 1822 Revealing the specific software version of the server might allow the 1823 server machine to become more vulnerable to attacks against software 1824 that is known to contain security holes. Implementors SHOULD make 1825 the Server header field a configurable option. 1827 Proxies which serve as a portal through a network firewall SHOULD 1828 take special precautions regarding the transfer of header information 1829 that identifies the hosts behind the firewall. In particular, they 1830 SHOULD remove, or replace with sanitized versions, any Via fields 1831 generated behind the firewall. 1833 The Referer header allows reading patterns to be studied and reverse 1834 links drawn. Although it can be very useful, its power can be abused 1835 if user details are not separated from the information contained in 1836 the Referer. Even when the personal information has been removed, 1837 the Referer header might indicate a private document's URI whose 1838 publication would be inappropriate. 1840 The information sent in the From field might conflict with the user's 1841 privacy interests or their site's security policy, and hence it 1842 SHOULD NOT be transmitted without the user being able to disable, 1843 enable, and modify the contents of the field. The user MUST be able 1844 to set the contents of this field within a user preference or 1845 application defaults configuration. 1847 We suggest, though do not require, that a convenient toggle interface 1848 be provided for the user to enable or disable the sending of From and 1849 Referer information. 1851 The User-Agent (Section 9.9) or Server (Section 9.8) header fields 1852 can sometimes be used to determine that a specific client or server 1853 have a particular security hole which might be exploited. 1854 Unfortunately, this same information is often used for other valuable 1855 purposes for which HTTP currently has no better mechanism. 1857 Some methods, like TRACE (Section 7.8) may expose information sent in 1858 request headers in the response entity. Clients SHOULD be careful 1859 with sensitive information, like Cookies, Authorization credentials 1860 and other headers that might be used to collect data from the client. 1862 11.2. Encoding Sensitive Information in URIs 1864 Because the source of a link might be private information or might 1865 reveal an otherwise private information source, it is strongly 1866 recommended that the user be able to select whether or not the 1867 Referer field is sent. For example, a browser client could have a 1868 toggle switch for browsing openly/anonymously, which would 1869 respectively enable/disable the sending of Referer and From 1870 information. 1872 Clients SHOULD NOT include a Referer header field in a (non-secure) 1873 HTTP request if the referring page was transferred with a secure 1874 protocol. 1876 Authors of services should not use GET-based forms for the submission 1877 of sensitive data because that data will be encoded in the request- 1878 target. Many existing servers, proxies, and user agents log or 1879 display the request-target in places where it might be visible to 1880 third parties. Such services can use POST-based form submission 1881 instead. 1883 11.3. Location Headers and Spoofing 1885 If a single server supports multiple organizations that do not trust 1886 one another, then it MUST check the values of Location and Content- 1887 Location headers in responses that are generated under control of 1888 said organizations to make sure that they do not attempt to 1889 invalidate resources over which they have no authority. 1891 12. Acknowledgments 1893 13. References 1895 13.1. Normative References 1897 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1898 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1899 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 1900 and Message Parsing", draft-ietf-httpbis-p1-messaging-10 1901 (work in progress), July 2010. 1903 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1904 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1905 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 1906 and Content Negotiation", draft-ietf-httpbis-p3-payload-10 1907 (work in progress), July 2010. 1909 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1910 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1911 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 1912 Requests", draft-ietf-httpbis-p4-conditional-10 (work in 1913 progress), July 2010. 1915 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1916 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1917 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 1918 Partial Responses", draft-ietf-httpbis-p5-range-10 (work 1919 in progress), July 2010. 1921 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1922 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1923 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part 1924 6: Caching", draft-ietf-httpbis-p6-cache-10 (work in 1925 progress), July 2010. 1927 [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1928 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1929 and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", 1930 draft-ietf-httpbis-p7-auth-10 (work in progress), 1931 July 2010. 1933 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1934 Requirement Levels", BCP 14, RFC 2119, March 1997. 1936 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1937 Resource Identifier (URI): Generic Syntax", RFC 3986, 1938 STD 66, January 2005. 1940 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1941 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1943 13.2. Informative References 1945 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1946 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1948 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 1949 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 1950 RFC 2068, January 1997. 1952 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1953 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1954 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1956 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 1957 HTTP/1.1", RFC 2817, May 2000. 1959 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1960 Procedures for Message Header Fields", BCP 90, RFC 3864, 1961 September 2004. 1963 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1964 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1965 May 2008. 1967 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 1968 October 2008. 1970 Appendix A. Compatibility with Previous Versions 1972 A.1. Changes from RFC 2068 1974 Clarified which error code should be used for inbound server failures 1975 (e.g., DNS failures). (Section 8.5.5). 1977 201 (Created) had a race that required an Etag be sent when a 1978 resource is first created. (Section 8.2.2). 1980 303 (See Also) and 307 (Temporary Redirect) added to address user 1981 agent failure to implement status code 302 properly. (Section 8.3.4 1982 and 8.3.8) 1984 Rewrite of message transmission requirements to make it much harder 1985 for implementors to get it wrong, as the consequences of errors here 1986 can have significant impact on the Internet, and to deal with the 1987 following problems: 1989 1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where 1990 this was incorrectly placing a requirement on the behavior of an 1991 implementation of a future version of HTTP/1.x 1993 2. Made it clear that user-agents should retry requests, not 1994 "clients" in general. 1996 3. Converted requirements for clients to ignore unexpected 100 1997 (Continue) responses, and for proxies to forward 100 responses, 1998 into a general requirement for 1xx responses. 2000 4. Modified some TCP-specific language, to make it clearer that non- 2001 TCP transports are possible for HTTP. 2003 5. Require that the origin server MUST NOT wait for the request body 2004 before it sends a required 100 (Continue) response. 2006 6. Allow, rather than require, a server to omit 100 (Continue) if it 2007 has already seen some of the request body. 2009 7. Allow servers to defend against denial-of-service attacks and 2010 broken clients. 2012 This change adds the Expect header and 417 status code. 2014 Clean up confusion between 403 and 404 responses. (Section 8.4.4, 2015 8.4.5, and 8.4.11) 2017 The PATCH, LINK, UNLINK methods were defined but not commonly 2018 implemented in previous versions of this specification. See Section 2019 19.6.1 of [RFC2068]. 2021 A.2. Changes from RFC 2616 2023 This document takes over the Status Code Registry, previously defined 2024 in Section 7.1 of [RFC2817]. (Section 4.1) 2026 Clarify definition of POST. (Section 7.5) 2027 Failed to consider that there are many other request methods that are 2028 safe to automatically redirect, and further that the user agent is 2029 able to make that determination based on the request method 2030 semantics. (Sections 8.3.2, 8.3.3 and 8.3.8) 2032 Deprecate 305 Use Proxy status code, because user agents did not 2033 implement it. It used to indicate that the requested resource must 2034 be accessed through the proxy given by the Location field. The 2035 Location field gave the URI of the proxy. The recipient was expected 2036 to repeat this single request via the proxy. (Section 8.3.6) 2038 Reclassify Allow header as response header, removing the option to 2039 specify it in a PUT request. Relax the server requirement on the 2040 contents of the Allow header and remove requirement on clients to 2041 always trust the header value. (Section 9.1) 2043 Correct syntax of Location header to allow URI references (including 2044 relative references and fragments), as referred symbol "absoluteURI" 2045 wasn't what was expected, and add some clarifications as to when use 2046 of fragments would not be appropriate. (Section 9.4) 2048 Allow Referer value of "about:blank" as alternative to not specifying 2049 it. (Section 9.6) 2051 In the description of the Server header, the Via field was described 2052 as a SHOULD. The requirement was and is stated correctly in the 2053 description of the Via header in Section 9.9 of [Part1]. 2054 (Section 9.8) 2056 Appendix B. Collected ABNF 2058 Accept = 2059 Accept-Charset = 2060 Accept-Encoding = 2061 Accept-Language = 2062 Accept-Ranges = 2063 Age = 2064 Allow = "Allow:" OWS Allow-v 2065 Allow-v = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] 2066 Authorization = 2068 ETag = 2069 Expect = "Expect:" OWS Expect-v 2070 Expect-v = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) 2072 From = "From:" OWS From-v 2073 From-v = mailbox 2074 HTTP-date = 2075 Host = 2077 If-Match = 2078 If-Modified-Since = 2079 2080 If-None-Match = 2081 If-Range = 2082 If-Unmodified-Since = 2083 2085 Location = "Location:" OWS Location-v 2086 Location-v = URI-reference 2088 Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v 2089 Max-Forwards-v = 1*DIGIT 2090 Method = %x4F.50.54.49.4F.4E.53 ; OPTIONS 2091 / %x47.45.54 ; GET 2092 / %x48.45.41.44 ; HEAD 2093 / %x50.4F.53.54 ; POST 2094 / %x50.55.54 ; PUT 2095 / %x44.45.4C.45.54.45 ; DELETE 2096 / %x54.52.41.43.45 ; TRACE 2097 / %x43.4F.4E.4E.45.43.54 ; CONNECT 2098 / extension-method 2100 OWS = 2102 Proxy-Authenticate = 2103 2104 Proxy-Authorization = 2105 2107 RWS = 2108 Range = 2109 Reason-Phrase = *( WSP / VCHAR / obs-text ) 2110 Referer = "Referer:" OWS Referer-v 2111 Referer-v = absolute-URI / partial-URI 2112 Retry-After = "Retry-After:" OWS Retry-After-v 2113 Retry-After-v = HTTP-date / delta-seconds 2115 Server = "Server:" OWS Server-v 2116 Server-v = product *( RWS ( product / comment ) ) 2117 Status-Code = "100" / "101" / "200" / "201" / "202" / "203" / "204" / 2118 "205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" / 2119 "307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" / 2120 "407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" / 2121 "415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" / 2122 "505" / extension-code 2124 TE = 2126 URI-reference = 2127 User-Agent = "User-Agent:" OWS User-Agent-v 2128 User-Agent-v = product *( RWS ( product / comment ) ) 2130 Vary = 2132 WWW-Authenticate = 2133 2135 absolute-URI = 2137 comment = 2139 delta-seconds = 1*DIGIT 2141 expect-params = ";" token [ "=" ( token / quoted-string ) ] 2142 expectation = "100-continue" / expectation-extension 2143 expectation-extension = token [ "=" ( token / quoted-string ) 2144 *expect-params ] 2145 extension-code = 3DIGIT 2146 extension-method = token 2148 mailbox = 2150 obs-text = 2152 partial-URI = 2153 product = 2155 quoted-string = 2157 request-header = Accept / Accept-Charset / Accept-Encoding / 2158 Accept-Language / Authorization / Expect / From / Host / If-Match / 2159 If-Modified-Since / If-None-Match / If-Range / If-Unmodified-Since / 2160 Max-Forwards / Proxy-Authorization / Range / Referer / TE / 2161 User-Agent 2162 response-header = Accept-Ranges / Age / Allow / ETag / Location / 2163 Proxy-Authenticate / Retry-After / Server / Vary / WWW-Authenticate 2165 token = 2167 ABNF diagnostics: 2169 ; Reason-Phrase defined but not used 2170 ; Status-Code defined but not used 2171 ; request-header defined but not used 2172 ; response-header defined but not used 2174 Appendix C. Change Log (to be removed by RFC Editor before publication) 2176 C.1. Since RFC2616 2178 Extracted relevant partitions from [RFC2616]. 2180 C.2. Since draft-ietf-httpbis-p2-semantics-00 2182 Closed issues: 2184 o : "Via is a MUST" 2185 () 2187 o : "Fragments 2188 allowed in Location" 2189 () 2191 o : "Safe Methods 2192 vs Redirection" () 2194 o : "Revise 2195 description of the POST method" 2196 () 2198 o : "Normative and 2199 Informative references" 2201 o : "RFC2606 2202 Compliance" 2204 o : "Informative 2205 references" 2207 o : "Redundant 2208 cross-references" 2210 Other changes: 2212 o Move definitions of 304 and 412 condition codes to [Part4] 2214 C.3. Since draft-ietf-httpbis-p2-semantics-01 2216 Closed issues: 2218 o : "PUT side 2219 effects" 2221 o : "Duplicate Host 2222 header requirements" 2224 Ongoing work on ABNF conversion 2225 (): 2227 o Move "Product Tokens" section (back) into Part 1, as "token" is 2228 used in the definition of the Upgrade header. 2230 o Add explicit references to BNF syntax and rules imported from 2231 other parts of the specification. 2233 o Copy definition of delta-seconds from Part6 instead of referencing 2234 it. 2236 C.4. Since draft-ietf-httpbis-p2-semantics-02 2238 Closed issues: 2240 o : "Requiring 2241 Allow in 405 responses" 2243 o : "Status Code 2244 Registry" 2246 o : "Redirection 2247 vs. Location" 2249 o : "Cacheability 2250 of 303 response" 2252 o : "305 Use Proxy" 2254 o : 2255 "Classification for Allow header" 2257 o : "PUT - 'store 2258 under' vs 'store at'" 2260 Ongoing work on IANA Message Header Registration 2261 (): 2263 o Reference RFC 3984, and update header registrations for headers 2264 defined in this document. 2266 Ongoing work on ABNF conversion 2267 (): 2269 o Replace string literals when the string really is case-sensitive 2270 (method). 2272 C.5. Since draft-ietf-httpbis-p2-semantics-03 2274 Closed issues: 2276 o : "OPTIONS 2277 request bodies" 2279 o : "Description 2280 of CONNECT should refer to RFC2817" 2282 o : "Location 2283 Content-Location reference request/response mixup" 2285 Ongoing work on Method Registry 2286 (): 2288 o Added initial proposal for registration process, plus initial 2289 content (non-HTTP/1.1 methods to be added by a separate 2290 specification). 2292 C.6. Since draft-ietf-httpbis-p2-semantics-04 2294 Closed issues: 2296 o : "Content-*" 2298 o : "RFC 2822 is 2299 updated by RFC 5322" 2301 Ongoing work on ABNF conversion 2302 (): 2304 o Use "/" instead of "|" for alternatives. 2306 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 2307 whitespace ("OWS") and required whitespace ("RWS"). 2309 o Rewrite ABNFs to spell out whitespace rules, factor out header 2310 value format definitions. 2312 C.7. Since draft-ietf-httpbis-p2-semantics-05 2314 Closed issues: 2316 o : "Reason-Phrase 2317 BNF" 2319 Final work on ABNF conversion 2320 (): 2322 o Add appendix containing collected and expanded ABNF, reorganize 2323 ABNF introduction. 2325 C.8. Since draft-ietf-httpbis-p2-semantics-06 2327 Closed issues: 2329 o : "Clarify when 2330 Referer is sent" 2332 o : "status codes 2333 vs methods" 2335 o : "Do not 2336 require "updates" relation for specs that register status codes or 2337 method names" 2339 C.9. Since draft-ietf-httpbis-p2-semantics-07 2341 Closed issues: 2343 o : "Idempotency" 2345 o : "TRACE security 2346 considerations" 2348 o : "Clarify rules 2349 for determining what entities a response carries" 2351 o : "update note 2352 citing RFC 1945 and 2068" 2354 o : "update note 2355 about redirect limit" 2357 o : "Location 2358 header ABNF should use 'URI'" 2360 o : "fragments in 2361 Location vs status 303" 2363 o : "move IANA 2364 registrations for optional status codes" 2366 Partly resolved issues: 2368 o : "Are OPTIONS 2369 and TRACE safe?" 2371 C.10. Since draft-ietf-httpbis-p2-semantics-08 2373 Closed issues: 2375 o : "Safe Methods 2376 vs Redirection" (we missed the introduction to the 3xx status 2377 codes when fixing this previously) 2379 C.11. Since draft-ietf-httpbis-p2-semantics-09 2381 Closed issues: 2383 o : "Fragment 2384 combination / precedence during redirects" 2386 Partly resolved issues: 2388 o : "Location 2389 header payload handling" 2391 o : "Term for the 2392 requested resource's URI" 2394 Index 2396 1 2397 100 Continue (status code) 20 2398 101 Switching Protocols (status code) 20 2400 2 2401 200 OK (status code) 21 2402 201 Created (status code) 21 2403 202 Accepted (status code) 22 2404 203 Non-Authoritative Information (status code) 22 2405 204 No Content (status code) 22 2406 205 Reset Content (status code) 23 2407 206 Partial Content (status code) 23 2409 3 2410 300 Multiple Choices (status code) 23 2411 301 Moved Permanently (status code) 24 2412 302 Found (status code) 24 2413 303 See Other (status code) 25 2414 304 Not Modified (status code) 25 2415 305 Use Proxy (status code) 26 2416 306 (Unused) (status code) 26 2417 307 Temporary Redirect (status code) 26 2419 4 2420 400 Bad Request (status code) 27 2421 401 Unauthorized (status code) 27 2422 402 Payment Required (status code) 27 2423 403 Forbidden (status code) 27 2424 404 Not Found (status code) 27 2425 405 Method Not Allowed (status code) 27 2426 406 Not Acceptable (status code) 28 2427 407 Proxy Authentication Required (status code) 28 2428 408 Request Timeout (status code) 28 2429 409 Conflict (status code) 28 2430 410 Gone (status code) 29 2431 411 Length Required (status code) 29 2432 412 Precondition Failed (status code) 29 2433 413 Request Entity Too Large (status code) 29 2434 414 URI Too Long (status code) 30 2435 415 Unsupported Media Type (status code) 30 2436 416 Requested Range Not Satisfiable (status code) 30 2437 417 Expectation Failed (status code) 30 2439 5 2440 500 Internal Server Error (status code) 31 2441 501 Not Implemented (status code) 31 2442 502 Bad Gateway (status code) 31 2443 503 Service Unavailable (status code) 31 2444 504 Gateway Timeout (status code) 31 2445 505 HTTP Version Not Supported (status code) 31 2447 A 2448 Allow header 32 2450 C 2451 CONNECT method 20 2453 D 2454 DELETE method 19 2456 E 2457 Expect header 32 2459 F 2460 From header 33 2462 G 2463 GET method 16 2464 Grammar 2465 Allow 32 2466 Allow-v 32 2467 delta-seconds 36 2468 Expect 32 2469 expect-params 32 2470 Expect-v 32 2471 expectation 32 2472 expectation-extension 32 2473 extension-code 11 2474 extension-method 8 2475 From 33 2476 From-v 33 2477 Location 34 2478 Location-v 34 2479 Max-Forwards 35 2480 Max-Forwards-v 35 2481 Method 8 2482 Reason-Phrase 11 2483 Referer 36 2484 Referer-v 36 2485 request-header 9 2486 response-header 12 2487 Retry-After 36 2488 Retry-After-v 36 2489 Server 37 2490 Server-v 37 2491 Status-Code 11 2492 User-Agent 37 2493 User-Agent-v 37 2495 H 2496 HEAD method 16 2497 Headers 2498 Allow 32 2499 Expect 32 2500 From 33 2501 Location 34 2502 Max-Forwards 35 2503 Referer 35 2504 Retry-After 36 2505 Server 37 2506 User-Agent 37 2508 I 2509 Idempotent Methods 14 2511 L 2512 LINK method 44 2513 Location header 34 2515 M 2516 Max-Forwards header 35 2517 Methods 2518 CONNECT 20 2519 DELETE 19 2520 GET 16 2521 HEAD 16 2522 LINK 44 2523 OPTIONS 14 2524 PATCH 44 2525 POST 17 2526 PUT 17 2527 TRACE 19 2528 UNLINK 44 2530 O 2531 OPTIONS method 14 2533 P 2534 PATCH method 44 2535 POST method 17 2536 PUT method 17 2538 R 2539 Referer header 35 2540 Retry-After header 36 2542 S 2543 Safe Methods 14 2544 Server header 37 2545 Status Codes 2546 100 Continue 20 2547 101 Switching Protocols 20 2548 200 OK 21 2549 201 Created 21 2550 202 Accepted 22 2551 203 Non-Authoritative Information 22 2552 204 No Content 22 2553 205 Reset Content 23 2554 206 Partial Content 23 2555 300 Multiple Choices 23 2556 301 Moved Permanently 24 2557 302 Found 24 2558 303 See Other 25 2559 304 Not Modified 25 2560 305 Use Proxy 26 2561 306 (Unused) 26 2562 307 Temporary Redirect 26 2563 400 Bad Request 27 2564 401 Unauthorized 27 2565 402 Payment Required 27 2566 403 Forbidden 27 2567 404 Not Found 27 2568 405 Method Not Allowed 27 2569 406 Not Acceptable 28 2570 407 Proxy Authentication Required 28 2571 408 Request Timeout 28 2572 409 Conflict 28 2573 410 Gone 29 2574 411 Length Required 29 2575 412 Precondition Failed 29 2576 413 Request Entity Too Large 29 2577 414 URI Too Long 30 2578 415 Unsupported Media Type 30 2579 416 Requested Range Not Satisfiable 30 2580 417 Expectation Failed 30 2581 500 Internal Server Error 31 2582 501 Not Implemented 31 2583 502 Bad Gateway 31 2584 503 Service Unavailable 31 2585 504 Gateway Timeout 31 2586 505 HTTP Version Not Supported 31 2588 T 2589 TRACE method 19 2591 U 2592 UNLINK method 44 2593 User-Agent header 37 2595 Authors' Addresses 2597 Roy T. Fielding (editor) 2598 Day Software 2599 23 Corporate Plaza DR, Suite 280 2600 Newport Beach, CA 92660 2601 USA 2603 Phone: +1-949-706-5300 2604 Fax: +1-949-706-5305 2605 EMail: fielding@gbiv.com 2606 URI: http://roy.gbiv.com/ 2608 Jim Gettys 2609 Alcatel-Lucent Bell Labs 2610 21 Oak Knoll Road 2611 Carlisle, MA 01741 2612 USA 2614 EMail: jg@freedesktop.org 2615 URI: http://gettys.wordpress.com/ 2617 Jeffrey C. Mogul 2618 Hewlett-Packard Company 2619 HP Labs, Large Scale Systems Group 2620 1501 Page Mill Road, MS 1177 2621 Palo Alto, CA 94304 2622 USA 2624 EMail: JeffMogul@acm.org 2626 Henrik Frystyk Nielsen 2627 Microsoft Corporation 2628 1 Microsoft Way 2629 Redmond, WA 98052 2630 USA 2632 EMail: henrikn@microsoft.com 2633 Larry Masinter 2634 Adobe Systems, Incorporated 2635 345 Park Ave 2636 San Jose, CA 95110 2637 USA 2639 EMail: LMM@acm.org 2640 URI: http://larry.masinter.net/ 2642 Paul J. Leach 2643 Microsoft Corporation 2644 1 Microsoft Way 2645 Redmond, WA 98052 2647 EMail: paulle@microsoft.com 2649 Tim Berners-Lee 2650 World Wide Web Consortium 2651 MIT Computer Science and Artificial Intelligence Laboratory 2652 The Stata Center, Building 32 2653 32 Vassar Street 2654 Cambridge, MA 02139 2655 USA 2657 EMail: timbl@w3.org 2658 URI: http://www.w3.org/People/Berners-Lee/ 2660 Yves Lafon (editor) 2661 World Wide Web Consortium 2662 W3C / ERCIM 2663 2004, rte des Lucioles 2664 Sophia-Antipolis, AM 06902 2665 France 2667 EMail: ylafon@w3.org 2668 URI: http://www.raubacapeu.net/people/yves/ 2669 Julian F. Reschke (editor) 2670 greenbytes GmbH 2671 Hafenweg 16 2672 Muenster, NW 48155 2673 Germany 2675 Phone: +49 251 2807760 2676 Fax: +49 251 2807761 2677 EMail: julian.reschke@greenbytes.de 2678 URI: http://greenbytes.de/tech/webdav/