idnits 2.17.1 draft-ietf-httpbis-p2-semantics-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 26. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1941. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1952. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1959. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1965. 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2616]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 206: '... Product tokens SHOULD be short and t...' RFC 2119 keyword, line 208: '... token character MAY appear in a produ...' RFC 2119 keyword, line 209: '... SHOULD only be used for a version i...' RFC 2119 keyword, line 210: '...the same product SHOULD only differ in...' RFC 2119 keyword, line 233: '...An origin server SHOULD return the sta...' (162 more instances...) -- The draft header indicates that this document obsoletes RFC2068, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 20, 2007) is 5972 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'Luo1998' == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-00 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-00 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-00 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-00 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-00 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-00 ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Fielding, Ed. 3 Internet-Draft Day Software 4 Obsoletes: 2068, 2616 J. Gettys 5 (if approved) One Laptop per Child 6 Intended status: Standards Track J. Mogul 7 Expires: June 22, 2008 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 December 20, 2007 18 HTTP/1.1, part 2: Message Semantics 19 draft-ietf-httpbis-p2-semantics-00 21 Status of this Memo 23 By submitting this Internet-Draft, each author represents that any 24 applicable patent or other IPR claims of which he or she is aware 25 have been or will be disclosed, and any of which he or she becomes 26 aware will be disclosed, in accordance with Section 6 of BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on June 22, 2008. 46 Copyright Notice 48 Copyright (C) The IETF Trust (2007). 50 Abstract 52 The Hypertext Transfer Protocol (HTTP) is an application-level 53 protocol for distributed, collaborative, hypermedia information 54 systems. HTTP has been in use by the World Wide Web global 55 information initiative since 1990. This document is Part 2 of the 56 seven-part specification that defines the protocol referred to as 57 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines 58 the semantics of HTTP messages as expressed by request methods, 59 request-header fields, response status codes, and response-header 60 fields. 62 Editorial Note (To be removed by RFC Editor) 64 This version of the HTTP specification contains only minimal 65 editorial changes from [RFC2616] (abstract, introductory paragraph, 66 and authors' addresses). All other changes are due to partitioning 67 the original into seven mostly independent parts. The intent is for 68 readers of future drafts to able to use draft 00 as the basis for 69 comparison when the WG makes later changes to the specification text. 70 This draft will shortly be followed by draft 01 (containing the first 71 round of changes that have already been agreed to on the mailing 72 list). There is no point in reviewing this draft other than to 73 verify that the partitioning has been done correctly. Roy T. 74 Fielding, Yves Lafon, and Julian Reschke will be the editors after 75 draft 00 is submitted. 77 Discussion of this draft should take place on the HTTPBIS working 78 group mailing list (ietf-http-wg@w3.org). The current issues list is 79 at and related 80 documents (including fancy diffs) can be found at 81 . 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 86 2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . . . 5 87 3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 88 4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 6 89 5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 7 90 6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 9 91 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 92 8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 10 93 8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 10 94 8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 10 95 8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 10 96 8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 11 97 8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 98 8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 99 8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 100 8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 101 8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 15 102 8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 15 103 8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 16 104 9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 16 105 9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 16 106 9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 16 107 9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 17 108 9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 17 109 9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 17 110 9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 17 111 9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 18 112 9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 18 113 9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 18 114 9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 19 115 9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 19 116 9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 19 117 9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 19 118 9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 20 119 9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 20 120 9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 21 121 9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 21 122 9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 21 123 9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 22 124 9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 22 125 9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 22 126 9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 23 127 9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 23 128 9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 23 129 9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 23 130 9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 23 131 9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 23 132 9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 23 133 9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 24 134 9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 24 135 9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 24 136 9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 25 137 9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 25 138 9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 25 139 9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 25 140 9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 26 141 9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 26 142 9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 26 143 9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 26 144 9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 26 145 9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 26 146 9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 27 147 9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 27 148 9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 27 149 9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 27 150 9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 27 151 10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 28 152 10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 28 153 10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 28 154 10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 155 10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 30 156 10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 30 157 10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 31 158 10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 31 159 10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 32 160 10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 32 161 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 162 12. Security Considerations . . . . . . . . . . . . . . . . . . . 33 163 12.1. Transfer of Sensitive Information . . . . . . . . . . . . 33 164 12.2. Encoding Sensitive Information in URI's . . . . . . . . . 34 165 12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 34 166 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 167 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 168 Appendix A. Changes from RFC 2068 . . . . . . . . . . . . . . . . 36 169 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 170 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 171 Intellectual Property and Copyright Statements . . . . . . . . . . 43 173 1. Introduction 175 This document will define aspects of HTTP related to request and 176 response semantics. Right now it only includes the extracted 177 relevant sections of RFC 2616 with only minor edits. 179 The HTTP protocol is a request/response protocol. A client sends a 180 request to the server in the form of a request method, URI, and 181 protocol version, followed by a MIME-like message containing request 182 modifiers, client information, and possible body content over a 183 connection with a server. The server responds with a status line, 184 including the message's protocol version and a success or error code, 185 followed by a MIME-like message containing server information, entity 186 metainformation, and possible entity-body content. The relationship 187 between HTTP and MIME is described in Appendix A of [Part3]. 189 2. Product Tokens 191 Product tokens are used to allow communicating applications to 192 identify themselves by software name and version. Most fields using 193 product tokens also allow sub-products which form a significant part 194 of the application to be listed, separated by white space. By 195 convention, the products are listed in order of their significance 196 for identifying the application. 198 product = token ["/" product-version] 199 product-version = token 201 Examples: 203 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 204 Server: Apache/0.8.4 206 Product tokens SHOULD be short and to the point. They MUST NOT be 207 used for advertising or other non-essential information. Although 208 any token character MAY appear in a product-version, this token 209 SHOULD only be used for a version identifier (i.e., successive 210 versions of the same product SHOULD only differ in the product- 211 version portion of the product value). 213 3. Method 215 The Method token indicates the method to be performed on the resource 216 identified by the Request-URI. The method is case-sensitive. 218 Method = "OPTIONS" ; Section 8.2 219 | "GET" ; Section 8.3 220 | "HEAD" ; Section 8.4 221 | "POST" ; Section 8.5 222 | "PUT" ; Section 8.6 223 | "DELETE" ; Section 8.7 224 | "TRACE" ; Section 8.8 225 | "CONNECT" ; Section 8.9 226 | extension-method 227 extension-method = token 229 The list of methods allowed by a resource can be specified in an 230 Allow header field (Section 10.1). The return code of the response 231 always notifies the client whether a method is currently allowed on a 232 resource, since the set of allowed methods can change dynamically. 233 An origin server SHOULD return the status code 405 (Method Not 234 Allowed) if the method is known by the origin server but not allowed 235 for the requested resource, and 501 (Not Implemented) if the method 236 is unrecognized or not implemented by the origin server. The methods 237 GET and HEAD MUST be supported by all general-purpose servers. All 238 other methods are OPTIONAL; however, if the above methods are 239 implemented, they MUST be implemented with the same semantics as 240 those specified in Section 8. 242 4. Request Header Fields 244 The request-header fields allow the client to pass additional 245 information about the request, and about the client itself, to the 246 server. These fields act as request modifiers, with semantics 247 equivalent to the parameters on a programming language method 248 invocation. 250 request-header = Accept ; [Part3], Section 5.1 251 | Accept-Charset ; [Part3], Section 5.2 252 | Accept-Encoding ; [Part3], Section 5.3 253 | Accept-Language ; [Part3], Section 5.4 254 | Authorization ; [Part7], Section 3.1 255 | Expect ; Section 10.2 256 | From ; Section 10.3 257 | Host ; [Part1], Section 8.4 258 | If-Match ; [Part4], Section 6.2 259 | If-Modified-Since ; [Part4], Section 6.3 260 | If-None-Match ; [Part4], Section 6.4 261 | If-Range ; [Part5], Section 5.3 262 | If-Unmodified-Since ; [Part4], Section 6.5 263 | Max-Forwards ; Section 10.5 264 | Proxy-Authorization ; [Part7], Section 3.3 265 | Range ; [Part5], Section 5.4 266 | Referer ; Section 10.6 267 | TE ; [Part1], Section 8.8 268 | User-Agent ; Section 10.9 270 Request-header field names can be extended reliably only in 271 combination with a change in the protocol version. However, new or 272 experimental header fields MAY be given the semantics of request- 273 header fields if all parties in the communication recognize them to 274 be request-header fields. Unrecognized header fields are treated as 275 entity-header fields. 277 5. Status Code and Reason Phrase 279 The Status-Code element is a 3-digit integer result code of the 280 attempt to understand and satisfy the request. These codes are fully 281 defined in Section 9. The Reason-Phrase is intended to give a short 282 textual description of the Status-Code. The Status-Code is intended 283 for use by automata and the Reason-Phrase is intended for the human 284 user. The client is not required to examine or display the Reason- 285 Phrase. 287 The individual values of the numeric status codes defined for 288 HTTP/1.1, and an example set of corresponding Reason-Phrase's, are 289 presented below. The reason phrases listed here are only 290 recommendations -- they MAY be replaced by local equivalents without 291 affecting the protocol. 293 Status-Code = 294 "100" ; Section 9.1.1: Continue 295 | "101" ; Section 9.1.2: Switching Protocols 296 | "200" ; Section 9.2.1: OK 297 | "201" ; Section 9.2.2: Created 298 | "202" ; Section 9.2.3: Accepted 299 | "203" ; Section 9.2.4: Non-Authoritative Information 300 | "204" ; Section 9.2.5: No Content 301 | "205" ; Section 9.2.6: Reset Content 302 | "206" ; Section 9.2.7: Partial Content 303 | "300" ; Section 9.3.1: Multiple Choices 304 | "301" ; Section 9.3.2: Moved Permanently 305 | "302" ; Section 9.3.3: Found 306 | "303" ; Section 9.3.4: See Other 307 | "304" ; Section 9.3.5: Not Modified 308 | "305" ; Section 9.3.6: Use Proxy 309 | "307" ; Section 9.3.8: Temporary Redirect 310 | "400" ; Section 9.4.1: Bad Request 311 | "401" ; Section 9.4.2: Unauthorized 312 | "402" ; Section 9.4.3: Payment Required 313 | "403" ; Section 9.4.4: Forbidden 314 | "404" ; Section 9.4.5: Not Found 315 | "405" ; Section 9.4.6: Method Not Allowed 316 | "406" ; Section 9.4.7: Not Acceptable 317 | "407" ; Section 9.4.8: Proxy Authentication Required 318 | "408" ; Section 9.4.9: Request Time-out 319 | "409" ; Section 9.4.10: Conflict 320 | "410" ; Section 9.4.11: Gone 321 | "411" ; Section 9.4.12: Length Required 322 | "412" ; Section 9.4.13: Precondition Failed 323 | "413" ; Section 9.4.14: Request Entity Too Large 324 | "414" ; Section 9.4.15: Request-URI Too Large 325 | "415" ; Section 9.4.16: Unsupported Media Type 326 | "416" ; Section 9.4.17: Requested range not satisfiable 327 | "417" ; Section 9.4.18: Expectation Failed 328 | "500" ; Section 9.5.1: Internal Server Error 329 | "501" ; Section 9.5.2: Not Implemented 330 | "502" ; Section 9.5.3: Bad Gateway 331 | "503" ; Section 9.5.4: Service Unavailable 332 | "504" ; Section 9.5.5: Gateway Time-out 333 | "505" ; Section 9.5.6: HTTP Version not supported 334 | extension-code 336 extension-code = 3DIGIT 337 Reason-Phrase = * 339 HTTP status codes are extensible. HTTP applications are not required 340 to understand the meaning of all registered status codes, though such 341 understanding is obviously desirable. However, applications MUST 342 understand the class of any status code, as indicated by the first 343 digit, and treat any unrecognized response as being equivalent to the 344 x00 status code of that class, with the exception that an 345 unrecognized response MUST NOT be cached. For example, if an 346 unrecognized status code of 431 is received by the client, it can 347 safely assume that there was something wrong with its request and 348 treat the response as if it had received a 400 status code. In such 349 cases, user agents SHOULD present to the user the entity returned 350 with the response, since that entity is likely to include human- 351 readable information which will explain the unusual status. 353 6. Response Header Fields 355 The response-header fields allow the server to pass additional 356 information about the response which cannot be placed in the Status- 357 Line. These header fields give information about the server and 358 about further access to the resource identified by the Request-URI. 360 response-header = Accept-Ranges ; [Part5], Section 5.1 361 | Age ; [Part6], Section 3.1 362 | ETag ; [Part4], Section 6.1 363 | Location ; Section 10.4 364 | Proxy-Authenticate ; [Part7], Section 3.2 365 | Retry-After ; Section 10.7 366 | Server ; Section 10.8 367 | Vary ; [Part6], Section 3.5 368 | WWW-Authenticate ; [Part7], Section 3.4 370 Response-header field names can be extended reliably only in 371 combination with a change in the protocol version. However, new or 372 experimental header fields MAY be given the semantics of response- 373 header fields if all parties in the communication recognize them to 374 be response-header fields. Unrecognized header fields are treated as 375 entity-header fields. 377 7. Entity 379 Request and Response messages MAY transfer an entity if not otherwise 380 restricted by the request method or response status code. An entity 381 consists of entity-header fields and an entity-body, although some 382 responses will only include the entity-headers. HTTP entity-body and 383 entity-header fields are defined in [Part3]. 385 An entity-body is only present in a message when a message-body is 386 present, as described in Section 4.3 of [Part1]. The entity-body is 387 obtained from the message-body by decoding any Transfer-Encoding that 388 might have been applied to ensure safe and proper transfer of the 389 message. 391 8. Method Definitions 393 The set of common methods for HTTP/1.1 is defined below. Although 394 this set can be expanded, additional methods cannot be assumed to 395 share the same semantics for separately extended clients and servers. 396 The Host request-header field (Section 8.4 of [Part1]) MUST accompany 397 all HTTP/1.1 requests. 399 8.1. Safe and Idempotent Methods 401 8.1.1. Safe Methods 403 Implementors should be aware that the software represents the user in 404 their interactions over the Internet, and should be careful to allow 405 the user to be aware of any actions they might take which may have an 406 unexpected significance to themselves or others. 408 In particular, the convention has been established that the GET and 409 HEAD methods SHOULD NOT have the significance of taking an action 410 other than retrieval. These methods ought to be considered "safe". 411 This allows user agents to represent other methods, such as POST, PUT 412 and DELETE, in a special way, so that the user is made aware of the 413 fact that a possibly unsafe action is being requested. 415 Naturally, it is not possible to ensure that the server does not 416 generate side-effects as a result of performing a GET request; in 417 fact, some dynamic resources consider that a feature. The important 418 distinction here is that the user did not request the side-effects, 419 so therefore cannot be held accountable for them. 421 8.1.2. Idempotent Methods 423 Methods can also have the property of "idempotence" in that (aside 424 from error or expiration issues) the side-effects of N > 0 identical 425 requests is the same as for a single request. The methods GET, HEAD, 426 PUT and DELETE share this property. Also, the methods OPTIONS and 427 TRACE SHOULD NOT have side effects, and so are inherently idempotent. 429 However, it is possible that a sequence of several requests is non- 430 idempotent, even if all of the methods executed in that sequence are 431 idempotent. (A sequence is idempotent if a single execution of the 432 entire sequence always yields a result that is not changed by a 433 reexecution of all, or part, of that sequence.) For example, a 434 sequence is non-idempotent if its result depends on a value that is 435 later modified in the same sequence. 437 A sequence that never has side effects is idempotent, by definition 438 (provided that no concurrent operations are being executed on the 439 same set of resources). 441 8.2. OPTIONS 443 The OPTIONS method represents a request for information about the 444 communication options available on the request/response chain 445 identified by the Request-URI. This method allows the client to 446 determine the options and/or requirements associated with a resource, 447 or the capabilities of a server, without implying a resource action 448 or initiating a resource retrieval. 450 Responses to this method are not cacheable. 452 If the OPTIONS request includes an entity-body (as indicated by the 453 presence of Content-Length or Transfer-Encoding), then the media type 454 MUST be indicated by a Content-Type field. Although this 455 specification does not define any use for such a body, future 456 extensions to HTTP might use the OPTIONS body to make more detailed 457 queries on the server. A server that does not support such an 458 extension MAY discard the request body. 460 If the Request-URI is an asterisk ("*"), the OPTIONS request is 461 intended to apply to the server in general rather than to a specific 462 resource. Since a server's communication options typically depend on 463 the resource, the "*" request is only useful as a "ping" or "no-op" 464 type of method; it does nothing beyond allowing the client to test 465 the capabilities of the server. For example, this can be used to 466 test a proxy for HTTP/1.1 compliance (or lack thereof). 468 If the Request-URI is not an asterisk, the OPTIONS request applies 469 only to the options that are available when communicating with that 470 resource. 472 A 200 response SHOULD include any header fields that indicate 473 optional features implemented by the server and applicable to that 474 resource (e.g., Allow), possibly including extensions not defined by 475 this specification. The response body, if any, SHOULD also include 476 information about the communication options. The format for such a 477 body is not defined by this specification, but might be defined by 478 future extensions to HTTP. Content negotiation MAY be used to select 479 the appropriate response format. If no response body is included, 480 the response MUST include a Content-Length field with a field-value 481 of "0". 483 The Max-Forwards request-header field MAY be used to target a 484 specific proxy in the request chain. When a proxy receives an 485 OPTIONS request on an absoluteURI for which request forwarding is 486 permitted, the proxy MUST check for a Max-Forwards field. If the 487 Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward 488 the message; instead, the proxy SHOULD respond with its own 489 communication options. If the Max-Forwards field-value is an integer 490 greater than zero, the proxy MUST decrement the field-value when it 491 forwards the request. If no Max-Forwards field is present in the 492 request, then the forwarded request MUST NOT include a Max-Forwards 493 field. 495 8.3. GET 497 The GET method means retrieve whatever information (in the form of an 498 entity) is identified by the Request-URI. If the Request-URI refers 499 to a data-producing process, it is the produced data which shall be 500 returned as the entity in the response and not the source text of the 501 process, unless that text happens to be the output of the process. 503 The semantics of the GET method change to a "conditional GET" if the 504 request message includes an If-Modified-Since, If-Unmodified-Since, 505 If-Match, If-None-Match, or If-Range header field. A conditional GET 506 method requests that the entity be transferred only under the 507 circumstances described by the conditional header field(s). The 508 conditional GET method is intended to reduce unnecessary network 509 usage by allowing cached entities to be refreshed without requiring 510 multiple requests or transferring data already held by the client. 512 The semantics of the GET method change to a "partial GET" if the 513 request message includes a Range header field. A partial GET 514 requests that only part of the entity be transferred, as described in 515 Section 5.4 of [Part5]. The partial GET method is intended to reduce 516 unnecessary network usage by allowing partially-retrieved entities to 517 be completed without transferring data already held by the client. 519 The response to a GET request is cacheable if and only if it meets 520 the requirements for HTTP caching described in [Part6]. 522 See Section 12.2 for security considerations when used for forms. 524 8.4. HEAD 526 The HEAD method is identical to GET except that the server MUST NOT 527 return a message-body in the response. The metainformation contained 528 in the HTTP headers in response to a HEAD request SHOULD be identical 529 to the information sent in response to a GET request. This method 530 can be used for obtaining metainformation about the entity implied by 531 the request without transferring the entity-body itself. This method 532 is often used for testing hypertext links for validity, 533 accessibility, and recent modification. 535 The response to a HEAD request MAY be cacheable in the sense that the 536 information contained in the response MAY be used to update a 537 previously cached entity from that resource. If the new field values 538 indicate that the cached entity differs from the current entity (as 539 would be indicated by a change in Content-Length, Content-MD5, ETag 540 or Last-Modified), then the cache MUST treat the cache entry as 541 stale. 543 8.5. POST 545 The POST method is used to request that the origin server accept the 546 entity enclosed in the request as a new subordinate of the resource 547 identified by the Request-URI in the Request-Line. POST is designed 548 to allow a uniform method to cover the following functions: 550 o Annotation of existing resources; 552 o Posting a message to a bulletin board, newsgroup, mailing list, or 553 similar group of articles; 555 o Providing a block of data, such as the result of submitting a 556 form, to a data-handling process; 558 o Extending a database through an append operation. 560 The actual function performed by the POST method is determined by the 561 server and is usually dependent on the Request-URI. The posted 562 entity is subordinate to that URI in the same way that a file is 563 subordinate to a directory containing it, a news article is 564 subordinate to a newsgroup to which it is posted, or a record is 565 subordinate to a database. 567 The action performed by the POST method might not result in a 568 resource that can be identified by a URI. In this case, either 200 569 (OK) or 204 (No Content) is the appropriate response status, 570 depending on whether or not the response includes an entity that 571 describes the result. 573 If a resource has been created on the origin server, the response 574 SHOULD be 201 (Created) and contain an entity which describes the 575 status of the request and refers to the new resource, and a Location 576 header (see Section 10.4). 578 Responses to this method are not cacheable, unless the response 579 includes appropriate Cache-Control or Expires header fields. 580 However, the 303 (See Other) response can be used to direct the user 581 agent to retrieve a cacheable resource. 583 POST requests MUST obey the message transmission requirements set out 584 in Section 7.2 of [Part1]. 586 See Section 12.2 for security considerations. 588 8.6. PUT 590 The PUT method requests that the enclosed entity be stored under the 591 supplied Request-URI. If the Request-URI refers to an already 592 existing resource, the enclosed entity SHOULD be considered as a 593 modified version of the one residing on the origin server. If the 594 Request-URI does not point to an existing resource, and that URI is 595 capable of being defined as a new resource by the requesting user 596 agent, the origin server can create the resource with that URI. If a 597 new resource is created, the origin server MUST inform the user agent 598 via the 201 (Created) response. If an existing resource is modified, 599 either the 200 (OK) or 204 (No Content) response codes SHOULD be sent 600 to indicate successful completion of the request. If the resource 601 could not be created or modified with the Request-URI, an appropriate 602 error response SHOULD be given that reflects the nature of the 603 problem. The recipient of the entity MUST NOT ignore any Content-* 604 (e.g. Content-Range) headers that it does not understand or 605 implement and MUST return a 501 (Not Implemented) response in such 606 cases. 608 If the request passes through a cache and the Request-URI identifies 609 one or more currently cached entities, those entries SHOULD be 610 treated as stale. Responses to this method are not cacheable. 612 The fundamental difference between the POST and PUT requests is 613 reflected in the different meaning of the Request-URI. The URI in a 614 POST request identifies the resource that will handle the enclosed 615 entity. That resource might be a data-accepting process, a gateway 616 to some other protocol, or a separate entity that accepts 617 annotations. In contrast, the URI in a PUT request identifies the 618 entity enclosed with the request -- the user agent knows what URI is 619 intended and the server MUST NOT attempt to apply the request to some 620 other resource. If the server desires that the request be applied to 621 a different URI, it MUST send a 301 (Moved Permanently) response; the 622 user agent MAY then make its own decision regarding whether or not to 623 redirect the request. 625 A single resource MAY be identified by many different URIs. For 626 example, an article might have a URI for identifying "the current 627 version" which is separate from the URI identifying each particular 628 version. In this case, a PUT request on a general URI might result 629 in several other URIs being defined by the origin server. 631 HTTP/1.1 does not define how a PUT method affects the state of an 632 origin server. 634 PUT requests MUST obey the message transmission requirements set out 635 in Section 7.2 of [Part1]. 637 Unless otherwise specified for a particular entity-header, the 638 entity-headers in the PUT request SHOULD be applied to the resource 639 created or modified by the PUT. 641 8.7. DELETE 643 The DELETE method requests that the origin server delete the resource 644 identified by the Request-URI. This method MAY be overridden by 645 human intervention (or other means) on the origin server. The client 646 cannot be guaranteed that the operation has been carried out, even if 647 the status code returned from the origin server indicates that the 648 action has been completed successfully. However, the server SHOULD 649 NOT indicate success unless, at the time the response is given, it 650 intends to delete the resource or move it to an inaccessible 651 location. 653 A successful response SHOULD be 200 (OK) if the response includes an 654 entity describing the status, 202 (Accepted) if the action has not 655 yet been enacted, or 204 (No Content) if the action has been enacted 656 but the response does not include an entity. 658 If the request passes through a cache and the Request-URI identifies 659 one or more currently cached entities, those entries SHOULD be 660 treated as stale. Responses to this method are not cacheable. 662 8.8. TRACE 664 The TRACE method is used to invoke a remote, application-layer loop- 665 back of the request message. The final recipient of the request 666 SHOULD reflect the message received back to the client as the entity- 667 body of a 200 (OK) response. The final recipient is either the 668 origin server or the first proxy or gateway to receive a Max-Forwards 669 value of zero (0) in the request (see Section 10.5). A TRACE request 670 MUST NOT include an entity. 672 TRACE allows the client to see what is being received at the other 673 end of the request chain and use that data for testing or diagnostic 674 information. The value of the Via header field (Section 8.9 of 676 [Part1]) is of particular interest, since it acts as a trace of the 677 request chain. Use of the Max-Forwards header field allows the 678 client to limit the length of the request chain, which is useful for 679 testing a chain of proxies forwarding messages in an infinite loop. 681 If the request is valid, the response SHOULD contain the entire 682 request message in the entity-body, with a Content-Type of "message/ 683 http". Responses to this method MUST NOT be cached. 685 8.9. CONNECT 687 This specification reserves the method name CONNECT for use with a 688 proxy that can dynamically switch to being a tunnel (e.g. SSL 689 tunneling [Luo1998]). 691 9. Status Code Definitions 693 Each Status-Code is described below, including a description of which 694 method(s) it can follow and any metainformation required in the 695 response. 697 9.1. Informational 1xx 699 This class of status code indicates a provisional response, 700 consisting only of the Status-Line and optional headers, and is 701 terminated by an empty line. There are no required headers for this 702 class of status code. Since HTTP/1.0 did not define any 1xx status 703 codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client 704 except under experimental conditions. 706 A client MUST be prepared to accept one or more 1xx status responses 707 prior to a regular response, even if the client does not expect a 100 708 (Continue) status message. Unexpected 1xx status responses MAY be 709 ignored by a user agent. 711 Proxies MUST forward 1xx responses, unless the connection between the 712 proxy and its client has been closed, or unless the proxy itself 713 requested the generation of the 1xx response. (For example, if a 714 proxy adds a "Expect: 100-continue" field when it forwards a request, 715 then it need not forward the corresponding 100 (Continue) 716 response(s).) 718 9.1.1. 100 Continue 720 The client SHOULD continue with its request. This interim response 721 is used to inform the client that the initial part of the request has 722 been received and has not yet been rejected by the server. The 723 client SHOULD continue by sending the remainder of the request or, if 724 the request has already been completed, ignore this response. The 725 server MUST send a final response after the request has been 726 completed. See Section 7.2.3 of [Part1] for detailed discussion of 727 the use and handling of this status code. 729 9.1.2. 101 Switching Protocols 731 The server understands and is willing to comply with the client's 732 request, via the Upgrade message header field (Section 5.4 of 733 [Part5]), for a change in the application protocol being used on this 734 connection. The server will switch protocols to those defined by the 735 response's Upgrade header field immediately after the empty line 736 which terminates the 101 response. 738 The protocol SHOULD be switched only when it is advantageous to do 739 so. For example, switching to a newer version of HTTP is 740 advantageous over older versions, and switching to a real-time, 741 synchronous protocol might be advantageous when delivering resources 742 that use such features. 744 9.2. Successful 2xx 746 This class of status code indicates that the client's request was 747 successfully received, understood, and accepted. 749 9.2.1. 200 OK 751 The request has succeeded. The information returned with the 752 response is dependent on the method used in the request, for example: 754 GET an entity corresponding to the requested resource is sent in the 755 response; 757 HEAD the entity-header fields corresponding to the requested 758 resource are sent in the response without any message-body; 760 POST an entity describing or containing the result of the action; 762 TRACE an entity containing the request message as received by the 763 end server. 765 9.2.2. 201 Created 767 The request has been fulfilled and resulted in a new resource being 768 created. The newly created resource can be referenced by the URI(s) 769 returned in the entity of the response, with the most specific URI 770 for the resource given by a Location header field. The response 771 SHOULD include an entity containing a list of resource 772 characteristics and location(s) from which the user or user agent can 773 choose the one most appropriate. The entity format is specified by 774 the media type given in the Content-Type header field. The origin 775 server MUST create the resource before returning the 201 status code. 776 If the action cannot be carried out immediately, the server SHOULD 777 respond with 202 (Accepted) response instead. 779 A 201 response MAY contain an ETag response header field indicating 780 the current value of the entity tag for the requested variant just 781 created, see Section 6.1 of [Part4]. 783 9.2.3. 202 Accepted 785 The request has been accepted for processing, but the processing has 786 not been completed. The request might or might not eventually be 787 acted upon, as it might be disallowed when processing actually takes 788 place. There is no facility for re-sending a status code from an 789 asynchronous operation such as this. 791 The 202 response is intentionally non-committal. Its purpose is to 792 allow a server to accept a request for some other process (perhaps a 793 batch-oriented process that is only run once per day) without 794 requiring that the user agent's connection to the server persist 795 until the process is completed. The entity returned with this 796 response SHOULD include an indication of the request's current status 797 and either a pointer to a status monitor or some estimate of when the 798 user can expect the request to be fulfilled. 800 9.2.4. 203 Non-Authoritative Information 802 The returned metainformation in the entity-header is not the 803 definitive set as available from the origin server, but is gathered 804 from a local or a third-party copy. The set presented MAY be a 805 subset or superset of the original version. For example, including 806 local annotation information about the resource might result in a 807 superset of the metainformation known by the origin server. Use of 808 this response code is not required and is only appropriate when the 809 response would otherwise be 200 (OK). 811 9.2.5. 204 No Content 813 The server has fulfilled the request but does not need to return an 814 entity-body, and might want to return updated metainformation. The 815 response MAY include new or updated metainformation in the form of 816 entity-headers, which if present SHOULD be associated with the 817 requested variant. 819 If the client is a user agent, it SHOULD NOT change its document view 820 from that which caused the request to be sent. This response is 821 primarily intended to allow input for actions to take place without 822 causing a change to the user agent's active document view, although 823 any new or updated metainformation SHOULD be applied to the document 824 currently in the user agent's active view. 826 The 204 response MUST NOT include a message-body, and thus is always 827 terminated by the first empty line after the header fields. 829 9.2.6. 205 Reset Content 831 The server has fulfilled the request and the user agent SHOULD reset 832 the document view which caused the request to be sent. This response 833 is primarily intended to allow input for actions to take place via 834 user input, followed by a clearing of the form in which the input is 835 given so that the user can easily initiate another input action. The 836 response MUST NOT include an entity. 838 9.2.7. 206 Partial Content 840 The server has fulfilled the partial GET request for the resource and 841 the enclosed entity is a partial representation as defined in 842 [Part5]. 844 9.3. Redirection 3xx 846 This class of status code indicates that further action needs to be 847 taken by the user agent in order to fulfill the request. The action 848 required MAY be carried out by the user agent without interaction 849 with the user if and only if the method used in the second request is 850 GET or HEAD. A client SHOULD detect infinite redirection loops, 851 since such loops generate network traffic for each redirection. 853 Note: previous versions of this specification recommended a 854 maximum of five redirections. Content developers should be aware 855 that there might be clients that implement such a fixed 856 limitation. 858 9.3.1. 300 Multiple Choices 860 The requested resource corresponds to any one of a set of 861 representations, each with its own specific location, and agent- 862 driven negotiation information (Section 4 of [Part3]) is being 863 provided so that the user (or user agent) can select a preferred 864 representation and redirect its request to that location. 866 Unless it was a HEAD request, the response SHOULD include an entity 867 containing a list of resource characteristics and location(s) from 868 which the user or user agent can choose the one most appropriate. 869 The entity format is specified by the media type given in the 870 Content-Type header field. Depending upon the format and the 871 capabilities of the user agent, selection of the most appropriate 872 choice MAY be performed automatically. However, this specification 873 does not define any standard for such automatic selection. 875 If the server has a preferred choice of representation, it SHOULD 876 include the specific URI for that representation in the Location 877 field; user agents MAY use the Location field value for automatic 878 redirection. This response is cacheable unless indicated otherwise. 880 9.3.2. 301 Moved Permanently 882 The requested resource has been assigned a new permanent URI and any 883 future references to this resource SHOULD use one of the returned 884 URIs. Clients with link editing capabilities ought to automatically 885 re-link references to the Request-URI to one or more of the new 886 references returned by the server, where possible. This response is 887 cacheable unless indicated otherwise. 889 The new permanent URI SHOULD be given by the Location field in the 890 response. Unless the request method was HEAD, the entity of the 891 response SHOULD contain a short hypertext note with a hyperlink to 892 the new URI(s). 894 If the 301 status code is received in response to a request other 895 than GET or HEAD, the user agent MUST NOT automatically redirect the 896 request unless it can be confirmed by the user, since this might 897 change the conditions under which the request was issued. 899 Note: When automatically redirecting a POST request after 900 receiving a 301 status code, some existing HTTP/1.0 user agents 901 will erroneously change it into a GET request. 903 9.3.3. 302 Found 905 The requested resource resides temporarily under a different URI. 906 Since the redirection might be altered on occasion, the client SHOULD 907 continue to use the Request-URI for future requests. This response 908 is only cacheable if indicated by a Cache-Control or Expires header 909 field. 911 The temporary URI SHOULD be given by the Location field in the 912 response. Unless the request method was HEAD, the entity of the 913 response SHOULD contain a short hypertext note with a hyperlink to 914 the new URI(s). 916 If the 302 status code is received in response to a request other 917 than GET or HEAD, the user agent MUST NOT automatically redirect the 918 request unless it can be confirmed by the user, since this might 919 change the conditions under which the request was issued. 921 Note: RFC 1945 and RFC 2068 specify that the client is not allowed 922 to change the method on the redirected request. However, most 923 existing user agent implementations treat 302 as if it were a 303 924 response, performing a GET on the Location field-value regardless 925 of the original request method. The status codes 303 and 307 have 926 been added for servers that wish to make unambiguously clear which 927 kind of reaction is expected of the client. 929 9.3.4. 303 See Other 931 The response to the request can be found under a different URI and 932 SHOULD be retrieved using a GET method on that resource. This method 933 exists primarily to allow the output of a POST-activated script to 934 redirect the user agent to a selected resource. The new URI is not a 935 substitute reference for the originally requested resource. The 303 936 response MUST NOT be cached, but the response to the second 937 (redirected) request might be cacheable. 939 The different URI SHOULD be given by the Location field in the 940 response. Unless the request method was HEAD, the entity of the 941 response SHOULD contain a short hypertext note with a hyperlink to 942 the new URI(s). 944 Note: Many pre-HTTP/1.1 user agents do not understand the 303 945 status. When interoperability with such clients is a concern, the 946 302 status code may be used instead, since most user agents react 947 to a 302 response as described here for 303. 949 9.3.5. 304 Not Modified 951 The response to the request has not been modified since the 952 conditions indicated by the client's conditional GET request, as 953 defined in [Part4]. 955 9.3.6. 305 Use Proxy 957 The requested resource MUST be accessed through the proxy given by 958 the Location field. The Location field gives the URI of the proxy. 959 The recipient is expected to repeat this single request via the 960 proxy. 305 responses MUST only be generated by origin servers. 962 Note: RFC 2068 was not clear that 305 was intended to redirect a 963 single request, and to be generated by origin servers only. Not 964 observing these limitations has significant security consequences. 966 9.3.7. 306 (Unused) 968 The 306 status code was used in a previous version of the 969 specification, is no longer used, and the code is reserved. 971 9.3.8. 307 Temporary Redirect 973 The requested resource resides temporarily under a different URI. 974 Since the redirection MAY be altered on occasion, the client SHOULD 975 continue to use the Request-URI for future requests. This response 976 is only cacheable if indicated by a Cache-Control or Expires header 977 field. 979 The temporary URI SHOULD be given by the Location field in the 980 response. Unless the request method was HEAD, the entity of the 981 response SHOULD contain a short hypertext note with a hyperlink to 982 the new URI(s) , since many pre-HTTP/1.1 user agents do not 983 understand the 307 status. Therefore, the note SHOULD contain the 984 information necessary for a user to repeat the original request on 985 the new URI. 987 If the 307 status code is received in response to a request other 988 than GET or HEAD, the user agent MUST NOT automatically redirect the 989 request unless it can be confirmed by the user, since this might 990 change the conditions under which the request was issued. 992 9.4. Client Error 4xx 994 The 4xx class of status code is intended for cases in which the 995 client seems to have erred. Except when responding to a HEAD 996 request, the server SHOULD include an entity containing an 997 explanation of the error situation, and whether it is a temporary or 998 permanent condition. These status codes are applicable to any 999 request method. User agents SHOULD display any included entity to 1000 the user. 1002 If the client is sending data, a server implementation using TCP 1003 SHOULD be careful to ensure that the client acknowledges receipt of 1004 the packet(s) containing the response, before the server closes the 1005 input connection. If the client continues sending data to the server 1006 after the close, the server's TCP stack will send a reset packet to 1007 the client, which may erase the client's unacknowledged input buffers 1008 before they can be read and interpreted by the HTTP application. 1010 9.4.1. 400 Bad Request 1012 The request could not be understood by the server due to malformed 1013 syntax. The client SHOULD NOT repeat the request without 1014 modifications. 1016 9.4.2. 401 Unauthorized 1018 The request requires user authentication (see [Part7]). 1020 9.4.3. 402 Payment Required 1022 This code is reserved for future use. 1024 9.4.4. 403 Forbidden 1026 The server understood the request, but is refusing to fulfill it. 1027 Authorization will not help and the request SHOULD NOT be repeated. 1028 If the request method was not HEAD and the server wishes to make 1029 public why the request has not been fulfilled, it SHOULD describe the 1030 reason for the refusal in the entity. If the server does not wish to 1031 make this information available to the client, the status code 404 1032 (Not Found) can be used instead. 1034 9.4.5. 404 Not Found 1036 The server has not found anything matching the Request-URI. No 1037 indication is given of whether the condition is temporary or 1038 permanent. The 410 (Gone) status code SHOULD be used if the server 1039 knows, through some internally configurable mechanism, that an old 1040 resource is permanently unavailable and has no forwarding address. 1041 This status code is commonly used when the server does not wish to 1042 reveal exactly why the request has been refused, or when no other 1043 response is applicable. 1045 9.4.6. 405 Method Not Allowed 1047 The method specified in the Request-Line is not allowed for the 1048 resource identified by the Request-URI. The response MUST include an 1049 Allow header containing a list of valid methods for the requested 1050 resource. 1052 9.4.7. 406 Not Acceptable 1054 The resource identified by the request is only capable of generating 1055 response entities which have content characteristics not acceptable 1056 according to the accept headers sent in the request. 1058 Unless it was a HEAD request, the response SHOULD include an entity 1059 containing a list of available entity characteristics and location(s) 1060 from which the user or user agent can choose the one most 1061 appropriate. The entity format is specified by the media type given 1062 in the Content-Type header field. Depending upon the format and the 1063 capabilities of the user agent, selection of the most appropriate 1064 choice MAY be performed automatically. However, this specification 1065 does not define any standard for such automatic selection. 1067 Note: HTTP/1.1 servers are allowed to return responses which are 1068 not acceptable according to the accept headers sent in the 1069 request. In some cases, this may even be preferable to sending a 1070 406 response. User agents are encouraged to inspect the headers 1071 of an incoming response to determine if it is acceptable. 1073 If the response could be unacceptable, a user agent SHOULD 1074 temporarily stop receipt of more data and query the user for a 1075 decision on further actions. 1077 9.4.8. 407 Proxy Authentication Required 1079 This code is similar to 401 (Unauthorized), but indicates that the 1080 client must first authenticate itself with the proxy (see [Part7]). 1082 9.4.9. 408 Request Timeout 1084 The client did not produce a request within the time that the server 1085 was prepared to wait. The client MAY repeat the request without 1086 modifications at any later time. 1088 9.4.10. 409 Conflict 1090 The request could not be completed due to a conflict with the current 1091 state of the resource. This code is only allowed in situations where 1092 it is expected that the user might be able to resolve the conflict 1093 and resubmit the request. The response body SHOULD include enough 1094 information for the user to recognize the source of the conflict. 1095 Ideally, the response entity would include enough information for the 1096 user or user agent to fix the problem; however, that might not be 1097 possible and is not required. 1099 Conflicts are most likely to occur in response to a PUT request. For 1100 example, if versioning were being used and the entity being PUT 1101 included changes to a resource which conflict with those made by an 1102 earlier (third-party) request, the server might use the 409 response 1103 to indicate that it can't complete the request. In this case, the 1104 response entity would likely contain a list of the differences 1105 between the two versions in a format defined by the response Content- 1106 Type. 1108 9.4.11. 410 Gone 1110 The requested resource is no longer available at the server and no 1111 forwarding address is known. This condition is expected to be 1112 considered permanent. Clients with link editing capabilities SHOULD 1113 delete references to the Request-URI after user approval. If the 1114 server does not know, or has no facility to determine, whether or not 1115 the condition is permanent, the status code 404 (Not Found) SHOULD be 1116 used instead. This response is cacheable unless indicated otherwise. 1118 The 410 response is primarily intended to assist the task of web 1119 maintenance by notifying the recipient that the resource is 1120 intentionally unavailable and that the server owners desire that 1121 remote links to that resource be removed. Such an event is common 1122 for limited-time, promotional services and for resources belonging to 1123 individuals no longer working at the server's site. It is not 1124 necessary to mark all permanently unavailable resources as "gone" or 1125 to keep the mark for any length of time -- that is left to the 1126 discretion of the server owner. 1128 9.4.12. 411 Length Required 1130 The server refuses to accept the request without a defined Content- 1131 Length. The client MAY repeat the request if it adds a valid 1132 Content-Length header field containing the length of the message-body 1133 in the request message. 1135 9.4.13. 412 Precondition Failed 1137 The precondition given in one or more of the request-header fields 1138 evaluated to false when it was tested on the server, as defined in 1139 [Part4]. 1141 9.4.14. 413 Request Entity Too Large 1143 The server is refusing to process a request because the request 1144 entity is larger than the server is willing or able to process. The 1145 server MAY close the connection to prevent the client from continuing 1146 the request. 1148 If the condition is temporary, the server SHOULD include a Retry- 1149 After header field to indicate that it is temporary and after what 1150 time the client MAY try again. 1152 9.4.15. 414 Request-URI Too Long 1154 The server is refusing to service the request because the Request-URI 1155 is longer than the server is willing to interpret. This rare 1156 condition is only likely to occur when a client has improperly 1157 converted a POST request to a GET request with long query 1158 information, when the client has descended into a URI "black hole" of 1159 redirection (e.g., a redirected URI prefix that points to a suffix of 1160 itself), or when the server is under attack by a client attempting to 1161 exploit security holes present in some servers using fixed-length 1162 buffers for reading or manipulating the Request-URI. 1164 9.4.16. 415 Unsupported Media Type 1166 The server is refusing to service the request because the entity of 1167 the request is in a format not supported by the requested resource 1168 for the requested method. 1170 9.4.17. 416 Requested Range Not Satisfiable 1172 The request included a Range request-header field (Section 5.4 of 1173 [Part5]) and none of the range-specifier values in this field overlap 1174 the current extent of the selected resource. 1176 9.4.18. 417 Expectation Failed 1178 The expectation given in an Expect request-header field (see 1179 Section 10.2) could not be met by this server, or, if the server is a 1180 proxy, the server has unambiguous evidence that the request could not 1181 be met by the next-hop server. 1183 9.5. Server Error 5xx 1185 Response status codes beginning with the digit "5" indicate cases in 1186 which the server is aware that it has erred or is incapable of 1187 performing the request. Except when responding to a HEAD request, 1188 the server SHOULD include an entity containing an explanation of the 1189 error situation, and whether it is a temporary or permanent 1190 condition. User agents SHOULD display any included entity to the 1191 user. These response codes are applicable to any request method. 1193 9.5.1. 500 Internal Server Error 1195 The server encountered an unexpected condition which prevented it 1196 from fulfilling the request. 1198 9.5.2. 501 Not Implemented 1200 The server does not support the functionality required to fulfill the 1201 request. This is the appropriate response when the server does not 1202 recognize the request method and is not capable of supporting it for 1203 any resource. 1205 9.5.3. 502 Bad Gateway 1207 The server, while acting as a gateway or proxy, received an invalid 1208 response from the upstream server it accessed in attempting to 1209 fulfill the request. 1211 9.5.4. 503 Service Unavailable 1213 The server is currently unable to handle the request due to a 1214 temporary overloading or maintenance of the server. The implication 1215 is that this is a temporary condition which will be alleviated after 1216 some delay. If known, the length of the delay MAY be indicated in a 1217 Retry-After header. If no Retry-After is given, the client SHOULD 1218 handle the response as it would for a 500 response. 1220 Note: The existence of the 503 status code does not imply that a 1221 server must use it when becoming overloaded. Some servers may 1222 wish to simply refuse the connection. 1224 9.5.5. 504 Gateway Timeout 1226 The server, while acting as a gateway or proxy, did not receive a 1227 timely response from the upstream server specified by the URI (e.g. 1228 HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed 1229 to access in attempting to complete the request. 1231 Note: Note to implementors: some deployed proxies are known to 1232 return 400 or 500 when DNS lookups time out. 1234 9.5.6. 505 HTTP Version Not Supported 1236 The server does not support, or refuses to support, the HTTP protocol 1237 version that was used in the request message. The server is 1238 indicating that it is unable or unwilling to complete the request 1239 using the same major version as the client, as described in Section 1240 3.1 of [Part1], other than with this error message. The response 1241 SHOULD contain an entity describing why that version is not supported 1242 and what other protocols are supported by that server. 1244 10. Header Field Definitions 1246 This section defines the syntax and semantics of all standard 1247 HTTP/1.1 header fields. For entity-header fields, both sender and 1248 recipient refer to either the client or the server, depending on who 1249 sends and who receives the entity. 1251 10.1. Allow 1253 The Allow entity-header field lists the set of methods supported by 1254 the resource identified by the Request-URI. The purpose of this 1255 field is strictly to inform the recipient of valid methods associated 1256 with the resource. An Allow header field MUST be present in a 405 1257 (Method Not Allowed) response. 1259 Allow = "Allow" ":" #Method 1261 Example of use: 1263 Allow: GET, HEAD, PUT 1265 This field cannot prevent a client from trying other methods. 1266 However, the indications given by the Allow header field value SHOULD 1267 be followed. The actual set of allowed methods is defined by the 1268 origin server at the time of each request. 1270 The Allow header field MAY be provided with a PUT request to 1271 recommend the methods to be supported by the new or modified 1272 resource. The server is not required to support these methods and 1273 SHOULD include an Allow header in the response giving the actual 1274 supported methods. 1276 A proxy MUST NOT modify the Allow header field even if it does not 1277 understand all the methods specified, since the user agent might have 1278 other means of communicating with the origin server. 1280 10.2. Expect 1282 The Expect request-header field is used to indicate that particular 1283 server behaviors are required by the client. 1285 Expect = "Expect" ":" 1#expectation 1287 expectation = "100-continue" | expectation-extension 1288 expectation-extension = token [ "=" ( token | quoted-string ) 1289 *expect-params ] 1290 expect-params = ";" token [ "=" ( token | quoted-string ) ] 1292 A server that does not understand or is unable to comply with any of 1293 the expectation values in the Expect field of a request MUST respond 1294 with appropriate error status. The server MUST respond with a 417 1295 (Expectation Failed) status if any of the expectations cannot be met 1296 or, if there are other problems with the request, some other 4xx 1297 status. 1299 This header field is defined with extensible syntax to allow for 1300 future extensions. If a server receives a request containing an 1301 Expect field that includes an expectation-extension that it does not 1302 support, it MUST respond with a 417 (Expectation Failed) status. 1304 Comparison of expectation values is case-insensitive for unquoted 1305 tokens (including the 100-continue token), and is case-sensitive for 1306 quoted-string expectation-extensions. 1308 The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST 1309 return a 417 (Expectation Failed) status if it receives a request 1310 with an expectation that it cannot meet. However, the Expect 1311 request-header itself is end-to-end; it MUST be forwarded if the 1312 request is forwarded. 1314 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the 1315 Expect header. 1317 See Section 7.2.3 of [Part1] for the use of the 100 (continue) 1318 status. 1320 10.3. From 1322 The From request-header field, if given, SHOULD contain an Internet 1323 e-mail address for the human user who controls the requesting user 1324 agent. The address SHOULD be machine-usable, as defined by "mailbox" 1325 in RFC 822 [RFC822] as updated by RFC 1123 [RFC1123]: 1327 From = "From" ":" mailbox 1329 An example is: 1331 From: webmaster@w3.org 1333 This header field MAY be used for logging purposes and as a means for 1334 identifying the source of invalid or unwanted requests. It SHOULD 1335 NOT be used as an insecure form of access protection. The 1336 interpretation of this field is that the request is being performed 1337 on behalf of the person given, who accepts responsibility for the 1338 method performed. In particular, robot agents SHOULD include this 1339 header so that the person responsible for running the robot can be 1340 contacted if problems occur on the receiving end. 1342 The Internet e-mail address in this field MAY be separate from the 1343 Internet host which issued the request. For example, when a request 1344 is passed through a proxy the original issuer's address SHOULD be 1345 used. 1347 The client SHOULD NOT send the From header field without the user's 1348 approval, as it might conflict with the user's privacy interests or 1349 their site's security policy. It is strongly recommended that the 1350 user be able to disable, enable, and modify the value of this field 1351 at any time prior to a request. 1353 10.4. Location 1355 The Location response-header field is used to redirect the recipient 1356 to a location other than the Request-URI for completion of the 1357 request or identification of a new resource. For 201 (Created) 1358 responses, the Location is that of the new resource which was created 1359 by the request. For 3xx responses, the location SHOULD indicate the 1360 server's preferred URI for automatic redirection to the resource. 1361 The field value consists of a single absolute URI. 1363 Location = "Location" ":" absoluteURI 1365 An example is: 1367 Location: http://www.w3.org/pub/WWW/People.html 1369 Note: The Content-Location header field (Section 5.7 of [Part3]) 1370 differs from Location in that the Content-Location identifies the 1371 original location of the entity enclosed in the request. It is 1372 therefore possible for a response to contain header fields for 1373 both Location and Content-Location. 1375 10.5. Max-Forwards 1377 The Max-Forwards request-header field provides a mechanism with the 1378 TRACE (Section 8.8) and OPTIONS (Section 8.2) methods to limit the 1379 number of proxies or gateways that can forward the request to the 1380 next inbound server. This can be useful when the client is 1381 attempting to trace a request chain which appears to be failing or 1382 looping in mid-chain. 1384 Max-Forwards = "Max-Forwards" ":" 1*DIGIT 1386 The Max-Forwards value is a decimal integer indicating the remaining 1387 number of times this request message may be forwarded. 1389 Each proxy or gateway recipient of a TRACE or OPTIONS request 1390 containing a Max-Forwards header field MUST check and update its 1391 value prior to forwarding the request. If the received value is zero 1392 (0), the recipient MUST NOT forward the request; instead, it MUST 1393 respond as the final recipient. If the received Max-Forwards value 1394 is greater than zero, then the forwarded message MUST contain an 1395 updated Max-Forwards field with a value decremented by one (1). 1397 The Max-Forwards header field MAY be ignored for all other methods 1398 defined by this specification and for any extension methods for which 1399 it is not explicitly referred to as part of that method definition. 1401 10.6. Referer 1403 The Referer[sic] request-header field allows the client to specify, 1404 for the server's benefit, the address (URI) of the resource from 1405 which the Request-URI was obtained (the "referrer", although the 1406 header field is misspelled.) The Referer request-header allows a 1407 server to generate lists of back-links to resources for interest, 1408 logging, optimized caching, etc. It also allows obsolete or mistyped 1409 links to be traced for maintenance. The Referer field MUST NOT be 1410 sent if the Request-URI was obtained from a source that does not have 1411 its own URI, such as input from the user keyboard. 1413 Referer = "Referer" ":" ( absoluteURI | relativeURI ) 1415 Example: 1417 Referer: http://www.w3.org/hypertext/DataSources/Overview.html 1419 If the field value is a relative URI, it SHOULD be interpreted 1420 relative to the Request-URI. The URI MUST NOT include a fragment. 1421 See Section 12.2 for security considerations. 1423 10.7. Retry-After 1425 The Retry-After response-header field can be used with a 503 (Service 1426 Unavailable) response to indicate how long the service is expected to 1427 be unavailable to the requesting client. This field MAY also be used 1428 with any 3xx (Redirection) response to indicate the minimum time the 1429 user-agent is asked wait before issuing the redirected request. The 1430 value of this field can be either an HTTP-date or an integer number 1431 of seconds (in decimal) after the time of the response. 1433 Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) 1435 Two examples of its use are 1436 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 1437 Retry-After: 120 1439 In the latter example, the delay is 2 minutes. 1441 10.8. Server 1443 The Server response-header field contains information about the 1444 software used by the origin server to handle the request. The field 1445 can contain multiple product tokens (Section 2) and comments 1446 identifying the server and any significant subproducts. The product 1447 tokens are listed in order of their significance for identifying the 1448 application. 1450 Server = "Server" ":" 1*( product | comment ) 1452 Example: 1454 Server: CERN/3.0 libwww/2.17 1456 If the response is being forwarded through a proxy, the proxy 1457 application MUST NOT modify the Server response-header. Instead, it 1458 SHOULD include a Via field (as described in Section 8.9 of [Part1]). 1460 Note: Revealing the specific software version of the server might 1461 allow the server machine to become more vulnerable to attacks 1462 against software that is known to contain security holes. Server 1463 implementors are encouraged to make this field a configurable 1464 option. 1466 10.9. User-Agent 1468 The User-Agent request-header field contains information about the 1469 user agent originating the request. This is for statistical 1470 purposes, the tracing of protocol violations, and automated 1471 recognition of user agents for the sake of tailoring responses to 1472 avoid particular user agent limitations. User agents SHOULD include 1473 this field with requests. The field can contain multiple product 1474 tokens (Section 2) and comments identifying the agent and any 1475 subproducts which form a significant part of the user agent. By 1476 convention, the product tokens are listed in order of their 1477 significance for identifying the application. 1479 User-Agent = "User-Agent" ":" 1*( product | comment ) 1481 Example: 1483 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1485 11. IANA Considerations 1487 TBD. 1489 12. Security Considerations 1491 This section is meant to inform application developers, information 1492 providers, and users of the security limitations in HTTP/1.1 as 1493 described by this document. The discussion does not include 1494 definitive solutions to the problems revealed, though it does make 1495 some suggestions for reducing security risks. 1497 12.1. Transfer of Sensitive Information 1499 Like any generic data transfer protocol, HTTP cannot regulate the 1500 content of the data that is transferred, nor is there any a priori 1501 method of determining the sensitivity of any particular piece of 1502 information within the context of any given request. Therefore, 1503 applications SHOULD supply as much control over this information as 1504 possible to the provider of that information. Four header fields are 1505 worth special mention in this context: Server, Via, Referer and From. 1507 Revealing the specific software version of the server might allow the 1508 server machine to become more vulnerable to attacks against software 1509 that is known to contain security holes. Implementors SHOULD make 1510 the Server header field a configurable option. 1512 Proxies which serve as a portal through a network firewall SHOULD 1513 take special precautions regarding the transfer of header information 1514 that identifies the hosts behind the firewall. In particular, they 1515 SHOULD remove, or replace with sanitized versions, any Via fields 1516 generated behind the firewall. 1518 The Referer header allows reading patterns to be studied and reverse 1519 links drawn. Although it can be very useful, its power can be abused 1520 if user details are not separated from the information contained in 1521 the Referer. Even when the personal information has been removed, 1522 the Referer header might indicate a private document's URI whose 1523 publication would be inappropriate. 1525 The information sent in the From field might conflict with the user's 1526 privacy interests or their site's security policy, and hence it 1527 SHOULD NOT be transmitted without the user being able to disable, 1528 enable, and modify the contents of the field. The user MUST be able 1529 to set the contents of this field within a user preference or 1530 application defaults configuration. 1532 We suggest, though do not require, that a convenient toggle interface 1533 be provided for the user to enable or disable the sending of From and 1534 Referer information. 1536 The User-Agent (Section 10.9) or Server (Section 10.8) header fields 1537 can sometimes be used to determine that a specific client or server 1538 have a particular security hole which might be exploited. 1539 Unfortunately, this same information is often used for other valuable 1540 purposes for which HTTP currently has no better mechanism. 1542 12.2. Encoding Sensitive Information in URI's 1544 Because the source of a link might be private information or might 1545 reveal an otherwise private information source, it is strongly 1546 recommended that the user be able to select whether or not the 1547 Referer field is sent. For example, a browser client could have a 1548 toggle switch for browsing openly/anonymously, which would 1549 respectively enable/disable the sending of Referer and From 1550 information. 1552 Clients SHOULD NOT include a Referer header field in a (non-secure) 1553 HTTP request if the referring page was transferred with a secure 1554 protocol. 1556 Authors of services which use the HTTP protocol SHOULD NOT use GET 1557 based forms for the submission of sensitive data, because this will 1558 cause this data to be encoded in the Request-URI. Many existing 1559 servers, proxies, and user agents will log the request URI in some 1560 place where it might be visible to third parties. Servers can use 1561 POST-based form submission instead 1563 12.3. Location Headers and Spoofing 1565 If a single server supports multiple organizations that do not trust 1566 one another, then it MUST check the values of Location and Content- 1567 Location headers in responses that are generated under control of 1568 said organizations to make sure that they do not attempt to 1569 invalidate resources over which they have no authority. 1571 13. Acknowledgments 1573 Based on an XML translation of RFC 2616 by Julian Reschke. 1575 14. References 1577 [Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web 1578 proxy servers", Work in Progress. 1580 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1581 Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, 1582 part 1: URIs, Connections, and Message Parsing", 1583 draft-ietf-httpbis-p1-messaging-00 (work in progress), 1584 December 2007. 1586 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1587 Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, 1588 part 3: Message Payload and Content Negotiation", 1589 draft-ietf-httpbis-p3-payload-00 (work in progress), 1590 December 2007. 1592 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1593 Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, 1594 part 4: Conditional Requests", 1595 draft-ietf-httpbis-p4-conditional-00 (work in progress), 1596 December 2007. 1598 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1599 Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, 1600 part 5: Range Requests and Partial Responses", 1601 draft-ietf-httpbis-p5-range-00 (work in progress), 1602 December 2007. 1604 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1605 Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, 1606 part 6: Caching", draft-ietf-httpbis-p6-cache-00 (work in 1607 progress), December 2007. 1609 [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1610 Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, 1611 part 7: Authentication", draft-ietf-httpbis-p7-auth-00 1612 (work in progress), December 2007. 1614 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1615 and Support", STD 3, RFC 1123, October 1989. 1617 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 1618 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 1619 RFC 2068, January 1997. 1621 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1622 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1623 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1625 [RFC822] Crocker, D., "Standard for the format of ARPA Internet 1626 text messages", STD 11, RFC 822, August 1982. 1628 Appendix A. Changes from RFC 2068 1630 Clarified which error code should be used for inbound server failures 1631 (e.g. DNS failures). (Section 9.5.5). 1633 CREATE had a race that required an Etag be sent when a resource is 1634 first created. (Section 9.2.2). 1636 Rewrite of message transmission requirements to make it much harder 1637 for implementors to get it wrong, as the consequences of errors here 1638 can have significant impact on the Internet, and to deal with the 1639 following problems: 1641 1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where 1642 this was incorrectly placing a requirement on the behavior of an 1643 implementation of a future version of HTTP/1.x 1645 2. Made it clear that user-agents should retry requests, not 1646 "clients" in general. 1648 3. Converted requirements for clients to ignore unexpected 100 1649 (Continue) responses, and for proxies to forward 100 responses, 1650 into a general requirement for 1xx responses. 1652 4. Modified some TCP-specific language, to make it clearer that non- 1653 TCP transports are possible for HTTP. 1655 5. Require that the origin server MUST NOT wait for the request body 1656 before it sends a required 100 (Continue) response. 1658 6. Allow, rather than require, a server to omit 100 (Continue) if it 1659 has already seen some of the request body. 1661 7. Allow servers to defend against denial-of-service attacks and 1662 broken clients. 1664 This change adds the Expect header and 417 status code. 1666 Clean up confusion between 403 and 404 responses. (Section 9.4.4, 1667 9.4.5, and 9.4.11) 1669 The PATCH, LINK, UNLINK methods were defined but not commonly 1670 implemented in previous versions of this specification. See RFC 2068 1671 [RFC2068]. 1673 Index 1675 1 1676 100 Continue (status code) 16 1677 101 Switching Protocols (status code) 17 1679 2 1680 200 OK (status code) 17 1681 201 Created (status code) 17 1682 202 Accepted (status code) 18 1683 203 Non-Authoritative Information (status code) 18 1684 204 No Content (status code) 18 1685 205 Reset Content (status code) 19 1686 206 Partial Content (status code) 19 1688 3 1689 300 Multiple Choices (status code) 19 1690 301 Moved Permanently (status code) 20 1691 302 Found (status code) 20 1692 303 See Other (status code) 21 1693 304 Not Modified (status code) 21 1694 305 Use Proxy (status code) 21 1695 306 (Unused) (status code) 22 1696 307 Temporary Redirect (status code) 22 1698 4 1699 400 Bad Request (status code) 23 1700 401 Unauthorized (status code) 23 1701 402 Payment Required (status code) 23 1702 403 Forbidden (status code) 23 1703 404 Not Found (status code) 23 1704 405 Method Not Allowed (status code) 23 1705 406 Not Acceptable (status code) 23 1706 407 Proxy Authentication Required (status code) 24 1707 408 Request Timeout (status code) 24 1708 409 Conflict (status code) 24 1709 410 Gone (status code) 25 1710 411 Length Required (status code) 25 1711 412 Precondition Failed (status code) 25 1712 413 Request Entity Too Large (status code) 25 1713 414 Request-URI Too Long (status code) 26 1714 415 Unsupported Media Type (status code) 26 1715 416 Requested Range Not Satisfiable (status code) 26 1716 417 Expectation Failed (status code) 26 1718 5 1719 500 Internal Server Error (status code) 26 1720 501 Not Implemented (status code) 27 1721 502 Bad Gateway (status code) 27 1722 503 Service Unavailable (status code) 27 1723 504 Gateway Timeout (status code) 27 1724 505 HTTP Version Not Supported (status code) 27 1726 A 1727 Allow header 28 1729 C 1730 CONNECT method 16 1732 D 1733 DELETE method 15 1735 E 1736 Expect header 28 1738 F 1739 From header 29 1741 G 1742 GET method 12 1743 Grammar 1744 Allow 28 1745 Expect 28 1746 expect-params 28 1747 expectation 28 1748 expectation-extension 28 1749 extension-code 8 1750 extension-method 6 1751 From 29 1752 Location 30 1753 Max-Forwards 30 1754 Method 6 1755 product 5 1756 product-version 5 1757 Reason-Phrase 8 1758 Referer 31 1759 request-header 7 1760 response-header 9 1761 Retry-After 31 1762 Server 32 1763 Status-Code 8 1764 User-Agent 32 1766 H 1767 HEAD method 12 1768 Headers 1769 Allow 28 1770 Expect 28 1771 From 29 1772 Location 30 1773 Max-Forwards 30 1774 Referer 31 1775 Retry-After 31 1776 Server 32 1777 User-Agent 32 1779 L 1780 LINK method 36 1781 Location header 30 1783 M 1784 Max-Forwards header 30 1785 Methods 1786 CONNECT 16 1787 DELETE 15 1788 GET 12 1789 HEAD 12 1790 LINK 36 1791 OPTIONS 11 1792 PATCH 36 1793 POST 13 1794 PUT 14 1795 TRACE 15 1796 UNLINK 36 1798 O 1799 OPTIONS method 11 1801 P 1802 PATCH method 36 1803 POST method 13 1804 PUT method 14 1806 R 1807 Referer header 31 1808 Retry-After header 31 1810 S 1811 Server header 32 1812 Status Codes 1813 100 Continue 16 1814 101 Switching Protocols 17 1815 200 OK 17 1816 201 Created 17 1817 202 Accepted 18 1818 203 Non-Authoritative Information 18 1819 204 No Content 18 1820 205 Reset Content 19 1821 206 Partial Content 19 1822 300 Multiple Choices 19 1823 301 Moved Permanently 20 1824 302 Found 20 1825 303 See Other 21 1826 304 Not Modified 21 1827 305 Use Proxy 21 1828 306 (Unused) 22 1829 307 Temporary Redirect 22 1830 400 Bad Request 23 1831 401 Unauthorized 23 1832 402 Payment Required 23 1833 403 Forbidden 23 1834 404 Not Found 23 1835 405 Method Not Allowed 23 1836 406 Not Acceptable 23 1837 407 Proxy Authentication Required 24 1838 408 Request Timeout 24 1839 409 Conflict 24 1840 410 Gone 25 1841 411 Length Required 25 1842 412 Precondition Failed 25 1843 413 Request Entity Too Large 25 1844 414 Request-URI Too Long 26 1845 415 Unsupported Media Type 26 1846 416 Requested Range Not Satisfiable 26 1847 417 Expectation Failed 26 1848 500 Internal Server Error 26 1849 501 Not Implemented 27 1850 502 Bad Gateway 27 1851 503 Service Unavailable 27 1852 504 Gateway Timeout 27 1853 505 HTTP Version Not Supported 27 1855 T 1856 TRACE method 15 1858 U 1859 UNLINK method 36 1860 User-Agent header 32 1862 Authors' Addresses 1864 Roy T. Fielding (editor) 1865 Day Software 1866 23 Corporate Plaza DR, Suite 280 1867 Newport Beach, CA 92660 1868 USA 1870 Phone: +1-949-706-5300 1871 Fax: +1-949-706-5305 1872 Email: fielding@gbiv.com 1873 URI: http://roy.gbiv.com/ 1875 Jim Gettys 1876 One Laptop per Child 1877 21 Oak Knoll Road 1878 Carlisle, MA 01741 1879 USA 1881 Email: jg@laptop.org 1882 URI: http://www.laptop.org/ 1884 Jeffrey C. Mogul 1885 Hewlett-Packard Company 1886 HP Labs, Large Scale Systems Group 1887 1501 Page Mill Road, MS 1177 1888 Palo Alto, CA 94304 1889 USA 1891 Email: JeffMogul@acm.org 1893 Henrik Frystyk Nielsen 1894 Microsoft Corporation 1895 1 Microsoft Way 1896 Redmond, WA 98052 1897 USA 1899 Email: henrikn@microsoft.com 1900 Larry Masinter 1901 Adobe Systems, Incorporated 1902 345 Park Ave 1903 San Jose, CA 95110 1904 USA 1906 Email: LMM@acm.org 1907 URI: http://larry.masinter.net/ 1909 Paul J. Leach 1910 Microsoft Corporation 1911 1 Microsoft Way 1912 Redmond, WA 98052 1914 Email: paulle@microsoft.com 1916 Tim Berners-Lee 1917 World Wide Web Consortium 1918 MIT Computer Science and Artificial Intelligence Laboratory 1919 The Stata Center, Building 32 1920 32 Vassar Street 1921 Cambridge, MA 02139 1922 USA 1924 Email: timbl@w3.org 1925 URI: http://www.w3.org/People/Berners-Lee/ 1927 Full Copyright Statement 1929 Copyright (C) The IETF Trust (2007). 1931 This document is subject to the rights, licenses and restrictions 1932 contained in BCP 78, and except as set forth therein, the authors 1933 retain all their rights. 1935 This document and the information contained herein are provided on an 1936 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1937 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1938 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1939 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1940 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1941 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1943 Intellectual Property 1945 The IETF takes no position regarding the validity or scope of any 1946 Intellectual Property Rights or other rights that might be claimed to 1947 pertain to the implementation or use of the technology described in 1948 this document or the extent to which any license under such rights 1949 might or might not be available; nor does it represent that it has 1950 made any independent effort to identify any such rights. Information 1951 on the procedures with respect to rights in RFC documents can be 1952 found in BCP 78 and BCP 79. 1954 Copies of IPR disclosures made to the IETF Secretariat and any 1955 assurances of licenses to be made available, or the result of an 1956 attempt made to obtain a general license or permission for the use of 1957 such proprietary rights by implementers or users of this 1958 specification can be obtained from the IETF on-line IPR repository at 1959 http://www.ietf.org/ipr. 1961 The IETF invites any interested party to bring to its attention any 1962 copyrights, patents or patent applications, or other proprietary 1963 rights that may cover technology that may be required to implement 1964 this standard. Please address the information to the IETF at 1965 ietf-ipr@ietf.org. 1967 Acknowledgment 1969 Funding for the RFC Editor function is provided by the IETF 1970 Administrative Support Activity (IASA).