idnits 2.17.1 draft-ietf-httpbis-p2-semantics-11.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 (August 4, 2010) is 5014 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-11 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-11 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-11 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-11 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-11 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-11 -- 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: February 5, 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 August 4, 2010 22 HTTP/1.1, part 2: Message Semantics 23 draft-ietf-httpbis-p2-semantics-11 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.12. 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 February 5, 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. Representation . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 15 112 7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 113 7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 114 7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 115 7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . 24 133 8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 24 134 8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 25 135 8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 25 136 8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . . . . . 28 146 8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 28 147 8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 28 148 8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 28 149 8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 29 150 8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 29 151 8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 29 152 8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 30 153 8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 30 154 8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 30 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 . . . . . . . . . . . . . . . . 31 159 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 31 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 . . . . . . . . . . . . . . . . . 32 165 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 32 166 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 32 167 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 32 168 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 33 169 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 170 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 34 171 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 35 172 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 36 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. Header Field 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. Changes from RFC 2616 . . . . . . . . . . . . . . . . 43 189 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 44 190 Appendix C. Change Log (to be removed by RFC Editor before 191 publication) . . . . . . . . . . . . . . . . . . . . 47 193 C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 47 194 C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 47 195 C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 47 196 C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 48 197 C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 49 198 C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 49 199 C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 49 200 C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 50 201 C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 50 202 C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 51 203 C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 51 204 C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 51 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 to the target 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 target 314 resource (Section 4.3 of [Part1]). The method is case-sensitive. 316 Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 7.2 317 / %x47.45.54 ; "GET", Section 7.3 318 / %x48.45.41.44 ; "HEAD", Section 7.4 319 / %x50.4F.53.54 ; "POST", Section 7.5 320 / %x50.55.54 ; "PUT", Section 7.6 321 / %x44.45.4C.45.54.45 ; "DELETE", Section 7.7 322 / %x54.52.41.43.45 ; "TRACE", Section 7.8 323 / %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 7.9 324 / extension-method 325 extension-method = token 327 The list of methods allowed by a resource can be specified in an 328 Allow header field (Section 9.1). The status code of the response 329 always notifies the client whether a method is currently allowed on a 330 resource, since the set of allowed methods can change dynamically. 331 An origin server SHOULD respond with the status code 405 (Method Not 332 Allowed) if the method is known by the origin server but not allowed 333 for the resource, and 501 (Not Implemented) if the method is 334 unrecognized or not implemented by the origin server. The methods 335 GET and HEAD MUST be supported by all general-purpose servers. All 336 other methods are OPTIONAL; however, if the above methods are 337 implemented, they MUST be implemented with the same semantics as 338 those specified in Section 7. 340 2.1. Method Registry 342 The HTTP Method Registry defines the name space for the Method token 343 in the Request line of an HTTP request. 345 Registrations MUST include the following fields: 347 o Method Name (see Section 2) 349 o Safe ("yes" or "no", see Section 7.1.1) 351 o Pointer to specification text 353 Values to be added to this name space are subject to IETF review 354 ([RFC5226], Section 4.1). 356 The registry itself is maintained at 357 . 359 3. Request Header Fields 361 The request-header fields allow the client to pass additional 362 information about the request, and about the client itself, to the 363 server. These fields act as request modifiers, with semantics 364 equivalent to the parameters on a programming language method 365 invocation. 367 request-header = Accept ; [Part3], Section 6.1 368 / Accept-Charset ; [Part3], Section 6.2 369 / Accept-Encoding ; [Part3], Section 6.3 370 / Accept-Language ; [Part3], Section 6.4 371 / Authorization ; [Part7], Section 3.1 372 / Expect ; Section 9.2 373 / From ; Section 9.3 374 / Host ; [Part1], Section 9.4 375 / If-Match ; [Part4], Section 6.2 376 / If-Modified-Since ; [Part4], Section 6.3 377 / If-None-Match ; [Part4], Section 6.4 378 / If-Range ; [Part5], Section 5.3 379 / If-Unmodified-Since ; [Part4], Section 6.5 380 / Max-Forwards ; Section 9.5 381 / Proxy-Authorization ; [Part7], Section 3.3 382 / Range ; [Part5], Section 5.4 383 / Referer ; Section 9.6 384 / TE ; [Part1], Section 9.5 385 / User-Agent ; Section 9.9 387 Request-header field names can be extended reliably only in 388 combination with a change in the protocol version. However, new or 389 experimental header fields MAY be given the semantics of request- 390 header fields if all parties in the communication recognize them to 391 be request-header fields. 393 4. Status Code and Reason Phrase 395 The Status-Code element is a 3-digit integer result code of the 396 attempt to understand and satisfy the request. The status codes 397 listed below are defined in Section 8, Section 3 of [Part4], Section 398 3 of [Part5], and Section 2 of [Part7]. 400 The Reason-Phrase is intended to give a short textual description of 401 the Status-Code. The Status-Code is intended for use by automata and 402 the Reason-Phrase is intended for the human user. The client is not 403 required to examine or display the Reason-Phrase. 405 The individual values of the numeric status codes defined for 406 HTTP/1.1, and an example set of corresponding Reason-Phrase values, 407 are presented below. The reason phrases listed here are only 408 recommendations -- they MAY be replaced by local equivalents without 409 affecting the protocol. 411 Status-Code = 412 "100" ; Section 8.1.1: Continue 413 / "101" ; Section 8.1.2: Switching Protocols 414 / "200" ; Section 8.2.1: OK 415 / "201" ; Section 8.2.2: Created 416 / "202" ; Section 8.2.3: Accepted 417 / "203" ; Section 8.2.4: Non-Authoritative Information 418 / "204" ; Section 8.2.5: No Content 419 / "205" ; Section 8.2.6: Reset Content 420 / "206" ; [Part5], Section 3.1: Partial Content 421 / "300" ; Section 8.3.1: Multiple Choices 422 / "301" ; Section 8.3.2: Moved Permanently 423 / "302" ; Section 8.3.3: Found 424 / "303" ; Section 8.3.4: See Other 425 / "304" ; [Part4], Section 3.1: Not Modified 426 / "305" ; Section 8.3.6: Use Proxy 427 / "307" ; Section 8.3.8: Temporary Redirect 428 / "400" ; Section 8.4.1: Bad Request 429 / "401" ; [Part7], Section 2.1: Unauthorized 430 / "402" ; Section 8.4.3: Payment Required 431 / "403" ; Section 8.4.4: Forbidden 432 / "404" ; Section 8.4.5: Not Found 433 / "405" ; Section 8.4.6: Method Not Allowed 434 / "406" ; Section 8.4.7: Not Acceptable 435 / "407" ; [Part7], Section 2.2: Proxy Authentication Required 436 / "408" ; Section 8.4.9: Request Time-out 437 / "409" ; Section 8.4.10: Conflict 438 / "410" ; Section 8.4.11: Gone 439 / "411" ; Section 8.4.12: Length Required 440 / "412" ; [Part4], Section 3.2: Precondition Failed 441 / "413" ; Section 8.4.14: Request Entity Too Large 442 / "414" ; Section 8.4.15: URI Too Long 443 / "415" ; Section 8.4.16: Unsupported Media Type 444 / "416" ; [Part5], Section 3.2: Requested range not satisfiable 445 / "417" ; Section 8.4.18: Expectation Failed 446 / "500" ; Section 8.5.1: Internal Server Error 447 / "501" ; Section 8.5.2: Not Implemented 448 / "502" ; Section 8.5.3: Bad Gateway 449 / "503" ; Section 8.5.4: Service Unavailable 450 / "504" ; Section 8.5.5: Gateway Time-out 451 / "505" ; Section 8.5.6: HTTP Version not supported 452 / extension-code 454 extension-code = 3DIGIT 455 Reason-Phrase = *( WSP / VCHAR / obs-text ) 457 HTTP status codes are extensible. HTTP applications are not required 458 to understand the meaning of all registered status codes, though such 459 understanding is obviously desirable. However, applications MUST 460 understand the class of any status code, as indicated by the first 461 digit, and treat any unrecognized response as being equivalent to the 462 x00 status code of that class, with the exception that an 463 unrecognized response MUST NOT be cached. For example, if an 464 unrecognized status code of 431 is received by the client, it can 465 safely assume that there was something wrong with its request and 466 treat the response as if it had received a 400 status code. In such 467 cases, user agents SHOULD present to the user the representation 468 enclosed with the response, since that representation is likely to 469 include human-readable information which will explain the unusual 470 status. 472 4.1. Status Code Registry 474 The HTTP Status Code Registry defines the name space for the Status- 475 Code token in the Status-Line of an HTTP response. 477 Values to be added to this name space are subject to IETF review 478 ([RFC5226], Section 4.1). 480 The registry itself is maintained at 481 . 483 5. Response Header Fields 485 The response-header fields allow the server to pass additional 486 information about the response which cannot be placed in the Status- 487 Line. These header fields give information about the server and 488 about further access to the target resource (Section 4.3 of [Part1]). 490 response-header = Accept-Ranges ; [Part5], Section 5.1 491 / Age ; [Part6], Section 3.1 492 / Allow ; Section 9.1 493 / ETag ; [Part4], Section 6.1 494 / Location ; Section 9.4 495 / Proxy-Authenticate ; [Part7], Section 3.2 496 / Retry-After ; Section 9.7 497 / Server ; Section 9.8 498 / Vary ; [Part6], Section 3.5 499 / WWW-Authenticate ; [Part7], Section 3.4 501 Response-header field names can be extended reliably only in 502 combination with a change in the protocol version. However, new or 503 experimental header fields MAY be given the semantics of response- 504 header fields if all parties in the communication recognize them to 505 be response-header fields. 507 6. Representation 509 Request and Response messages MAY transfer a representation if not 510 otherwise restricted by the request method or response status code. 511 A representation consists of metadata (representation header fields) 512 and data (representation body). When a complete or partial 513 representation is enclosed in an HTTP message, it is referred to as 514 the payload of the message. HTTP representations are defined in 515 [Part3]. 517 A representation body is only present in a message when a message- 518 body is present, as described in Section 3.3 of [Part1]. The 519 representation body is obtained from the message-body by decoding any 520 Transfer-Encoding that might have been applied to ensure safe and 521 proper transfer of the message. 523 6.1. Identifying the Resource Associated with a Representation 525 It is sometimes necessary to determine an identifier for the resource 526 associated with a representation. 528 An HTTP request representation, when present, is always associated 529 with an anonymous (i.e., unidentified) resource. 531 In the common case, an HTTP response is a representation of the 532 target resource (see Section 4.3 of [Part1]). However, this is not 533 always the case. To determine the URI of the resource a response is 534 associated with, the following rules are used (with the first 535 applicable one being selected): 537 1. If the response status code is 200 or 203 and the request method 538 was GET, the response payload is a representation of the target 539 resource. 541 2. If the response status code is 204, 206, or 304 and the request 542 method was GET or HEAD, the response payload is a partial 543 representation of the target (see Section 2.8 of [Part6]). 545 3. If the response has a Content-Location header, and that URI is 546 the same as the effective request URI, the response payload is a 547 representation of the target resource. 549 4. If the response has a Content-Location header, and that URI is 550 not the same as the effective request URI, then the response 551 asserts that its payload is a representation of the resource 552 identified by the Content-Location URI. However, such an 553 assertion cannot be trusted unless it can be verified by other 554 means (not defined by HTTP). 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 need to be aware that the software represents the user 574 in their interactions over the Internet, and need to allow the user 575 to be aware of any actions they take which might have an unexpected 576 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 a message-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 (see Section 9.5). If no Max- 645 Forwards field is present in the request, then the forwarded request 646 MUST NOT include a Max-Forwards field. 648 7.3. GET 650 The GET method means retrieve whatever information (in the form of a 651 representation) currently corresponds to the target resource. 653 If the target resource is a data-producing process, it is the 654 produced data which shall be returned as the representation in the 655 response and not the source text of the process, unless that text 656 happens to be the output of the process. 658 The semantics of the GET method change to a "conditional GET" if the 659 request message includes an If-Modified-Since, If-Unmodified-Since, 660 If-Match, If-None-Match, or If-Range header field. A conditional GET 661 method requests that the representation be transferred only under the 662 circumstances described by the conditional header field(s). The 663 conditional GET method is intended to reduce unnecessary network 664 usage by allowing cached representations to be refreshed without 665 requiring multiple requests or transferring data already held by the 666 client. 668 The semantics of the GET method change to a "partial GET" if the 669 request message includes a Range header field. A partial GET 670 requests that only part of the representation be transferred, as 671 described in Section 5.4 of [Part5]. The partial GET method is 672 intended to reduce unnecessary network usage by allowing partially- 673 retrieved representations to be completed without transferring data 674 already held by the client. 676 The response to a GET request is cacheable and MAY be used to satisfy 677 subsequent GET and HEAD requests (see [Part6]). 679 See Section 11.2 for security considerations when used for forms. 681 7.4. HEAD 683 The HEAD method is identical to GET except that the server MUST NOT 684 return a message-body in the response. The metadata contained in the 685 HTTP headers in response to a HEAD request SHOULD be identical to the 686 information sent in response to a GET request. This method can be 687 used for obtaining metadata about the representation implied by the 688 request without transferring the representation body. This method is 689 often used for testing hypertext links for validity, accessibility, 690 and recent modification. 692 The response to a HEAD request is cacheable and MAY be used to 693 satisfy a subsequent HEAD request; see [Part6]. It also MAY be used 694 to update a previously cached representation from that resource; if 695 the new field values indicate that the cached representation differs 696 from the current representation (as would be indicated by a change in 697 Content-Length, Content-MD5, ETag or Last-Modified), then the cache 698 MUST treat the cache entry as stale. 700 7.5. POST 702 The POST method is used to request that the origin server accept the 703 representation enclosed in the request as data to be processed by the 704 target resource. POST is designed to allow a uniform method to cover 705 the following functions: 707 o Annotation of existing resources; 709 o Posting a message to a bulletin board, newsgroup, mailing list, or 710 similar group of articles; 712 o Providing a block of data, such as the result of submitting a 713 form, to a data-handling process; 715 o Extending a database through an append operation. 717 The actual function performed by the POST method is determined by the 718 server and is usually dependent on the effective request URI. 720 The action performed by the POST method might not result in a 721 resource that can be identified by a URI. In this case, either 200 722 (OK) or 204 (No Content) is the appropriate response status code, 723 depending on whether or not the response includes a representation 724 that describes the result. 726 If a resource has been created on the origin server, the response 727 SHOULD be 201 (Created) and contain a representation which describes 728 the status of the request and refers to the new resource, and a 729 Location header (see Section 9.4). 731 Responses to POST requests are only cacheable when they include 732 explicit freshness information (see Section 2.3.1 of [Part6]). A 733 cached POST response with a Content-Location header (see Section 6.7 734 of [Part3]) whose value is the effective Request URI MAY be used to 735 satisfy subsequent GET and HEAD requests. 737 Note that POST caching is not widely implemented. However, the 303 738 (See Other) response can be used to direct the user agent to retrieve 739 a cacheable resource. 741 7.6. PUT 743 The PUT method requests that the enclosed representation be stored at 744 the effective request URI. If the effective request URI refers to an 745 already existing resource, the enclosed representation SHOULD be 746 considered a modified version of the one residing on the origin 747 server. Otherwise, if the effective request URI does not point to an 748 existing resource, and that URI is capable of being defined as a new 749 resource by the requesting user agent, the origin server can create 750 the resource with that URI. 752 If a new resource is created at the effective request URI, the origin 753 server MUST inform the user agent via the 201 (Created) response. If 754 an existing resource is modified, either the 200 (OK) or 204 (No 755 Content) response codes SHOULD be sent to indicate successful 756 completion of the request. 758 If the target resource could not be created or modified, an 759 appropriate error response SHOULD be given that reflects the nature 760 of the problem. The recipient of the representation MUST NOT ignore 761 any Content-* headers (headers starting with the prefix "Content-") 762 that it does not understand or implement and MUST return a 501 (Not 763 Implemented) response in such cases. 765 If the request passes through a cache that has one or more stored 766 responses for the effective request URI, those stored responses 767 SHOULD be marked as stale if the response to the PUT request has a 768 success status code. Responses to the PUT method are not cacheable. 770 The fundamental difference between the POST and PUT requests is 771 reflected in the different meaning of the effective request URI. The 772 URI in a POST request identifies the resource that will handle the 773 enclosed representation. That resource might be a data-accepting 774 process, a gateway to some other protocol, or a document that accepts 775 annotations. In contrast, the URI in a PUT request identifies the 776 resource for which enclosed representation is a new or replacement 777 value; the user agent knows what URI is intended and the server MUST 778 NOT attempt to apply the request to some other resource. If the 779 server desires that the request be applied to a different URI, it 780 MUST send a 301 (Moved Permanently) response; the user agent MAY then 781 make its own decision regarding whether or not to redirect the 782 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 Header fields in a PUT request that are recognized as representation 794 metadata SHOULD be applied to the resource created or modified by the 795 PUT. Unrecognized header fields SHOULD be ignored. 797 7.7. DELETE 799 The DELETE method requests that the origin server delete the target 800 resource. This method MAY be overridden by human intervention (or 801 other means) on the origin server. The client cannot be guaranteed 802 that the operation has been carried out, even if the status code 803 returned from the origin server indicates that the action has been 804 completed successfully. However, the server SHOULD NOT indicate 805 success unless, at the time the response is given, it intends to 806 delete the resource or move it to an inaccessible location. 808 A successful response SHOULD be 200 (OK) if the response includes an 809 representation describing the status, 202 (Accepted) if the action 810 has not yet been enacted, or 204 (No Content) if the action has been 811 enacted but the response does not include a representation. 813 If the request passes through a cache and the effective request URI 814 identifies one or more currently cached representations, those 815 entries SHOULD be treated as stale. Responses to the DELETE method 816 are not cacheable. 818 7.8. TRACE 820 The TRACE method is used to invoke a remote, application-layer loop- 821 back of the request message. The final recipient of the request 822 SHOULD reflect the message received back to the client as the 823 message-body of a 200 (OK) response. The final recipient is either 824 the origin server or the first proxy or gateway to receive a Max- 825 Forwards value of zero (0) in the request (see Section 9.5). A TRACE 826 request MUST NOT include a message-body. 828 TRACE allows the client to see what is being received at the other 829 end of the request chain and use that data for testing or diagnostic 830 information. The value of the Via header field (Section 9.9 of 831 [Part1]) is of particular interest, since it acts as a trace of the 832 request chain. Use of the Max-Forwards header field allows the 833 client to limit the length of the request chain, which is useful for 834 testing a chain of proxies forwarding messages in an infinite loop. 836 If the request is valid, the response SHOULD have a Content-Type of 837 "message/http" (see Section 10.3.1 of [Part1]) and contain a message- 838 body that encloses a copy of the entire request message. Responses 839 to the TRACE method are not cacheable. 841 7.9. CONNECT 843 This specification reserves the method name CONNECT for use with a 844 proxy that can dynamically switch to being a tunnel (e.g., SSL 845 tunneling [RFC2817]). 847 8. Status Code Definitions 849 Each Status-Code is described below, including any metadata required 850 in the response. 852 8.1. Informational 1xx 854 This class of status code indicates a provisional response, 855 consisting only of the Status-Line and optional headers, and is 856 terminated by an empty line. There are no required headers for this 857 class of status code. Since HTTP/1.0 did not define any 1xx status 858 codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client 859 except under experimental conditions. 861 A client MUST be prepared to accept one or more 1xx status responses 862 prior to a regular response, even if the client does not expect a 100 863 (Continue) status message. Unexpected 1xx status responses MAY be 864 ignored by a user agent. 866 Proxies MUST forward 1xx responses, unless the connection between the 867 proxy and its client has been closed, or unless the proxy itself 868 requested the generation of the 1xx response. (For example, if a 869 proxy adds a "Expect: 100-continue" field when it forwards a request, 870 then it need not forward the corresponding 100 (Continue) 871 response(s).) 873 8.1.1. 100 Continue 875 The client SHOULD continue with its request. This interim response 876 is used to inform the client that the initial part of the request has 877 been received and has not yet been rejected by the server. The 878 client SHOULD continue by sending the remainder of the request or, if 879 the request has already been completed, ignore this response. The 880 server MUST send a final response after the request has been 881 completed. See Section 7.2.3 of [Part1] for detailed discussion of 882 the use and handling of this status code. 884 8.1.2. 101 Switching Protocols 886 The server understands and is willing to comply with the client's 887 request, via the Upgrade message header field (Section 9.8 of 888 [Part1]), for a change in the application protocol being used on this 889 connection. The server will switch protocols to those defined by the 890 response's Upgrade header field immediately after the empty line 891 which terminates the 101 response. 893 The protocol SHOULD be switched only when it is advantageous to do 894 so. For example, switching to a newer version of HTTP is 895 advantageous over older versions, and switching to a real-time, 896 synchronous protocol might be advantageous when delivering resources 897 that use such features. 899 8.2. Successful 2xx 901 This class of status code indicates that the client's request was 902 successfully received, understood, and accepted. 904 8.2.1. 200 OK 906 The request has succeeded. The payload returned with the response is 907 dependent on the method used in the request, for example: 909 GET a representation of the target resource is sent in the response; 911 HEAD the same representation as GET, except without the message- 912 body; 914 POST a representation describing or containing the result of the 915 action; 917 TRACE a representation containing the request message as received by 918 the end server. 920 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 921 determine freshness for 200 responses. 923 8.2.2. 201 Created 925 The request has been fulfilled and has resulted in a new resource 926 being created. The newly created resource can be referenced by the 927 URI(s) returned in the payload of the response, with the most 928 specific URI for the resource given by a Location header field. The 929 response SHOULD include a payload containing a list of resource 930 characteristics and location(s) from which the user or user agent can 931 choose the one most appropriate. The payload format is specified by 932 the media type given in the Content-Type header field. The origin 933 server MUST create the resource before returning the 201 status code. 934 If the action cannot be carried out immediately, the server SHOULD 935 respond with 202 (Accepted) response instead. 937 A 201 response MAY contain an ETag response header field indicating 938 the current value of the entity-tag for the representation of the 939 resource just created (see Section 6.1 of [Part4]). 941 8.2.3. 202 Accepted 943 The request has been accepted for processing, but the processing has 944 not been completed. The request might or might not eventually be 945 acted upon, as it might be disallowed when processing actually takes 946 place. There is no facility for re-sending a status code from an 947 asynchronous operation such as this. 949 The 202 response is intentionally non-committal. Its purpose is to 950 allow a server to accept a request for some other process (perhaps a 951 batch-oriented process that is only run once per day) without 952 requiring that the user agent's connection to the server persist 953 until the process is completed. The representation returned with 954 this response SHOULD include an indication of the request's current 955 status and either a pointer to a status monitor or some estimate of 956 when the user can expect the request to be fulfilled. 958 8.2.4. 203 Non-Authoritative Information 960 The returned metadata in the header fields is not the definitive set 961 as available from the origin server, but is gathered from a local or 962 a third-party copy. The set presented MAY be a subset or superset of 963 the original version. For example, including local annotation 964 information about the resource might result in a superset of the 965 metadata known by the origin server. Use of this response code is 966 not required and is only appropriate when the response would 967 otherwise be 200 (OK). 969 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 970 determine freshness for 203 responses. 972 8.2.5. 204 No Content 974 The server has successfully fulfilled the request, but there is no 975 additional content to return in the response payload body. The 976 resource metadata and representation metadata in the response 977 message's header fields refer to the target resource and its current 978 representation, respectively, after the requested action. For 979 example, if a 204 status code is received in response to a PUT and 980 the response contains an ETag header field, then the value of that 981 field is the current entity-tag for the representation that was 982 successfully PUT. 984 If the client is a user agent, it SHOULD NOT change its document view 985 from that which caused the request to be sent. This response is 986 primarily intended to allow input for actions to take place without 987 causing a change to the user agent's active document view, although 988 any new or updated metadata SHOULD be applied to the document 989 currently in the user agent's active view. 991 The 204 response MUST NOT include a message-body, and thus is always 992 terminated by the first empty line after the header fields. 994 8.2.6. 205 Reset Content 996 The server has fulfilled the request and the user agent SHOULD reset 997 the document view which caused the request to be sent. This response 998 is primarily intended to allow input for actions to take place via 999 user input, followed by a clearing of the form in which the input is 1000 given so that the user can easily initiate another input action. The 1001 response MUST NOT include a message-body. 1003 8.2.7. 206 Partial Content 1005 The server has fulfilled the partial GET request for the resource and 1006 the enclosed payload is a partial representation as defined in 1007 Section 3.1 of [Part5]. 1009 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1010 determine freshness for 206 responses. 1012 8.3. Redirection 3xx 1014 This class of status code indicates that further action needs to be 1015 taken by the user agent in order to fulfill the request. The action 1016 required MAY be carried out by the user agent without interaction 1017 with the user if and only if the method used in the second request is 1018 known to be "safe", as defined in Section 7.1.1. A client SHOULD 1019 detect infinite redirection loops, since such loops generate network 1020 traffic for each redirection. 1022 Note: An earlier version of this specification recommended a 1023 maximum of five redirections ([RFC2068], Section 10.3). Content 1024 developers need to be aware that some clients might implement such 1025 a fixed limitation. 1027 8.3.1. 300 Multiple Choices 1029 The target resource more than one representation, each with its own 1030 specific location, and agent-driven negotiation information (Section 1031 5 of [Part3]) is being provided so that the user (or user agent) can 1032 select a preferred representation by redirecting its request to that 1033 location. 1035 Unless it was a HEAD request, the response SHOULD include a 1036 representation containing a list of representation metadata and 1037 location(s) from which the user or user agent can choose the one most 1038 appropriate. The data format is specified by the media type given in 1039 the Content-Type header field. Depending upon the format and the 1040 capabilities of the user agent, selection of the most appropriate 1041 choice MAY be performed automatically. However, this specification 1042 does not define any standard for such automatic selection. 1044 If the server has a preferred choice of representation, it SHOULD 1045 include the specific URI for that representation in the Location 1046 field; user agents MAY use the Location field value for automatic 1047 redirection. 1049 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1050 determine freshness for 300 responses. 1052 8.3.2. 301 Moved Permanently 1054 The target resource has been assigned a new permanent URI and any 1055 future references to this resource SHOULD use one of the returned 1056 URIs. Clients with link editing capabilities ought to automatically 1057 re-link references to the effective request URI to one or more of the 1058 new references returned by the server, where possible. 1060 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1061 determine freshness for 301 responses. 1063 The new permanent URI SHOULD be given by the Location field in the 1064 response. Unless the request method was HEAD, the representation of 1065 the response SHOULD contain a short hypertext note with a hyperlink 1066 to the new URI(s). 1068 If the 301 status code is received in response to a request method 1069 that is known to be "safe", as defined in Section 7.1.1, then the 1070 request MAY be automatically redirected by the user agent without 1071 confirmation. Otherwise, the user agent MUST NOT automatically 1072 redirect the request unless it can be confirmed by the user, since 1073 this might change the conditions under which the request was issued. 1075 Note: When automatically redirecting a POST request after 1076 receiving a 301 status code, some existing HTTP/1.0 user agents 1077 will erroneously change it into a GET request. 1079 8.3.3. 302 Found 1081 The target resource resides temporarily under a different URI. Since 1082 the redirection might be altered on occasion, the client SHOULD 1083 continue to use the effective request URI for future requests. 1085 The temporary URI SHOULD be given by the Location field in the 1086 response. Unless the request method was HEAD, the representation of 1087 the response SHOULD contain a short hypertext note with a hyperlink 1088 to the new URI(s). 1090 If the 302 status code is received in response to a request method 1091 that is known to be "safe", as defined in Section 7.1.1, then the 1092 request MAY be automatically redirected by the user agent without 1093 confirmation. Otherwise, the user agent MUST NOT automatically 1094 redirect the request unless it can be confirmed by the user, since 1095 this might change the conditions under which the request was issued. 1097 Note: HTTP/1.0 ([RFC1945], Section 9.3) and the first version of 1098 HTTP/1.1 ([RFC2068], Section 10.3.3) specify that the client is 1099 not allowed to change the method on the redirected request. 1100 However, most existing user agent implementations treat 302 as if 1101 it were a 303 response, performing a GET on the Location field- 1102 value regardless of the original request method. Therefore, a 1103 previous version of this specification ([RFC2616], Section 10.3.3) 1104 has added the status codes 303 and 307 for servers that wish to 1105 make unambiguously clear which kind of reaction is expected of the 1106 client. 1108 8.3.4. 303 See Other 1110 The server directs the user agent to a different resource, indicated 1111 by a URI in the Location header field, that provides an indirect 1112 response to the original request. The user agent MAY perform a GET 1113 request on the URI in the Location field in order to obtain a 1114 representation corresponding to the response, be redirected again, or 1115 end with an error status. The Location URI is not a substitute 1116 reference for the effective request URI. 1118 The 303 status code is generally applicable to any HTTP method. It 1119 is primarily used to allow the output of a POST action to redirect 1120 the user agent to a selected resource, since doing so provides the 1121 information corresponding to the POST response in a form that can be 1122 separately identified, bookmarked, and cached independent of the 1123 original request. 1125 A 303 response to a GET request indicates that the requested resource 1126 does not have a representation of its own that can be transferred by 1127 the server over HTTP. The Location URI indicates a resource that is 1128 descriptive of the target resource, such that the follow-on 1129 representation might be useful to recipients without implying that it 1130 adequately represents the target resource. Note that answers to the 1131 questions of what can be represented, what representations are 1132 adequate, and what might be a useful description are outside the 1133 scope of HTTP and thus entirely determined by the URI owner(s). 1135 Except for responses to a HEAD request, the representation of a 303 1136 response SHOULD contain a short hypertext note with a hyperlink to 1137 the Location URI. 1139 8.3.5. 304 Not Modified 1141 The response to the request has not been modified since the 1142 conditions indicated by the client's conditional GET request, as 1143 defined in Section 3.1 of [Part4]. 1145 8.3.6. 305 Use Proxy 1147 The 305 status code was defined in a previous version of this 1148 specification (see Appendix A), and is now deprecated. 1150 8.3.7. 306 (Unused) 1152 The 306 status code was used in a previous version of the 1153 specification, is no longer used, and the code is reserved. 1155 8.3.8. 307 Temporary Redirect 1157 The target resource resides temporarily under a different URI. Since 1158 the redirection can change over time, the client SHOULD continue to 1159 use the effective request URI for future requests. 1161 The temporary URI SHOULD be given by the Location field in the 1162 response. Unless the request method was HEAD, the representation of 1163 the response SHOULD contain a short hypertext note with a hyperlink 1164 to the new URI(s) , since many pre-HTTP/1.1 user agents do not 1165 understand the 307 status code. Therefore, the note SHOULD contain 1166 the information necessary for a user to repeat the original request 1167 on the new URI. 1169 If the 307 status code is received in response to a request method 1170 that is known to be "safe", as defined in Section 7.1.1, then the 1171 request MAY be automatically redirected by the user agent without 1172 confirmation. Otherwise, the user agent MUST NOT automatically 1173 redirect the request unless it can be confirmed by the user, since 1174 this might change the conditions under which the request was issued. 1176 8.4. Client Error 4xx 1178 The 4xx class of status code is intended for cases in which the 1179 client seems to have erred. Except when responding to a HEAD 1180 request, the server SHOULD include a representation containing an 1181 explanation of the error situation, and whether it is a temporary or 1182 permanent condition. These status codes are applicable to any 1183 request method. User agents SHOULD display any included 1184 representation to the user. 1186 If the client is sending data, a server implementation using TCP 1187 SHOULD be careful to ensure that the client acknowledges receipt of 1188 the packet(s) containing the response, before the server closes the 1189 input connection. If the client continues sending data to the server 1190 after the close, the server's TCP stack will send a reset packet to 1191 the client, which might erase the client's unacknowledged input 1192 buffers before they can be read and interpreted by the HTTP 1193 application. 1195 8.4.1. 400 Bad Request 1197 The request could not be understood by the server due to malformed 1198 syntax. The client SHOULD NOT repeat the request without 1199 modifications. 1201 8.4.2. 401 Unauthorized 1203 The request requires user authentication (see Section 2.1 of 1204 [Part7]). 1206 8.4.3. 402 Payment Required 1208 This code is reserved for future use. 1210 8.4.4. 403 Forbidden 1212 The server understood the request, but is refusing to fulfill it. 1213 Authorization will not help and the request SHOULD NOT be repeated. 1214 If the request method was not HEAD and the server wishes to make 1215 public why the request has not been fulfilled, it SHOULD describe the 1216 reason for the refusal in the representation. If the server does not 1217 wish to make this information available to the client, the status 1218 code 404 (Not Found) can be used instead. 1220 8.4.5. 404 Not Found 1222 The server has not found anything matching the effective request URI. 1223 No indication is given of whether the condition is temporary or 1224 permanent. The 410 (Gone) status code SHOULD be used if the server 1225 knows, through some internally configurable mechanism, that an old 1226 resource is permanently unavailable and has no forwarding address. 1227 This status code is commonly used when the server does not wish to 1228 reveal exactly why the request has been refused, or when no other 1229 response is applicable. 1231 8.4.6. 405 Method Not Allowed 1233 The method specified in the Request-Line is not allowed for the 1234 target resource. The response MUST include an Allow header 1235 containing a list of valid methods for the requested resource. 1237 8.4.7. 406 Not Acceptable 1239 The resource identified by the request is only capable of generating 1240 response representations which have content characteristics not 1241 acceptable according to the accept headers sent in the request. 1243 Unless it was a HEAD request, the response SHOULD include a 1244 representation containing a list of available representation 1245 characteristics and location(s) from which the user or user agent can 1246 choose the one most appropriate. The data format is specified by the 1247 media type given in the Content-Type header field. Depending upon 1248 the format and the capabilities of the user agent, selection of the 1249 most appropriate choice MAY be performed automatically. However, 1250 this specification does not define any standard for such automatic 1251 selection. 1253 Note: HTTP/1.1 servers are allowed to return responses which are 1254 not acceptable according to the accept headers sent in the 1255 request. In some cases, this might even be preferable to sending 1256 a 406 response. User agents are encouraged to inspect the headers 1257 of an incoming response to determine if it is acceptable. 1259 If the response could be unacceptable, a user agent SHOULD 1260 temporarily stop receipt of more data and query the user for a 1261 decision on further actions. 1263 8.4.8. 407 Proxy Authentication Required 1265 This code is similar to 401 (Unauthorized), but indicates that the 1266 client must first authenticate itself with the proxy (see Section 2.2 1267 of [Part7]). 1269 8.4.9. 408 Request Timeout 1271 The client did not produce a request within the time that the server 1272 was prepared to wait. The client MAY repeat the request without 1273 modifications at any later time. 1275 8.4.10. 409 Conflict 1277 The request could not be completed due to a conflict with the current 1278 state of the resource. This code is only allowed in situations where 1279 it is expected that the user might be able to resolve the conflict 1280 and resubmit the request. The response body SHOULD include enough 1281 information for the user to recognize the source of the conflict. 1282 Ideally, the response representation would include enough information 1283 for the user or user agent to fix the problem; however, that might 1284 not be possible and is not required. 1286 Conflicts are most likely to occur in response to a PUT request. For 1287 example, if versioning were being used and the representation being 1288 PUT included changes to a resource which conflict with those made by 1289 an earlier (third-party) request, the server might use the 409 1290 response to indicate that it can't complete the request. In this 1291 case, the response representation would likely contain a list of the 1292 differences between the two versions in a format defined by the 1293 response Content-Type. 1295 8.4.11. 410 Gone 1297 The target resource is no longer available at the server and no 1298 forwarding address is known. This condition is expected to be 1299 considered permanent. Clients with link editing capabilities SHOULD 1300 delete references to the effective request URI after user approval. 1301 If the server does not know, or has no facility to determine, whether 1302 or not the condition is permanent, the status code 404 (Not Found) 1303 SHOULD be used instead. 1305 The 410 response is primarily intended to assist the task of web 1306 maintenance by notifying the recipient that the resource is 1307 intentionally unavailable and that the server owners desire that 1308 remote links to that resource be removed. Such an event is common 1309 for limited-time, promotional services and for resources belonging to 1310 individuals no longer working at the server's site. It is not 1311 necessary to mark all permanently unavailable resources as "gone" or 1312 to keep the mark for any length of time -- that is left to the 1313 discretion of the server owner. 1315 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to 1316 determine freshness for 410 responses. 1318 8.4.12. 411 Length Required 1320 The server refuses to accept the request without a defined Content- 1321 Length. The client MAY repeat the request if it adds a valid 1322 Content-Length header field containing the length of the message-body 1323 in the request message. 1325 8.4.13. 412 Precondition Failed 1327 The precondition given in one or more of the request-header fields 1328 evaluated to false when it was tested on the server, as defined in 1329 Section 3.2 of [Part4]. 1331 8.4.14. 413 Request Entity Too Large 1333 The server is refusing to process a request because the request 1334 representation is larger than the server is willing or able to 1335 process. The server MAY close the connection to prevent the client 1336 from continuing the request. 1338 If the condition is temporary, the server SHOULD include a Retry- 1339 After header field to indicate that it is temporary and after what 1340 time the client MAY try again. 1342 8.4.15. 414 URI Too Long 1344 The server is refusing to service the request because the effective 1345 request URI is longer than the server is willing to interpret. This 1346 rare condition is only likely to occur when a client has improperly 1347 converted a POST request to a GET request with long query 1348 information, when the client has descended into a URI "black hole" of 1349 redirection (e.g., a redirected URI prefix that points to a suffix of 1350 itself), or when the server is under attack by a client attempting to 1351 exploit security holes present in some servers using fixed-length 1352 buffers for reading or manipulating the effective request URI. 1354 8.4.16. 415 Unsupported Media Type 1356 The server is refusing to service the request because the 1357 representation of the request is in a format not supported by the 1358 target resource for the requested method. 1360 8.4.17. 416 Requested Range Not Satisfiable 1362 The request included a Range request-header field (Section 5.4 of 1363 [Part5]) and none of the range-specifier values in this field overlap 1364 the current extent of the selected resource. See Section 3.2 of 1365 [Part5]. 1367 8.4.18. 417 Expectation Failed 1369 The expectation given in an Expect request-header field (see 1370 Section 9.2) could not be met by this server, or, if the server is a 1371 proxy, the server has unambiguous evidence that the request could not 1372 be met by the next-hop server. 1374 8.5. Server Error 5xx 1376 Response status codes beginning with the digit "5" indicate cases in 1377 which the server is aware that it has erred or is incapable of 1378 performing the request. Except when responding to a HEAD request, 1379 the server SHOULD include a representation containing an explanation 1380 of the error situation, and whether it is a temporary or permanent 1381 condition. User agents SHOULD display any included representation to 1382 the user. These response codes are applicable to any request method. 1384 8.5.1. 500 Internal Server Error 1386 The server encountered an unexpected condition which prevented it 1387 from fulfilling the request. 1389 8.5.2. 501 Not Implemented 1391 The server does not support the functionality required to fulfill the 1392 request. This is the appropriate response when the server does not 1393 recognize the request method and is not capable of supporting it for 1394 any resource. 1396 8.5.3. 502 Bad Gateway 1398 The server, while acting as a gateway or proxy, received an invalid 1399 response from the upstream server it accessed in attempting to 1400 fulfill the request. 1402 8.5.4. 503 Service Unavailable 1404 The server is currently unable to handle the request due to a 1405 temporary overloading or maintenance of the server. The implication 1406 is that this is a temporary condition which will be alleviated after 1407 some delay. If known, the length of the delay MAY be indicated in a 1408 Retry-After header. If no Retry-After is given, the client SHOULD 1409 handle the response as it would for a 500 response. 1411 Note: The existence of the 503 status code does not imply that a 1412 server must use it when becoming overloaded. Some servers might 1413 wish to simply refuse the connection. 1415 8.5.5. 504 Gateway Timeout 1417 The server, while acting as a gateway or proxy, did not receive a 1418 timely response from the upstream server specified by the URI (e.g., 1419 HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed 1420 to access in attempting to complete the request. 1422 Note to implementors: some deployed proxies are known to return 1423 400 or 500 when DNS lookups time out. 1425 8.5.6. 505 HTTP Version Not Supported 1427 The server does not support, or refuses to support, the protocol 1428 version that was used in the request message. The server is 1429 indicating that it is unable or unwilling to complete the request 1430 using the same major version as the client, as described in Section 1431 2.5 of [Part1], other than with this error message. The response 1432 SHOULD contain a representation describing why that version is not 1433 supported and what other protocols are supported by that server. 1435 9. Header Field Definitions 1437 This section defines the syntax and semantics of HTTP/1.1 header 1438 fields related to request and response semantics. 1440 9.1. Allow 1442 The "Allow" response-header field lists the set of methods advertised 1443 as supported by the target resource. The purpose of this field is 1444 strictly to inform the recipient of valid methods associated with the 1445 resource. 1447 Allow = "Allow" ":" OWS Allow-v 1448 Allow-v = #Method 1450 Example of use: 1452 Allow: GET, HEAD, PUT 1454 The actual set of allowed methods is defined by the origin server at 1455 the time of each request. 1457 A proxy MUST NOT modify the Allow header field even if it does not 1458 understand all the methods specified, since the user agent might have 1459 other means of communicating with the origin server. 1461 9.2. Expect 1463 The "Expect" request-header field is used to indicate that particular 1464 server behaviors are required by the client. 1466 Expect = "Expect" ":" OWS Expect-v 1467 Expect-v = 1#expectation 1469 expectation = "100-continue" / expectation-extension 1470 expectation-extension = token [ "=" ( token / quoted-string ) 1471 *expect-params ] 1472 expect-params = ";" token [ "=" ( token / quoted-string ) ] 1474 A server that does not understand or is unable to comply with any of 1475 the expectation values in the Expect field of a request MUST respond 1476 with appropriate error status code. The server MUST respond with a 1477 417 (Expectation Failed) status code if any of the expectations 1478 cannot be met or, if there are other problems with the request, some 1479 other 4xx status code. 1481 This header field is defined with extensible syntax to allow for 1482 future extensions. If a server receives a request containing an 1483 Expect field that includes an expectation-extension that it does not 1484 support, it MUST respond with a 417 (Expectation Failed) status code. 1486 Comparison of expectation values is case-insensitive for unquoted 1487 tokens (including the 100-continue token), and is case-sensitive for 1488 quoted-string expectation-extensions. 1490 The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST 1491 return a 417 (Expectation Failed) status code if it receives a 1492 request with an expectation that it cannot meet. However, the Expect 1493 request-header itself is end-to-end; it MUST be forwarded if the 1494 request is forwarded. 1496 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the 1497 Expect header. 1499 See Section 7.2.3 of [Part1] for the use of the 100 (Continue) status 1500 code. 1502 9.3. From 1504 The "From" request-header field, if given, SHOULD contain an Internet 1505 e-mail address for the human user who controls the requesting user 1506 agent. The address SHOULD be machine-usable, as defined by "mailbox" 1507 in Section 3.4 of [RFC5322]: 1509 From = "From" ":" OWS From-v 1510 From-v = mailbox 1512 mailbox = 1514 An example is: 1516 From: webmaster@example.org 1518 This header field MAY be used for logging purposes and as a means for 1519 identifying the source of invalid or unwanted requests. It SHOULD 1520 NOT be used as an insecure form of access protection. The 1521 interpretation of this field is that the request is being performed 1522 on behalf of the person given, who accepts responsibility for the 1523 method performed. In particular, robot agents SHOULD include this 1524 header so that the person responsible for running the robot can be 1525 contacted if problems occur on the receiving end. 1527 The Internet e-mail address in this field MAY be separate from the 1528 Internet host which issued the request. For example, when a request 1529 is passed through a proxy the original issuer's address SHOULD be 1530 used. 1532 The client SHOULD NOT send the From header field without the user's 1533 approval, as it might conflict with the user's privacy interests or 1534 their site's security policy. It is strongly recommended that the 1535 user be able to disable, enable, and modify the value of this field 1536 at any time prior to a request. 1538 9.4. Location 1540 The "Location" response-header field is used to identify a newly 1541 created resource, or to redirect the recipient to a different 1542 location for completion of the request. 1544 For 201 (Created) responses, the Location is the URI of the new 1545 resource which was created by the request. For 3xx responses, the 1546 location SHOULD indicate the server's preferred URI for automatic 1547 redirection to the resource. 1549 The field value consists of a single URI-reference. When it has the 1550 form of a relative reference ([RFC3986], Section 4.2), the final 1551 value is computed by resolving it against the effective request URI 1552 ([RFC3986], Section 5). 1554 Location = "Location" ":" OWS Location-v 1555 Location-v = URI-reference 1557 Examples are: 1559 Location: http://www.example.org/pub/WWW/People.html#tim 1561 Location: /index.html 1563 There are circumstances in which a fragment identifier in a Location 1564 URI would not be appropriate: 1566 o With a 201 Created response, because in this usage the Location 1567 header specifies the URI for the entire created resource. 1569 o With 305 Use Proxy. 1571 Note: This specification does not define precedence rules for the 1572 case where the original URI, as navigated to by the user agent, 1573 and the Location header field value both contain fragment 1574 identifiers. 1576 Note: The Content-Location header field (Section 6.7 of [Part3]) 1577 differs from Location in that the Content-Location identifies the 1578 most specific resource corresponding to the enclosed 1579 representation. It is therefore possible for a response to 1580 contain header fields for both Location and Content-Location. 1582 9.5. Max-Forwards 1584 The "Max-Forwards" request-header field provides a mechanism with the 1585 TRACE (Section 7.8) and OPTIONS (Section 7.2) methods to limit the 1586 number of times that the request is forwarded by proxies or gateways. 1587 This can be useful when the client is attempting to trace a request 1588 which appears to be failing or looping in mid-chain. 1590 Max-Forwards = "Max-Forwards" ":" OWS Max-Forwards-v 1591 Max-Forwards-v = 1*DIGIT 1593 The Max-Forwards value is a decimal integer indicating the remaining 1594 number of times this request message can be forwarded. 1596 Each proxy or gateway recipient of a TRACE or OPTIONS request 1597 containing a Max-Forwards header field MUST check and update its 1598 value prior to forwarding the request. If the received value is zero 1599 (0), the recipient MUST NOT forward the request; instead, it MUST 1600 respond as the final recipient. If the received Max-Forwards value 1601 is greater than zero, then the forwarded message MUST contain an 1602 updated Max-Forwards field with a value decremented by one (1). 1604 The Max-Forwards header field MAY be ignored for all other methods 1605 defined by this specification and for any extension methods for which 1606 it is not explicitly referred to as part of that method definition. 1608 9.6. Referer 1610 The "Referer" [sic] request-header field allows the client to specify 1611 the URI of the resource from which the effective request URI was 1612 obtained (the "referrer", although the header field is misspelled.). 1614 The Referer header allows servers to generate lists of back-links to 1615 resources for interest, logging, optimized caching, etc. It also 1616 allows obsolete or mistyped links to be traced for maintenance. Some 1617 servers use Referer as a means of controlling where they allow links 1618 from (so-called "deep linking"), but legitimate requests do not 1619 always contain a Referer header field. 1621 If the effective request URI was obtained from a source that does not 1622 have its own URI (e.g., input from the user keyboard), the Referer 1623 field MUST either be sent with the value "about:blank", or not be 1624 sent at all. Note that this requirement does not apply to sources 1625 with non-HTTP URIs (e.g., FTP). 1627 Referer = "Referer" ":" OWS Referer-v 1628 Referer-v = absolute-URI / partial-URI 1630 Example: 1632 Referer: http://www.example.org/hypertext/Overview.html 1634 If the field value is a relative URI, it SHOULD be interpreted 1635 relative to the effective request URI. The URI MUST NOT include a 1636 fragment. See Section 11.2 for security considerations. 1638 9.7. Retry-After 1640 The response-header "Retry-After" field can be used with a 503 1641 (Service Unavailable) response to indicate how long the service is 1642 expected to be unavailable to the requesting client. This field MAY 1643 also be used with any 3xx (Redirection) response to indicate the 1644 minimum time the user-agent is asked wait before issuing the 1645 redirected request. 1647 The value of this field can be either an HTTP-date or an integer 1648 number of seconds (in decimal) after the time of the response. 1650 Retry-After = "Retry-After" ":" OWS Retry-After-v 1651 Retry-After-v = HTTP-date / delta-seconds 1653 Time spans are non-negative decimal integers, representing time in 1654 seconds. 1656 delta-seconds = 1*DIGIT 1658 Two examples of its use are 1660 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 1661 Retry-After: 120 1663 In the latter example, the delay is 2 minutes. 1665 9.8. Server 1667 The "Server" response-header field contains information about the 1668 software used by the origin server to handle the request. 1670 The field can contain multiple product tokens (Section 6.3 of 1671 [Part1]) and comments (Section 3.2 of [Part1]) identifying the server 1672 and any significant subproducts. The product tokens are listed in 1673 order of their significance for identifying the application. 1675 Server = "Server" ":" OWS Server-v 1676 Server-v = product 1677 *( RWS ( product / comment ) ) 1679 Example: 1681 Server: CERN/3.0 libwww/2.17 1683 If the response is being forwarded through a proxy, the proxy 1684 application MUST NOT modify the Server response-header. Instead, it 1685 MUST include a Via field (as described in Section 9.9 of [Part1]). 1687 Note: Revealing the specific software version of the server might 1688 allow the server machine to become more vulnerable to attacks 1689 against software that is known to contain security holes. Server 1690 implementors are encouraged to make this field a configurable 1691 option. 1693 9.9. User-Agent 1695 The "User-Agent" request-header field contains information about the 1696 user agent originating the request. This is for statistical 1697 purposes, the tracing of protocol violations, and automated 1698 recognition of user agents for the sake of tailoring responses to 1699 avoid particular user agent limitations. 1701 User agents SHOULD include this field with requests. The field can 1702 contain multiple product tokens (Section 6.3 of [Part1]) and comments 1703 (Section 3.2 of [Part1]) identifying the agent and any subproducts 1704 which form a significant part of the user agent. By convention, the 1705 product tokens are listed in order of their significance for 1706 identifying the application. 1708 User-Agent = "User-Agent" ":" OWS User-Agent-v 1709 User-Agent-v = product 1710 *( RWS ( product / comment ) ) 1712 Example: 1714 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1716 10. IANA Considerations 1718 10.1. Method Registry 1720 The registration procedure for HTTP Methods is defined by Section 2.1 1721 of this document. 1723 The HTTP Method Registry shall be created at 1724 and be populated with 1725 the registrations below: 1727 +---------+------+-------------+ 1728 | Method | Safe | Reference | 1729 +---------+------+-------------+ 1730 | CONNECT | no | Section 7.9 | 1731 | DELETE | no | Section 7.7 | 1732 | GET | yes | Section 7.3 | 1733 | HEAD | yes | Section 7.4 | 1734 | OPTIONS | yes | Section 7.2 | 1735 | POST | no | Section 7.5 | 1736 | PUT | no | Section 7.6 | 1737 | TRACE | yes | Section 7.8 | 1738 +---------+------+-------------+ 1740 10.2. Status Code Registry 1742 The registration procedure for HTTP Status Codes -- previously 1743 defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.1 1744 of this document. 1746 The HTTP Status Code Registry located at 1747 shall be updated 1748 with the registrations below: 1750 +-------+-------------------------------+----------------+ 1751 | Value | Description | Reference | 1752 +-------+-------------------------------+----------------+ 1753 | 100 | Continue | Section 8.1.1 | 1754 | 101 | Switching Protocols | Section 8.1.2 | 1755 | 200 | OK | Section 8.2.1 | 1756 | 201 | Created | Section 8.2.2 | 1757 | 202 | Accepted | Section 8.2.3 | 1758 | 203 | Non-Authoritative Information | Section 8.2.4 | 1759 | 204 | No Content | Section 8.2.5 | 1760 | 205 | Reset Content | Section 8.2.6 | 1761 | 300 | Multiple Choices | Section 8.3.1 | 1762 | 301 | Moved Permanently | Section 8.3.2 | 1763 | 302 | Found | Section 8.3.3 | 1764 | 303 | See Other | Section 8.3.4 | 1765 | 305 | Use Proxy | Section 8.3.6 | 1766 | 306 | (Unused) | Section 8.3.7 | 1767 | 307 | Temporary Redirect | Section 8.3.8 | 1768 | 400 | Bad Request | Section 8.4.1 | 1769 | 402 | Payment Required | Section 8.4.3 | 1770 | 403 | Forbidden | Section 8.4.4 | 1771 | 404 | Not Found | Section 8.4.5 | 1772 | 405 | Method Not Allowed | Section 8.4.6 | 1773 | 406 | Not Acceptable | Section 8.4.7 | 1774 | 407 | Proxy Authentication Required | Section 8.4.8 | 1775 | 408 | Request Timeout | Section 8.4.9 | 1776 | 409 | Conflict | Section 8.4.10 | 1777 | 410 | Gone | Section 8.4.11 | 1778 | 411 | Length Required | Section 8.4.12 | 1779 | 413 | Request Entity Too Large | Section 8.4.14 | 1780 | 414 | URI Too Long | Section 8.4.15 | 1781 | 415 | Unsupported Media Type | Section 8.4.16 | 1782 | 417 | Expectation Failed | Section 8.4.18 | 1783 | 500 | Internal Server Error | Section 8.5.1 | 1784 | 501 | Not Implemented | Section 8.5.2 | 1785 | 502 | Bad Gateway | Section 8.5.3 | 1786 | 503 | Service Unavailable | Section 8.5.4 | 1787 | 504 | Gateway Timeout | Section 8.5.5 | 1788 | 505 | HTTP Version Not Supported | Section 8.5.6 | 1789 +-------+-------------------------------+----------------+ 1791 10.3. Header Field Registration 1793 The Message Header Field Registry located at shall be 1795 updated with the permanent registrations below (see [RFC3864]): 1797 +-------------------+----------+----------+-------------+ 1798 | Header Field Name | Protocol | Status | Reference | 1799 +-------------------+----------+----------+-------------+ 1800 | Allow | http | standard | Section 9.1 | 1801 | Expect | http | standard | Section 9.2 | 1802 | From | http | standard | Section 9.3 | 1803 | Location | http | standard | Section 9.4 | 1804 | Max-Forwards | http | standard | Section 9.5 | 1805 | Referer | http | standard | Section 9.6 | 1806 | Retry-After | http | standard | Section 9.7 | 1807 | Server | http | standard | Section 9.8 | 1808 | User-Agent | http | standard | Section 9.9 | 1809 +-------------------+----------+----------+-------------+ 1811 The change controller is: "IETF (iesg@ietf.org) - Internet 1812 Engineering Task Force". 1814 11. Security Considerations 1816 This section is meant to inform application developers, information 1817 providers, and users of the security limitations in HTTP/1.1 as 1818 described by this document. The discussion does not include 1819 definitive solutions to the problems revealed, though it does make 1820 some suggestions for reducing security risks. 1822 11.1. Transfer of Sensitive Information 1824 Like any generic data transfer protocol, HTTP cannot regulate the 1825 content of the data that is transferred, nor is there any a priori 1826 method of determining the sensitivity of any particular piece of 1827 information within the context of any given request. Therefore, 1828 applications SHOULD supply as much control over this information as 1829 possible to the provider of that information. Four header fields are 1830 worth special mention in this context: Server, Via, Referer and From. 1832 Revealing the specific software version of the server might allow the 1833 server machine to become more vulnerable to attacks against software 1834 that is known to contain security holes. Implementors SHOULD make 1835 the Server header field a configurable option. 1837 Proxies which serve as a portal through a network firewall SHOULD 1838 take special precautions regarding the transfer of header information 1839 that identifies the hosts behind the firewall. In particular, they 1840 SHOULD remove, or replace with sanitized versions, any Via fields 1841 generated behind the firewall. 1843 The Referer header allows reading patterns to be studied and reverse 1844 links drawn. Although it can be very useful, its power can be abused 1845 if user details are not separated from the information contained in 1846 the Referer. Even when the personal information has been removed, 1847 the Referer header might indicate a private document's URI whose 1848 publication would be inappropriate. 1850 The information sent in the From field might conflict with the user's 1851 privacy interests or their site's security policy, and hence it 1852 SHOULD NOT be transmitted without the user being able to disable, 1853 enable, and modify the contents of the field. The user MUST be able 1854 to set the contents of this field within a user preference or 1855 application defaults configuration. 1857 We suggest, though do not require, that a convenient toggle interface 1858 be provided for the user to enable or disable the sending of From and 1859 Referer information. 1861 The User-Agent (Section 9.9) or Server (Section 9.8) header fields 1862 can sometimes be used to determine that a specific client or server 1863 have a particular security hole which might be exploited. 1864 Unfortunately, this same information is often used for other valuable 1865 purposes for which HTTP currently has no better mechanism. 1867 Some methods, like TRACE (Section 7.8), expose information that was 1868 sent in request headers within the body of their response. Clients 1869 SHOULD be careful with sensitive information, like Cookies, 1870 Authorization credentials and other headers that might be used to 1871 collect data from the client. 1873 11.2. Encoding Sensitive Information in URIs 1875 Because the source of a link might be private information or might 1876 reveal an otherwise private information source, it is strongly 1877 recommended that the user be able to select whether or not the 1878 Referer field is sent. For example, a browser client could have a 1879 toggle switch for browsing openly/anonymously, which would 1880 respectively enable/disable the sending of Referer and From 1881 information. 1883 Clients SHOULD NOT include a Referer header field in a (non-secure) 1884 HTTP request if the referring page was transferred with a secure 1885 protocol. 1887 Authors of services SHOULD NOT use GET-based forms for the submission 1888 of sensitive data because that data will be placed in the request- 1889 target. Many existing servers, proxies, and user agents log or 1890 display the request-target in places where it might be visible to 1891 third parties. Such services can use POST-based form submission 1892 instead. 1894 11.3. Location Headers and Spoofing 1896 If a single server supports multiple organizations that do not trust 1897 one another, then it MUST check the values of Location and Content- 1898 Location headers in responses that are generated under control of 1899 said organizations to make sure that they do not attempt to 1900 invalidate resources over which they have no authority. 1902 12. Acknowledgments 1904 13. References 1906 13.1. Normative References 1908 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1909 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1910 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 1911 and Message Parsing", draft-ietf-httpbis-p1-messaging-11 1912 (work in progress), August 2010. 1914 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1915 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1916 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 1917 and Content Negotiation", draft-ietf-httpbis-p3-payload-11 1918 (work in progress), August 2010. 1920 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1921 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1922 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 1923 Requests", draft-ietf-httpbis-p4-conditional-11 (work in 1924 progress), August 2010. 1926 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1927 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1928 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 1929 Partial Responses", draft-ietf-httpbis-p5-range-11 (work 1930 in progress), August 2010. 1932 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1933 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1934 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part 1935 6: Caching", draft-ietf-httpbis-p6-cache-11 (work in 1936 progress), August 2010. 1938 [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1939 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1940 and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", 1941 draft-ietf-httpbis-p7-auth-11 (work in progress), 1942 August 2010. 1944 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1945 Requirement Levels", BCP 14, RFC 2119, March 1997. 1947 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1948 Resource Identifier (URI): Generic Syntax", RFC 3986, 1949 STD 66, January 2005. 1951 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1952 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1954 13.2. Informative References 1956 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1957 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1959 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 1960 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 1961 RFC 2068, January 1997. 1963 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1964 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1965 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1967 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 1968 HTTP/1.1", RFC 2817, May 2000. 1970 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1971 Procedures for Message Header Fields", BCP 90, RFC 3864, 1972 September 2004. 1974 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1975 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1976 May 2008. 1978 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 1979 October 2008. 1981 Appendix A. Changes from RFC 2616 1983 This document takes over the Status Code Registry, previously defined 1984 in Section 7.1 of [RFC2817]. (Section 4.1) 1986 Clarify definition of POST. (Section 7.5) 1988 Failed to consider that there are many other request methods that are 1989 safe to automatically redirect, and further that the user agent is 1990 able to make that determination based on the request method 1991 semantics. (Sections 8.3.2, 8.3.3 and 8.3.8) 1993 Deprecate 305 Use Proxy status code, because user agents did not 1994 implement it. It used to indicate that the target resource must be 1995 accessed through the proxy given by the Location field. The Location 1996 field gave the URI of the proxy. The recipient was expected to 1997 repeat this single request via the proxy. (Section 8.3.6) 1999 Reclassify Allow header as response header, removing the option to 2000 specify it in a PUT request. Relax the server requirement on the 2001 contents of the Allow header and remove requirement on clients to 2002 always trust the header value. (Section 9.1) 2004 Correct syntax of Location header to allow URI references (including 2005 relative references and fragments), as referred symbol "absoluteURI" 2006 wasn't what was expected, and add some clarifications as to when use 2007 of fragments would not be appropriate. (Section 9.4) 2009 Allow Referer value of "about:blank" as alternative to not specifying 2010 it. (Section 9.6) 2012 In the description of the Server header, the Via field was described 2013 as a SHOULD. The requirement was and is stated correctly in the 2014 description of the Via header in Section 9.9 of [Part1]. 2015 (Section 9.8) 2017 Appendix B. Collected ABNF 2019 Accept = 2020 Accept-Charset = 2021 Accept-Encoding = 2022 Accept-Language = 2023 Accept-Ranges = 2024 Age = 2025 Allow = "Allow:" OWS Allow-v 2026 Allow-v = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] 2027 Authorization = 2029 ETag = 2030 Expect = "Expect:" OWS Expect-v 2031 Expect-v = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) 2033 From = "From:" OWS From-v 2034 From-v = mailbox 2036 HTTP-date = 2037 Host = 2038 If-Match = 2039 If-Modified-Since = 2040 2041 If-None-Match = 2042 If-Range = 2043 If-Unmodified-Since = 2044 2046 Location = "Location:" OWS Location-v 2047 Location-v = URI-reference 2049 Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v 2050 Max-Forwards-v = 1*DIGIT 2051 Method = %x4F.50.54.49.4F.4E.53 ; OPTIONS 2052 / %x47.45.54 ; GET 2053 / %x48.45.41.44 ; HEAD 2054 / %x50.4F.53.54 ; POST 2055 / %x50.55.54 ; PUT 2056 / %x44.45.4C.45.54.45 ; DELETE 2057 / %x54.52.41.43.45 ; TRACE 2058 / %x43.4F.4E.4E.45.43.54 ; CONNECT 2059 / extension-method 2061 OWS = 2063 Proxy-Authenticate = 2064 2065 Proxy-Authorization = 2066 2068 RWS = 2069 Range = 2070 Reason-Phrase = *( WSP / VCHAR / obs-text ) 2071 Referer = "Referer:" OWS Referer-v 2072 Referer-v = absolute-URI / partial-URI 2073 Retry-After = "Retry-After:" OWS Retry-After-v 2074 Retry-After-v = HTTP-date / delta-seconds 2076 Server = "Server:" OWS Server-v 2077 Server-v = product *( RWS ( product / comment ) ) 2078 Status-Code = "100" / "101" / "200" / "201" / "202" / "203" / "204" / 2079 "205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" / 2080 "307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" / 2081 "407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" / 2082 "415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" / 2083 "505" / extension-code 2085 TE = 2086 URI-reference = 2087 User-Agent = "User-Agent:" OWS User-Agent-v 2088 User-Agent-v = product *( RWS ( product / comment ) ) 2090 Vary = 2092 WWW-Authenticate = 2093 2095 absolute-URI = 2097 comment = 2099 delta-seconds = 1*DIGIT 2101 expect-params = ";" token [ "=" ( token / quoted-string ) ] 2102 expectation = "100-continue" / expectation-extension 2103 expectation-extension = token [ "=" ( token / quoted-string ) 2104 *expect-params ] 2105 extension-code = 3DIGIT 2106 extension-method = token 2108 mailbox = 2110 obs-text = 2112 partial-URI = 2113 product = 2115 quoted-string = 2117 request-header = Accept / Accept-Charset / Accept-Encoding / 2118 Accept-Language / Authorization / Expect / From / Host / If-Match / 2119 If-Modified-Since / If-None-Match / If-Range / If-Unmodified-Since / 2120 Max-Forwards / Proxy-Authorization / Range / Referer / TE / 2121 User-Agent 2122 response-header = Accept-Ranges / Age / Allow / ETag / Location / 2123 Proxy-Authenticate / Retry-After / Server / Vary / WWW-Authenticate 2125 token = 2127 ABNF diagnostics: 2129 ; Reason-Phrase defined but not used 2130 ; Status-Code defined but not used 2131 ; request-header defined but not used 2132 ; response-header defined but not used 2134 Appendix C. Change Log (to be removed by RFC Editor before publication) 2136 C.1. Since RFC2616 2138 Extracted relevant partitions from [RFC2616]. 2140 C.2. Since draft-ietf-httpbis-p2-semantics-00 2142 Closed issues: 2144 o : "Via is a MUST" 2145 () 2147 o : "Fragments 2148 allowed in Location" 2149 () 2151 o : "Safe Methods 2152 vs Redirection" () 2154 o : "Revise 2155 description of the POST method" 2156 () 2158 o : "Normative and 2159 Informative references" 2161 o : "RFC2606 2162 Compliance" 2164 o : "Informative 2165 references" 2167 o : "Redundant 2168 cross-references" 2170 Other changes: 2172 o Move definitions of 304 and 412 condition codes to [Part4] 2174 C.3. Since draft-ietf-httpbis-p2-semantics-01 2176 Closed issues: 2178 o : "PUT side 2179 effects" 2181 o : "Duplicate Host 2182 header requirements" 2184 Ongoing work on ABNF conversion 2185 (): 2187 o Move "Product Tokens" section (back) into Part 1, as "token" is 2188 used in the definition of the Upgrade header. 2190 o Add explicit references to BNF syntax and rules imported from 2191 other parts of the specification. 2193 o Copy definition of delta-seconds from Part6 instead of referencing 2194 it. 2196 C.4. Since draft-ietf-httpbis-p2-semantics-02 2198 Closed issues: 2200 o : "Requiring 2201 Allow in 405 responses" 2203 o : "Status Code 2204 Registry" 2206 o : "Redirection 2207 vs. Location" 2209 o : "Cacheability 2210 of 303 response" 2212 o : "305 Use Proxy" 2214 o : 2215 "Classification for Allow header" 2217 o : "PUT - 'store 2218 under' vs 'store at'" 2220 Ongoing work on IANA Message Header Registration 2221 (): 2223 o Reference RFC 3984, and update header registrations for headers 2224 defined in this document. 2226 Ongoing work on ABNF conversion 2227 (): 2229 o Replace string literals when the string really is case-sensitive 2230 (method). 2232 C.5. Since draft-ietf-httpbis-p2-semantics-03 2234 Closed issues: 2236 o : "OPTIONS 2237 request bodies" 2239 o : "Description 2240 of CONNECT should refer to RFC2817" 2242 o : "Location 2243 Content-Location reference request/response mixup" 2245 Ongoing work on Method Registry 2246 (): 2248 o Added initial proposal for registration process, plus initial 2249 content (non-HTTP/1.1 methods to be added by a separate 2250 specification). 2252 C.6. Since draft-ietf-httpbis-p2-semantics-04 2254 Closed issues: 2256 o : "Content-*" 2258 o : "RFC 2822 is 2259 updated by RFC 5322" 2261 Ongoing work on ABNF conversion 2262 (): 2264 o Use "/" instead of "|" for alternatives. 2266 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 2267 whitespace ("OWS") and required whitespace ("RWS"). 2269 o Rewrite ABNFs to spell out whitespace rules, factor out header 2270 value format definitions. 2272 C.7. Since draft-ietf-httpbis-p2-semantics-05 2274 Closed issues: 2276 o : "Reason-Phrase 2277 BNF" 2279 Final work on ABNF conversion 2280 (): 2282 o Add appendix containing collected and expanded ABNF, reorganize 2283 ABNF introduction. 2285 C.8. Since draft-ietf-httpbis-p2-semantics-06 2287 Closed issues: 2289 o : "Clarify when 2290 Referer is sent" 2292 o : "status codes 2293 vs methods" 2295 o : "Do not 2296 require "updates" relation for specs that register status codes or 2297 method names" 2299 C.9. Since draft-ietf-httpbis-p2-semantics-07 2301 Closed issues: 2303 o : "Idempotency" 2305 o : "TRACE security 2306 considerations" 2308 o : "Clarify rules 2309 for determining what entities a response carries" 2311 o : "update note 2312 citing RFC 1945 and 2068" 2314 o : "update note 2315 about redirect limit" 2317 o : "Location 2318 header ABNF should use 'URI'" 2320 o : "fragments in 2321 Location vs status 303" 2323 o : "move IANA 2324 registrations for optional status codes" 2326 Partly resolved issues: 2328 o : "Are OPTIONS 2329 and TRACE safe?" 2331 C.10. Since draft-ietf-httpbis-p2-semantics-08 2333 Closed issues: 2335 o : "Safe Methods 2336 vs Redirection" (we missed the introduction to the 3xx status 2337 codes when fixing this previously) 2339 C.11. Since draft-ietf-httpbis-p2-semantics-09 2341 Closed issues: 2343 o : "Fragment 2344 combination / precedence during redirects" 2346 Partly resolved issues: 2348 o : "Location 2349 header payload handling" 2351 o : "Term for the 2352 requested resource's URI" 2354 C.12. Since draft-ietf-httpbis-p2-semantics-10 2356 Closed issues: 2358 o : "Clarify 2359 'Requested Variant'" 2361 o : "Clarify 2362 entity / representation / variant terminology" 2364 o : "Methods and 2365 Caching" 2367 o : "OPTIONS vs 2368 Max-Forwards" 2370 o : "Status codes 2371 and caching" 2373 o : "consider 2374 removing the 'changes from 2068' sections" 2376 Index 2378 1 2379 100 Continue (status code) 20 2380 101 Switching Protocols (status code) 21 2382 2 2383 200 OK (status code) 21 2384 201 Created (status code) 21 2385 202 Accepted (status code) 22 2386 203 Non-Authoritative Information (status code) 22 2387 204 No Content (status code) 22 2388 205 Reset Content (status code) 23 2389 206 Partial Content (status code) 23 2391 3 2392 300 Multiple Choices (status code) 24 2393 301 Moved Permanently (status code) 24 2394 302 Found (status code) 25 2395 303 See Other (status code) 25 2396 304 Not Modified (status code) 26 2397 305 Use Proxy (status code) 26 2398 306 (Unused) (status code) 26 2399 307 Temporary Redirect (status code) 26 2401 4 2402 400 Bad Request (status code) 27 2403 401 Unauthorized (status code) 27 2404 402 Payment Required (status code) 27 2405 403 Forbidden (status code) 27 2406 404 Not Found (status code) 28 2407 405 Method Not Allowed (status code) 28 2408 406 Not Acceptable (status code) 28 2409 407 Proxy Authentication Required (status code) 28 2410 408 Request Timeout (status code) 29 2411 409 Conflict (status code) 29 2412 410 Gone (status code) 29 2413 411 Length Required (status code) 30 2414 412 Precondition Failed (status code) 30 2415 413 Request Entity Too Large (status code) 30 2416 414 URI Too Long (status code) 30 2417 415 Unsupported Media Type (status code) 30 2418 416 Requested Range Not Satisfiable (status code) 30 2419 417 Expectation Failed (status code) 31 2421 5 2422 500 Internal Server Error (status code) 31 2423 501 Not Implemented (status code) 31 2424 502 Bad Gateway (status code) 31 2425 503 Service Unavailable (status code) 31 2426 504 Gateway Timeout (status code) 32 2427 505 HTTP Version Not Supported (status code) 32 2429 A 2430 Allow header 32 2432 C 2433 CONNECT method 20 2435 D 2436 DELETE method 19 2438 E 2439 Expect header 33 2441 F 2442 From header 33 2444 G 2445 GET method 16 2446 Grammar 2447 Allow 32 2448 Allow-v 32 2449 delta-seconds 37 2450 Expect 33 2451 expect-params 33 2452 Expect-v 33 2453 expectation 33 2454 expectation-extension 33 2455 extension-code 11 2456 extension-method 8 2457 From 34 2458 From-v 34 2459 Location 34 2460 Location-v 34 2461 Max-Forwards 35 2462 Max-Forwards-v 35 2463 Method 8 2464 Reason-Phrase 11 2465 Referer 36 2466 Referer-v 36 2467 request-header 9 2468 response-header 12 2469 Retry-After 36 2470 Retry-After-v 36 2471 Server 37 2472 Server-v 37 2473 Status-Code 11 2474 User-Agent 38 2475 User-Agent-v 38 2477 H 2478 HEAD method 16 2479 Headers 2480 Allow 32 2481 Expect 33 2482 From 33 2483 Location 34 2484 Max-Forwards 35 2485 Referer 36 2486 Retry-After 36 2487 Server 37 2488 User-Agent 37 2490 I 2491 Idempotent Methods 14 2493 L 2494 Location header 34 2496 M 2497 Max-Forwards header 35 2498 Methods 2499 CONNECT 20 2500 DELETE 19 2501 GET 16 2502 HEAD 16 2503 OPTIONS 15 2504 POST 17 2505 PUT 18 2506 TRACE 19 2508 O 2509 OPTIONS method 15 2511 P 2512 POST method 17 2513 PUT method 18 2515 R 2516 Referer header 36 2517 Retry-After header 36 2519 S 2520 Safe Methods 14 2521 Server header 37 2522 Status Codes 2523 100 Continue 20 2524 101 Switching Protocols 21 2525 200 OK 21 2526 201 Created 21 2527 202 Accepted 22 2528 203 Non-Authoritative Information 22 2529 204 No Content 22 2530 205 Reset Content 23 2531 206 Partial Content 23 2532 300 Multiple Choices 24 2533 301 Moved Permanently 24 2534 302 Found 25 2535 303 See Other 25 2536 304 Not Modified 26 2537 305 Use Proxy 26 2538 306 (Unused) 26 2539 307 Temporary Redirect 26 2540 400 Bad Request 27 2541 401 Unauthorized 27 2542 402 Payment Required 27 2543 403 Forbidden 27 2544 404 Not Found 28 2545 405 Method Not Allowed 28 2546 406 Not Acceptable 28 2547 407 Proxy Authentication Required 28 2548 408 Request Timeout 29 2549 409 Conflict 29 2550 410 Gone 29 2551 411 Length Required 30 2552 412 Precondition Failed 30 2553 413 Request Entity Too Large 30 2554 414 URI Too Long 30 2555 415 Unsupported Media Type 30 2556 416 Requested Range Not Satisfiable 30 2557 417 Expectation Failed 31 2558 500 Internal Server Error 31 2559 501 Not Implemented 31 2560 502 Bad Gateway 31 2561 503 Service Unavailable 31 2562 504 Gateway Timeout 32 2563 505 HTTP Version Not Supported 32 2565 T 2566 TRACE method 19 2568 U 2569 User-Agent header 37 2571 Authors' Addresses 2573 Roy T. Fielding (editor) 2574 Day Software 2575 23 Corporate Plaza DR, Suite 280 2576 Newport Beach, CA 92660 2577 USA 2579 Phone: +1-949-706-5300 2580 Fax: +1-949-706-5305 2581 EMail: fielding@gbiv.com 2582 URI: http://roy.gbiv.com/ 2584 Jim Gettys 2585 Alcatel-Lucent Bell Labs 2586 21 Oak Knoll Road 2587 Carlisle, MA 01741 2588 USA 2590 EMail: jg@freedesktop.org 2591 URI: http://gettys.wordpress.com/ 2593 Jeffrey C. Mogul 2594 Hewlett-Packard Company 2595 HP Labs, Large Scale Systems Group 2596 1501 Page Mill Road, MS 1177 2597 Palo Alto, CA 94304 2598 USA 2600 EMail: JeffMogul@acm.org 2601 Henrik Frystyk Nielsen 2602 Microsoft Corporation 2603 1 Microsoft Way 2604 Redmond, WA 98052 2605 USA 2607 EMail: henrikn@microsoft.com 2609 Larry Masinter 2610 Adobe Systems, Incorporated 2611 345 Park Ave 2612 San Jose, CA 95110 2613 USA 2615 EMail: LMM@acm.org 2616 URI: http://larry.masinter.net/ 2618 Paul J. Leach 2619 Microsoft Corporation 2620 1 Microsoft Way 2621 Redmond, WA 98052 2623 EMail: paulle@microsoft.com 2625 Tim Berners-Lee 2626 World Wide Web Consortium 2627 MIT Computer Science and Artificial Intelligence Laboratory 2628 The Stata Center, Building 32 2629 32 Vassar Street 2630 Cambridge, MA 02139 2631 USA 2633 EMail: timbl@w3.org 2634 URI: http://www.w3.org/People/Berners-Lee/ 2635 Yves Lafon (editor) 2636 World Wide Web Consortium 2637 W3C / ERCIM 2638 2004, rte des Lucioles 2639 Sophia-Antipolis, AM 06902 2640 France 2642 EMail: ylafon@w3.org 2643 URI: http://www.raubacapeu.net/people/yves/ 2645 Julian F. Reschke (editor) 2646 greenbytes GmbH 2647 Hafenweg 16 2648 Muenster, NW 48155 2649 Germany 2651 Phone: +49 251 2807760 2652 Fax: +49 251 2807761 2653 EMail: julian.reschke@greenbytes.de 2654 URI: http://greenbytes.de/tech/webdav/