idnits 2.17.1 draft-ietf-httpbis-p2-semantics-01.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 30. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2068. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2079. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2086. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2092. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (January 12, 2008) is 5948 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-01 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-01 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-01 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-01 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-01 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-01 -- 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 2822 (Obsoleted by RFC 5322) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 10 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: 2616 (if approved) J. Gettys 5 Intended status: Standards Track One Laptop per Child 6 Expires: July 15, 2008 J. Mogul 7 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 January 12, 2008 22 HTTP/1.1, part 2: Message Semantics 23 draft-ietf-httpbis-p2-semantics-01 25 Status of this Memo 27 By submitting this Internet-Draft, each author represents that any 28 applicable patent or other IPR claims of which he or she is aware 29 have been or will be disclosed, and any of which he or she becomes 30 aware will be disclosed, in accordance with Section 6 of BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on July 15, 2008. 50 Copyright Notice 52 Copyright (C) The IETF Trust (2008). 54 Abstract 56 The Hypertext Transfer Protocol (HTTP) is an application-level 57 protocol for distributed, collaborative, hypermedia information 58 systems. HTTP has been in use by the World Wide Web global 59 information initiative since 1990. This document is Part 2 of the 60 seven-part specification that defines the protocol referred to as 61 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines 62 the semantics of HTTP messages as expressed by request methods, 63 request-header fields, response status codes, and response-header 64 fields. 66 Editorial Note (To be removed by RFC Editor) 68 Discussion of this draft should take place on the HTTPBIS working 69 group mailing list (ietf-http-wg@w3.org). The current issues list is 70 at and related 71 documents (including fancy diffs) can be found at 72 . 74 This draft incorporates those issue resolutions that were either 75 collected in the original RFC2616 errata list 76 (), or which were agreed upon on the 77 mailing list between October 2006 and November 2007 (as published in 78 "draft-lafon-rfc2616bis-03"). 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 83 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 84 2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . . . 6 85 3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 7 87 5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 8 88 6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 10 89 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 11 91 8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 11 92 8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 11 93 8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 11 94 8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 96 8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 97 8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 98 8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 99 8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 16 100 8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 16 101 8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 17 102 9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 17 103 9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 17 104 9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 17 105 9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 18 106 9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 18 107 9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 18 108 9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 18 109 9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 19 110 9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 19 111 9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 19 112 9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 20 113 9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 20 114 9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 20 115 9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 20 116 9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 21 117 9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 21 118 9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 22 119 9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 22 120 9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 22 121 9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 23 122 9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 23 123 9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 23 124 9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 24 125 9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 24 126 9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 24 127 9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 24 128 9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 24 129 9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 24 130 9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 24 131 9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 25 132 9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 25 133 9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 25 134 9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 26 135 9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 26 136 9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 26 137 9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 26 138 9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 27 139 9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 27 140 9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 27 141 9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 27 142 9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 27 143 9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 27 144 9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 28 145 9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 28 146 9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 28 147 9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 28 148 9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 28 149 10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 29 150 10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 29 151 10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 29 152 10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 153 10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 31 154 10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 32 155 10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 32 156 10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 33 157 10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 33 158 10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 34 159 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 160 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 161 12.1. Transfer of Sensitive Information . . . . . . . . . . . . 34 162 12.2. Encoding Sensitive Information in URI's . . . . . . . . . 35 163 12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 36 164 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 165 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 166 14.1. Normative References . . . . . . . . . . . . . . . . . . . 36 167 14.2. Informative References . . . . . . . . . . . . . . . . . . 37 168 Appendix A. Compatibility with Previous Versions . . . . . . . . 37 169 A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 37 170 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 38 171 Appendix B. Change Log (to be removed by RFC Editor before 172 publication) . . . . . . . . . . . . . . . . . . . . 39 173 B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 39 174 B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 39 175 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 176 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 177 Intellectual Property and Copyright Statements . . . . . . . . . . 47 179 1. Introduction 181 This document defines HTTP/1.1 request and response semantics. Each 182 HTTP message, as defined in [Part1], is in the form of either a 183 request or a response. An HTTP server listens on a connection for 184 HTTP requests and responds to each request, in the order received on 185 that connection, with one or more HTTP response messages. This 186 document defines the commonly agreed upon semantics of the HTTP 187 uniform interface, the intentions defined by each request method, and 188 the various response messages that might be expected as a result of 189 applying that method for the requested resource. 191 This document is currently disorganized in order to minimize the 192 changes between drafts and enable reviewers to see the smaller errata 193 changes. The next draft will reorganize the sections to better 194 reflect the content. In particular, the sections will be ordered 195 according to the typical processing of an HTTP request message (after 196 message parsing): resource mapping, general header fields, methods, 197 request modifiers, response status, and resource metadata. The 198 current mess reflects how widely dispersed these topics and 199 associated requirements had become in [RFC2616]. 201 1.1. Requirements 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in [RFC2119]. 207 An implementation is not compliant if it fails to satisfy one or more 208 of the MUST or REQUIRED level requirements for the protocols it 209 implements. An implementation that satisfies all the MUST or 210 REQUIRED level and all the SHOULD level requirements for its 211 protocols is said to be "unconditionally compliant"; one that 212 satisfies all the MUST level requirements but not all the SHOULD 213 level requirements for its protocols is said to be "conditionally 214 compliant." 216 2. Product Tokens 218 Product tokens are used to allow communicating applications to 219 identify themselves by software name and version. Most fields using 220 product tokens also allow sub-products which form a significant part 221 of the application to be listed, separated by white space. By 222 convention, the products are listed in order of their significance 223 for identifying the application. 225 product = token ["/" product-version] 226 product-version = token 228 Examples: 230 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 231 Server: Apache/0.8.4 233 Product tokens SHOULD be short and to the point. They MUST NOT be 234 used for advertising or other non-essential information. Although 235 any token character MAY appear in a product-version, this token 236 SHOULD only be used for a version identifier (i.e., successive 237 versions of the same product SHOULD only differ in the product- 238 version portion of the product value). 240 3. Method 242 The Method token indicates the method to be performed on the resource 243 identified by the Request-URI. The method is case-sensitive. 245 Method = "OPTIONS" ; Section 8.2 246 | "GET" ; Section 8.3 247 | "HEAD" ; Section 8.4 248 | "POST" ; Section 8.5 249 | "PUT" ; Section 8.6 250 | "DELETE" ; Section 8.7 251 | "TRACE" ; Section 8.8 252 | "CONNECT" ; Section 8.9 253 | extension-method 254 extension-method = token 256 The list of methods allowed by a resource can be specified in an 257 Allow header field (Section 10.1). The return code of the response 258 always notifies the client whether a method is currently allowed on a 259 resource, since the set of allowed methods can change dynamically. 260 An origin server SHOULD return the status code 405 (Method Not 261 Allowed) if the method is known by the origin server but not allowed 262 for the requested resource, and 501 (Not Implemented) if the method 263 is unrecognized or not implemented by the origin server. The methods 264 GET and HEAD MUST be supported by all general-purpose servers. All 265 other methods are OPTIONAL; however, if the above methods are 266 implemented, they MUST be implemented with the same semantics as 267 those specified in Section 8. 269 4. Request Header Fields 271 The request-header fields allow the client to pass additional 272 information about the request, and about the client itself, to the 273 server. These fields act as request modifiers, with semantics 274 equivalent to the parameters on a programming language method 275 invocation. 277 request-header = Accept ; [Part3], Section 5.1 278 | Accept-Charset ; [Part3], Section 5.2 279 | Accept-Encoding ; [Part3], Section 5.3 280 | Accept-Language ; [Part3], Section 5.4 281 | Authorization ; [Part7], Section 3.1 282 | Expect ; Section 10.2 283 | From ; Section 10.3 284 | Host ; [Part1], Section 8.4 285 | If-Match ; [Part4], Section 6.2 286 | If-Modified-Since ; [Part4], Section 6.3 287 | If-None-Match ; [Part4], Section 6.4 288 | If-Range ; [Part5], Section 5.3 289 | If-Unmodified-Since ; [Part4], Section 6.5 290 | Max-Forwards ; Section 10.5 291 | Proxy-Authorization ; [Part7], Section 3.3 292 | Range ; [Part5], Section 5.4 293 | Referer ; Section 10.6 294 | TE ; [Part1], Section 8.8 295 | User-Agent ; Section 10.9 297 Request-header field names can be extended reliably only in 298 combination with a change in the protocol version. However, new or 299 experimental header fields MAY be given the semantics of request- 300 header fields if all parties in the communication recognize them to 301 be request-header fields. Unrecognized header fields are treated as 302 entity-header fields. 304 5. Status Code and Reason Phrase 306 The Status-Code element is a 3-digit integer result code of the 307 attempt to understand and satisfy the request. The status codes 308 listed below are defined in Section 9. The Reason-Phrase is intended 309 to give a short textual description of the Status-Code. The Status- 310 Code is intended for use by automata and the Reason-Phrase is 311 intended for the human user. The client is not required to examine 312 or display the Reason-Phrase. 314 The individual values of the numeric status codes defined for 315 HTTP/1.1, and an example set of corresponding Reason-Phrase's, are 316 presented below. The reason phrases listed here are only 317 recommendations -- they MAY be replaced by local equivalents without 318 affecting the protocol. 320 Status-Code = 321 "100" ; Section 9.1.1: Continue 322 | "101" ; Section 9.1.2: Switching Protocols 323 | "200" ; Section 9.2.1: OK 324 | "201" ; Section 9.2.2: Created 325 | "202" ; Section 9.2.3: Accepted 326 | "203" ; Section 9.2.4: Non-Authoritative Information 327 | "204" ; Section 9.2.5: No Content 328 | "205" ; Section 9.2.6: Reset Content 329 | "206" ; Section 9.2.7: Partial Content 330 | "300" ; Section 9.3.1: Multiple Choices 331 | "301" ; Section 9.3.2: Moved Permanently 332 | "302" ; Section 9.3.3: Found 333 | "303" ; Section 9.3.4: See Other 334 | "304" ; Section 9.3.5: Not Modified 335 | "305" ; Section 9.3.6: Use Proxy 336 | "307" ; Section 9.3.8: Temporary Redirect 337 | "400" ; Section 9.4.1: Bad Request 338 | "401" ; Section 9.4.2: Unauthorized 339 | "402" ; Section 9.4.3: Payment Required 340 | "403" ; Section 9.4.4: Forbidden 341 | "404" ; Section 9.4.5: Not Found 342 | "405" ; Section 9.4.6: Method Not Allowed 343 | "406" ; Section 9.4.7: Not Acceptable 344 | "407" ; Section 9.4.8: Proxy Authentication Required 345 | "408" ; Section 9.4.9: Request Time-out 346 | "409" ; Section 9.4.10: Conflict 347 | "410" ; Section 9.4.11: Gone 348 | "411" ; Section 9.4.12: Length Required 349 | "412" ; Section 9.4.13: Precondition Failed 350 | "413" ; Section 9.4.14: Request Entity Too Large 351 | "414" ; Section 9.4.15: Request-URI Too Large 352 | "415" ; Section 9.4.16: Unsupported Media Type 353 | "416" ; Section 9.4.17: Requested range not satisfiable 354 | "417" ; Section 9.4.18: Expectation Failed 355 | "500" ; Section 9.5.1: Internal Server Error 356 | "501" ; Section 9.5.2: Not Implemented 357 | "502" ; Section 9.5.3: Bad Gateway 358 | "503" ; Section 9.5.4: Service Unavailable 359 | "504" ; Section 9.5.5: Gateway Time-out 360 | "505" ; Section 9.5.6: HTTP Version not supported 361 | extension-code 363 extension-code = 3DIGIT 364 Reason-Phrase = * 366 HTTP status codes are extensible. HTTP applications are not required 367 to understand the meaning of all registered status codes, though such 368 understanding is obviously desirable. However, applications MUST 369 understand the class of any status code, as indicated by the first 370 digit, and treat any unrecognized response as being equivalent to the 371 x00 status code of that class, with the exception that an 372 unrecognized response MUST NOT be cached. For example, if an 373 unrecognized status code of 431 is received by the client, it can 374 safely assume that there was something wrong with its request and 375 treat the response as if it had received a 400 status code. In such 376 cases, user agents SHOULD present to the user the entity returned 377 with the response, since that entity is likely to include human- 378 readable information which will explain the unusual status. 380 6. Response Header Fields 382 The response-header fields allow the server to pass additional 383 information about the response which cannot be placed in the Status- 384 Line. These header fields give information about the server and 385 about further access to the resource identified by the Request-URI. 387 response-header = Accept-Ranges ; [Part5], Section 5.1 388 | Age ; [Part6], Section 15.1 389 | ETag ; [Part4], Section 6.1 390 | Location ; Section 10.4 391 | Proxy-Authenticate ; [Part7], Section 3.2 392 | Retry-After ; Section 10.7 393 | Server ; Section 10.8 394 | Vary ; [Part6], Section 15.5 395 | WWW-Authenticate ; [Part7], Section 3.4 397 Response-header field names can be extended reliably only in 398 combination with a change in the protocol version. However, new or 399 experimental header fields MAY be given the semantics of response- 400 header fields if all parties in the communication recognize them to 401 be response-header fields. Unrecognized header fields are treated as 402 entity-header fields. 404 7. Entity 406 Request and Response messages MAY transfer an entity if not otherwise 407 restricted by the request method or response status code. An entity 408 consists of entity-header fields and an entity-body, although some 409 responses will only include the entity-headers. HTTP entity-body and 410 entity-header fields are defined in [Part3]. 412 An entity-body is only present in a message when a message-body is 413 present, as described in Section 4.3 of [Part1]. The entity-body is 414 obtained from the message-body by decoding any Transfer-Encoding that 415 might have been applied to ensure safe and proper transfer of the 416 message. 418 8. Method Definitions 420 The set of common methods for HTTP/1.1 is defined below. Although 421 this set can be expanded, additional methods cannot be assumed to 422 share the same semantics for separately extended clients and servers. 423 The Host request-header field (Section 8.4 of [Part1]) MUST accompany 424 all HTTP/1.1 requests. 426 8.1. Safe and Idempotent Methods 428 8.1.1. Safe Methods 430 Implementors should be aware that the software represents the user in 431 their interactions over the Internet, and should be careful to allow 432 the user to be aware of any actions they might take which may have an 433 unexpected significance to themselves or others. 435 In particular, the convention has been established that the GET and 436 HEAD methods SHOULD NOT have the significance of taking an action 437 other than retrieval. These methods ought to be considered "safe". 438 This allows user agents to represent other methods, such as POST, PUT 439 and DELETE, in a special way, so that the user is made aware of the 440 fact that a possibly unsafe action is being requested. 442 Naturally, it is not possible to ensure that the server does not 443 generate side-effects as a result of performing a GET request; in 444 fact, some dynamic resources consider that a feature. The important 445 distinction here is that the user did not request the side-effects, 446 so therefore cannot be held accountable for them. 448 8.1.2. Idempotent Methods 450 Methods can also have the property of "idempotence" in that (aside 451 from error or expiration issues) the side-effects of N > 0 identical 452 requests is the same as for a single request. The methods GET, HEAD, 453 PUT and DELETE share this property. Also, the methods OPTIONS and 454 TRACE SHOULD NOT have side effects, and so are inherently idempotent. 456 However, it is possible that a sequence of several requests is non- 457 idempotent, even if all of the methods executed in that sequence are 458 idempotent. (A sequence is idempotent if a single execution of the 459 entire sequence always yields a result that is not changed by a 460 reexecution of all, or part, of that sequence.) For example, a 461 sequence is non-idempotent if its result depends on a value that is 462 later modified in the same sequence. 464 A sequence that never has side effects is idempotent, by definition 465 (provided that no concurrent operations are being executed on the 466 same set of resources). 468 8.2. OPTIONS 470 The OPTIONS method represents a request for information about the 471 communication options available on the request/response chain 472 identified by the Request-URI. This method allows the client to 473 determine the options and/or requirements associated with a resource, 474 or the capabilities of a server, without implying a resource action 475 or initiating a resource retrieval. 477 Responses to this method are not cacheable. 479 If the OPTIONS request includes an entity-body (as indicated by the 480 presence of Content-Length or Transfer-Encoding), then the media type 481 MUST be indicated by a Content-Type field. Although this 482 specification does not define any use for such a body, future 483 extensions to HTTP might use the OPTIONS body to make more detailed 484 queries on the server. A server that does not support such an 485 extension MAY discard the request body. 487 If the Request-URI is an asterisk ("*"), the OPTIONS request is 488 intended to apply to the server in general rather than to a specific 489 resource. Since a server's communication options typically depend on 490 the resource, the "*" request is only useful as a "ping" or "no-op" 491 type of method; it does nothing beyond allowing the client to test 492 the capabilities of the server. For example, this can be used to 493 test a proxy for HTTP/1.1 compliance (or lack thereof). 495 If the Request-URI is not an asterisk, the OPTIONS request applies 496 only to the options that are available when communicating with that 497 resource. 499 A 200 response SHOULD include any header fields that indicate 500 optional features implemented by the server and applicable to that 501 resource (e.g., Allow), possibly including extensions not defined by 502 this specification. The response body, if any, SHOULD also include 503 information about the communication options. The format for such a 504 body is not defined by this specification, but might be defined by 505 future extensions to HTTP. Content negotiation MAY be used to select 506 the appropriate response format. If no response body is included, 507 the response MUST include a Content-Length field with a field-value 508 of "0". 510 The Max-Forwards request-header field MAY be used to target a 511 specific proxy in the request chain. When a proxy receives an 512 OPTIONS request on an absoluteURI for which request forwarding is 513 permitted, the proxy MUST check for a Max-Forwards field. If the 514 Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward 515 the message; instead, the proxy SHOULD respond with its own 516 communication options. If the Max-Forwards field-value is an integer 517 greater than zero, the proxy MUST decrement the field-value when it 518 forwards the request. If no Max-Forwards field is present in the 519 request, then the forwarded request MUST NOT include a Max-Forwards 520 field. 522 8.3. GET 524 The GET method means retrieve whatever information (in the form of an 525 entity) is identified by the Request-URI. If the Request-URI refers 526 to a data-producing process, it is the produced data which shall be 527 returned as the entity in the response and not the source text of the 528 process, unless that text happens to be the output of the process. 530 The semantics of the GET method change to a "conditional GET" if the 531 request message includes an If-Modified-Since, If-Unmodified-Since, 532 If-Match, If-None-Match, or If-Range header field. A conditional GET 533 method requests that the entity be transferred only under the 534 circumstances described by the conditional header field(s). The 535 conditional GET method is intended to reduce unnecessary network 536 usage by allowing cached entities to be refreshed without requiring 537 multiple requests or transferring data already held by the client. 539 The semantics of the GET method change to a "partial GET" if the 540 request message includes a Range header field. A partial GET 541 requests that only part of the entity be transferred, as described in 542 Section 5.4 of [Part5]. The partial GET method is intended to reduce 543 unnecessary network usage by allowing partially-retrieved entities to 544 be completed without transferring data already held by the client. 546 The response to a GET request is cacheable if and only if it meets 547 the requirements for HTTP caching described in [Part6]. 549 See Section 12.2 for security considerations when used for forms. 551 8.4. HEAD 553 The HEAD method is identical to GET except that the server MUST NOT 554 return a message-body in the response. The metainformation contained 555 in the HTTP headers in response to a HEAD request SHOULD be identical 556 to the information sent in response to a GET request. This method 557 can be used for obtaining metainformation about the entity implied by 558 the request without transferring the entity-body itself. This method 559 is often used for testing hypertext links for validity, 560 accessibility, and recent modification. 562 The response to a HEAD request MAY be cacheable in the sense that the 563 information contained in the response MAY be used to update a 564 previously cached entity from that resource. If the new field values 565 indicate that the cached entity differs from the current entity (as 566 would be indicated by a change in Content-Length, Content-MD5, ETag 567 or Last-Modified), then the cache MUST treat the cache entry as 568 stale. 570 8.5. POST 572 The POST method is used to request that the origin server accept the 573 entity enclosed in the request as data to be processed by the 574 resource identified by the Request-URI in the Request-Line. POST is 575 designed to allow a uniform method to cover the following functions: 577 o Annotation of existing resources; 579 o Posting a message to a bulletin board, newsgroup, mailing list, or 580 similar group of articles; 582 o Providing a block of data, such as the result of submitting a 583 form, to a data-handling process; 585 o Extending a database through an append operation. 587 The actual function performed by the POST method is determined by the 588 server and is usually dependent on the Request-URI. 590 The action performed by the POST method might not result in a 591 resource that can be identified by a URI. In this case, either 200 592 (OK) or 204 (No Content) is the appropriate response status, 593 depending on whether or not the response includes an entity that 594 describes the result. 596 If a resource has been created on the origin server, the response 597 SHOULD be 201 (Created) and contain an entity which describes the 598 status of the request and refers to the new resource, and a Location 599 header (see Section 10.4). 601 Responses to this method are not cacheable, unless the response 602 includes appropriate Cache-Control or Expires header fields. 603 However, the 303 (See Other) response can be used to direct the user 604 agent to retrieve a cacheable resource. 606 8.6. PUT 608 The PUT method requests that the enclosed entity be stored under the 609 supplied Request-URI. If the Request-URI refers to an already 610 existing resource, the enclosed entity SHOULD be considered as a 611 modified version of the one residing on the origin server. If the 612 Request-URI does not point to an existing resource, and that URI is 613 capable of being defined as a new resource by the requesting user 614 agent, the origin server can create the resource with that URI. If a 615 new resource is created, the origin server MUST inform the user agent 616 via the 201 (Created) response. If an existing resource is modified, 617 either the 200 (OK) or 204 (No Content) response codes SHOULD be sent 618 to indicate successful completion of the request. If the resource 619 could not be created or modified with the Request-URI, an appropriate 620 error response SHOULD be given that reflects the nature of the 621 problem. The recipient of the entity MUST NOT ignore any Content-* 622 (e.g. Content-Range) headers that it does not understand or 623 implement and MUST return a 501 (Not Implemented) response in such 624 cases. 626 If the request passes through a cache and the Request-URI identifies 627 one or more currently cached entities, those entries SHOULD be 628 treated as stale. Responses to this method are not cacheable. 630 The fundamental difference between the POST and PUT requests is 631 reflected in the different meaning of the Request-URI. The URI in a 632 POST request identifies the resource that will handle the enclosed 633 entity. That resource might be a data-accepting process, a gateway 634 to some other protocol, or a separate entity that accepts 635 annotations. In contrast, the URI in a PUT request identifies the 636 entity enclosed with the request -- the user agent knows what URI is 637 intended and the server MUST NOT attempt to apply the request to some 638 other resource. If the server desires that the request be applied to 639 a different URI, it MUST send a 301 (Moved Permanently) response; the 640 user agent MAY then make its own decision regarding whether or not to 641 redirect the request. 643 A single resource MAY be identified by many different URIs. For 644 example, an article might have a URI for identifying "the current 645 version" which is separate from the URI identifying each particular 646 version. In this case, a PUT request on a general URI might result 647 in several other URIs being defined by the origin server. 649 HTTP/1.1 does not define how a PUT method affects the state of an 650 origin server. 652 Unless otherwise specified for a particular entity-header, the 653 entity-headers in the PUT request SHOULD be applied to the resource 654 created or modified by the PUT. 656 8.7. DELETE 658 The DELETE method requests that the origin server delete the resource 659 identified by the Request-URI. This method MAY be overridden by 660 human intervention (or other means) on the origin server. The client 661 cannot be guaranteed that the operation has been carried out, even if 662 the status code returned from the origin server indicates that the 663 action has been completed successfully. However, the server SHOULD 664 NOT indicate success unless, at the time the response is given, it 665 intends to delete the resource or move it to an inaccessible 666 location. 668 A successful response SHOULD be 200 (OK) if the response includes an 669 entity describing the status, 202 (Accepted) if the action has not 670 yet been enacted, or 204 (No Content) if the action has been enacted 671 but the response does not include an entity. 673 If the request passes through a cache and the Request-URI identifies 674 one or more currently cached entities, those entries SHOULD be 675 treated as stale. Responses to this method are not cacheable. 677 8.8. TRACE 679 The TRACE method is used to invoke a remote, application-layer loop- 680 back of the request message. The final recipient of the request 681 SHOULD reflect the message received back to the client as the entity- 682 body of a 200 (OK) response. The final recipient is either the 683 origin server or the first proxy or gateway to receive a Max-Forwards 684 value of zero (0) in the request (see Section 10.5). A TRACE request 685 MUST NOT include an entity. 687 TRACE allows the client to see what is being received at the other 688 end of the request chain and use that data for testing or diagnostic 689 information. The value of the Via header field (Section 8.9 of 690 [Part1]) is of particular interest, since it acts as a trace of the 691 request chain. Use of the Max-Forwards header field allows the 692 client to limit the length of the request chain, which is useful for 693 testing a chain of proxies forwarding messages in an infinite loop. 695 If the request is valid, the response SHOULD contain the entire 696 request message in the entity-body, with a Content-Type of "message/ 697 http". Responses to this method MUST NOT be cached. 699 8.9. CONNECT 701 This specification reserves the method name CONNECT for use with a 702 proxy that can dynamically switch to being a tunnel (e.g. SSL 703 tunneling [Luo1998]). 705 9. Status Code Definitions 707 Each Status-Code is described below, including a description of which 708 method(s) it can follow and any metainformation required in the 709 response. 711 9.1. Informational 1xx 713 This class of status code indicates a provisional response, 714 consisting only of the Status-Line and optional headers, and is 715 terminated by an empty line. There are no required headers for this 716 class of status code. Since HTTP/1.0 did not define any 1xx status 717 codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client 718 except under experimental conditions. 720 A client MUST be prepared to accept one or more 1xx status responses 721 prior to a regular response, even if the client does not expect a 100 722 (Continue) status message. Unexpected 1xx status responses MAY be 723 ignored by a user agent. 725 Proxies MUST forward 1xx responses, unless the connection between the 726 proxy and its client has been closed, or unless the proxy itself 727 requested the generation of the 1xx response. (For example, if a 728 proxy adds a "Expect: 100-continue" field when it forwards a request, 729 then it need not forward the corresponding 100 (Continue) 730 response(s).) 732 9.1.1. 100 Continue 734 The client SHOULD continue with its request. This interim response 735 is used to inform the client that the initial part of the request has 736 been received and has not yet been rejected by the server. The 737 client SHOULD continue by sending the remainder of the request or, if 738 the request has already been completed, ignore this response. The 739 server MUST send a final response after the request has been 740 completed. See Section 7.2.3 of [Part1] for detailed discussion of 741 the use and handling of this status code. 743 9.1.2. 101 Switching Protocols 745 The server understands and is willing to comply with the client's 746 request, via the Upgrade message header field (Section 5.4 of 747 [Part5]), for a change in the application protocol being used on this 748 connection. The server will switch protocols to those defined by the 749 response's Upgrade header field immediately after the empty line 750 which terminates the 101 response. 752 The protocol SHOULD be switched only when it is advantageous to do 753 so. For example, switching to a newer version of HTTP is 754 advantageous over older versions, and switching to a real-time, 755 synchronous protocol might be advantageous when delivering resources 756 that use such features. 758 9.2. Successful 2xx 760 This class of status code indicates that the client's request was 761 successfully received, understood, and accepted. 763 9.2.1. 200 OK 765 The request has succeeded. The information returned with the 766 response is dependent on the method used in the request, for example: 768 GET an entity corresponding to the requested resource is sent in the 769 response; 771 HEAD the entity-header fields corresponding to the requested 772 resource are sent in the response without any message-body; 774 POST an entity describing or containing the result of the action; 776 TRACE an entity containing the request message as received by the 777 end server. 779 9.2.2. 201 Created 781 The request has been fulfilled and resulted in a new resource being 782 created. The newly created resource can be referenced by the URI(s) 783 returned in the entity of the response, with the most specific URI 784 for the resource given by a Location header field. The response 785 SHOULD include an entity containing a list of resource 786 characteristics and location(s) from which the user or user agent can 787 choose the one most appropriate. The entity format is specified by 788 the media type given in the Content-Type header field. The origin 789 server MUST create the resource before returning the 201 status code. 790 If the action cannot be carried out immediately, the server SHOULD 791 respond with 202 (Accepted) response instead. 793 A 201 response MAY contain an ETag response header field indicating 794 the current value of the entity tag for the requested variant just 795 created, see Section 6.1 of [Part4]. 797 9.2.3. 202 Accepted 799 The request has been accepted for processing, but the processing has 800 not been completed. The request might or might not eventually be 801 acted upon, as it might be disallowed when processing actually takes 802 place. There is no facility for re-sending a status code from an 803 asynchronous operation such as this. 805 The 202 response is intentionally non-committal. Its purpose is to 806 allow a server to accept a request for some other process (perhaps a 807 batch-oriented process that is only run once per day) without 808 requiring that the user agent's connection to the server persist 809 until the process is completed. The entity returned with this 810 response SHOULD include an indication of the request's current status 811 and either a pointer to a status monitor or some estimate of when the 812 user can expect the request to be fulfilled. 814 9.2.4. 203 Non-Authoritative Information 816 The returned metainformation in the entity-header is not the 817 definitive set as available from the origin server, but is gathered 818 from a local or a third-party copy. The set presented MAY be a 819 subset or superset of the original version. For example, including 820 local annotation information about the resource might result in a 821 superset of the metainformation known by the origin server. Use of 822 this response code is not required and is only appropriate when the 823 response would otherwise be 200 (OK). 825 9.2.5. 204 No Content 827 The server has fulfilled the request but does not need to return an 828 entity-body, and might want to return updated metainformation. The 829 response MAY include new or updated metainformation in the form of 830 entity-headers, which if present SHOULD be associated with the 831 requested variant. 833 If the client is a user agent, it SHOULD NOT change its document view 834 from that which caused the request to be sent. This response is 835 primarily intended to allow input for actions to take place without 836 causing a change to the user agent's active document view, although 837 any new or updated metainformation SHOULD be applied to the document 838 currently in the user agent's active view. 840 The 204 response MUST NOT include a message-body, and thus is always 841 terminated by the first empty line after the header fields. 843 9.2.6. 205 Reset Content 845 The server has fulfilled the request and the user agent SHOULD reset 846 the document view which caused the request to be sent. This response 847 is primarily intended to allow input for actions to take place via 848 user input, followed by a clearing of the form in which the input is 849 given so that the user can easily initiate another input action. The 850 response MUST NOT include an entity. 852 9.2.7. 206 Partial Content 854 The server has fulfilled the partial GET request for the resource and 855 the enclosed entity is a partial representation as defined in 856 [Part5]. 858 9.3. Redirection 3xx 860 This class of status code indicates that further action needs to be 861 taken by the user agent in order to fulfill the request. The action 862 required MAY be carried out by the user agent without interaction 863 with the user if and only if the method used in the second request is 864 GET or HEAD. A client SHOULD detect infinite redirection loops, 865 since such loops generate network traffic for each redirection. 867 Note: previous versions of this specification recommended a 868 maximum of five redirections. Content developers should be aware 869 that there might be clients that implement such a fixed 870 limitation. 872 9.3.1. 300 Multiple Choices 874 The requested resource corresponds to any one of a set of 875 representations, each with its own specific location, and agent- 876 driven negotiation information (Section 4 of [Part3]) is being 877 provided so that the user (or user agent) can select a preferred 878 representation and redirect its request to that location. 880 Unless it was a HEAD request, the response SHOULD include an entity 881 containing a list of resource characteristics and location(s) from 882 which the user or user agent can choose the one most appropriate. 883 The entity format is specified by the media type given in the 884 Content-Type header field. Depending upon the format and the 885 capabilities of the user agent, selection of the most appropriate 886 choice MAY be performed automatically. However, this specification 887 does not define any standard for such automatic selection. 889 If the server has a preferred choice of representation, it SHOULD 890 include the specific URI for that representation in the Location 891 field; user agents MAY use the Location field value for automatic 892 redirection. This response is cacheable unless indicated otherwise. 894 9.3.2. 301 Moved Permanently 896 The requested resource has been assigned a new permanent URI and any 897 future references to this resource SHOULD use one of the returned 898 URIs. Clients with link editing capabilities ought to automatically 899 re-link references to the Request-URI to one or more of the new 900 references returned by the server, where possible. This response is 901 cacheable unless indicated otherwise. 903 The new permanent URI SHOULD be given by the Location field in the 904 response. Unless the request method was HEAD, the entity of the 905 response SHOULD contain a short hypertext note with a hyperlink to 906 the new URI(s). 908 If the 301 status code is received in response to a request method 909 that is known to be "safe", as defined in Section 8.1.1, then the 910 request MAY be automatically redirected by the user agent without 911 confirmation. Otherwise, the user agent MUST NOT automatically 912 redirect the request unless it can be confirmed by the user, since 913 this might change the conditions under which the request was issued. 915 Note: When automatically redirecting a POST request after 916 receiving a 301 status code, some existing HTTP/1.0 user agents 917 will erroneously change it into a GET request. 919 9.3.3. 302 Found 921 The requested resource resides temporarily under a different URI. 922 Since the redirection might be altered on occasion, the client SHOULD 923 continue to use the Request-URI for future requests. This response 924 is only cacheable if indicated by a Cache-Control or Expires header 925 field. 927 The temporary URI SHOULD be given by the Location field in the 928 response. Unless the request method was HEAD, the entity of the 929 response SHOULD contain a short hypertext note with a hyperlink to 930 the new URI(s). 932 If the 302 status code is received in response to a request method 933 that is known to be "safe", as defined in Section 8.1.1, then the 934 request MAY be automatically redirected by the user agent without 935 confirmation. Otherwise, the user agent MUST NOT automatically 936 redirect the request unless it can be confirmed by the user, since 937 this might change the conditions under which the request was issued. 939 Note: [RFC1945] and [RFC2068] specify that the client is not 940 allowed to change the method on the redirected request. However, 941 most existing user agent implementations treat 302 as if it were a 942 303 response, performing a GET on the Location field-value 943 regardless of the original request method. The status codes 303 944 and 307 have been added for servers that wish to make 945 unambiguously clear which kind of reaction is expected of the 946 client. 948 9.3.4. 303 See Other 950 The response to the request can be found under a different URI and 951 SHOULD be retrieved using a GET method on that resource. This method 952 exists primarily to allow the output of a POST-activated script to 953 redirect the user agent to a selected resource. The new URI is not a 954 substitute reference for the originally requested resource. The 303 955 response MUST NOT be cached, but the response to the second 956 (redirected) request might be cacheable. 958 The different URI SHOULD be given by the Location field in the 959 response. Unless the request method was HEAD, the entity of the 960 response SHOULD contain a short hypertext note with a hyperlink to 961 the new URI(s). 963 Note: Many pre-HTTP/1.1 user agents do not understand the 303 964 status. When interoperability with such clients is a concern, the 965 302 status code may be used instead, since most user agents react 966 to a 302 response as described here for 303. 968 9.3.5. 304 Not Modified 970 The response to the request has not been modified since the 971 conditions indicated by the client's conditional GET request, as 972 defined in [Part4]. 974 9.3.6. 305 Use Proxy 976 The requested resource MUST be accessed through the proxy given by 977 the Location field. The Location field gives the URI of the proxy. 978 The recipient is expected to repeat this single request via the 979 proxy. 305 responses MUST only be generated by origin servers. 981 Note: [RFC2068] was not clear that 305 was intended to redirect a 982 single request, and to be generated by origin servers only. Not 983 observing these limitations has significant security consequences. 985 9.3.7. 306 (Unused) 987 The 306 status code was used in a previous version of the 988 specification, is no longer used, and the code is reserved. 990 9.3.8. 307 Temporary Redirect 992 The requested resource resides temporarily under a different URI. 993 Since the redirection MAY be altered on occasion, the client SHOULD 994 continue to use the Request-URI for future requests. This response 995 is only cacheable if indicated by a Cache-Control or Expires header 996 field. 998 The temporary URI SHOULD be given by the Location field in the 999 response. Unless the request method was HEAD, the entity of the 1000 response SHOULD contain a short hypertext note with a hyperlink to 1001 the new URI(s) , since many pre-HTTP/1.1 user agents do not 1002 understand the 307 status. Therefore, the note SHOULD contain the 1003 information necessary for a user to repeat the original request on 1004 the new URI. 1006 If the 307 status code is received in response to a request method 1007 that is known to be "safe", as defined in Section 8.1.1, then the 1008 request MAY be automatically redirected by the user agent without 1009 confirmation. Otherwise, the user agent MUST NOT automatically 1010 redirect the request unless it can be confirmed by the user, since 1011 this might change the conditions under which the request was issued. 1013 9.4. Client Error 4xx 1015 The 4xx class of status code is intended for cases in which the 1016 client seems to have erred. Except when responding to a HEAD 1017 request, the server SHOULD include an entity containing an 1018 explanation of the error situation, and whether it is a temporary or 1019 permanent condition. These status codes are applicable to any 1020 request method. User agents SHOULD display any included entity to 1021 the user. 1023 If the client is sending data, a server implementation using TCP 1024 SHOULD be careful to ensure that the client acknowledges receipt of 1025 the packet(s) containing the response, before the server closes the 1026 input connection. If the client continues sending data to the server 1027 after the close, the server's TCP stack will send a reset packet to 1028 the client, which may erase the client's unacknowledged input buffers 1029 before they can be read and interpreted by the HTTP application. 1031 9.4.1. 400 Bad Request 1033 The request could not be understood by the server due to malformed 1034 syntax. The client SHOULD NOT repeat the request without 1035 modifications. 1037 9.4.2. 401 Unauthorized 1039 The request requires user authentication (see [Part7]). 1041 9.4.3. 402 Payment Required 1043 This code is reserved for future use. 1045 9.4.4. 403 Forbidden 1047 The server understood the request, but is refusing to fulfill it. 1048 Authorization will not help and the request SHOULD NOT be repeated. 1049 If the request method was not HEAD and the server wishes to make 1050 public why the request has not been fulfilled, it SHOULD describe the 1051 reason for the refusal in the entity. If the server does not wish to 1052 make this information available to the client, the status code 404 1053 (Not Found) can be used instead. 1055 9.4.5. 404 Not Found 1057 The server has not found anything matching the Request-URI. No 1058 indication is given of whether the condition is temporary or 1059 permanent. The 410 (Gone) status code SHOULD be used if the server 1060 knows, through some internally configurable mechanism, that an old 1061 resource is permanently unavailable and has no forwarding address. 1062 This status code is commonly used when the server does not wish to 1063 reveal exactly why the request has been refused, or when no other 1064 response is applicable. 1066 9.4.6. 405 Method Not Allowed 1068 The method specified in the Request-Line is not allowed for the 1069 resource identified by the Request-URI. The response MUST include an 1070 Allow header containing a list of valid methods for the requested 1071 resource. 1073 9.4.7. 406 Not Acceptable 1075 The resource identified by the request is only capable of generating 1076 response entities which have content characteristics not acceptable 1077 according to the accept headers sent in the request. 1079 Unless it was a HEAD request, the response SHOULD include an entity 1080 containing a list of available entity characteristics and location(s) 1081 from which the user or user agent can choose the one most 1082 appropriate. The entity format is specified by the media type given 1083 in the Content-Type header field. Depending upon the format and the 1084 capabilities of the user agent, selection of the most appropriate 1085 choice MAY be performed automatically. However, this specification 1086 does not define any standard for such automatic selection. 1088 Note: HTTP/1.1 servers are allowed to return responses which are 1089 not acceptable according to the accept headers sent in the 1090 request. In some cases, this may even be preferable to sending a 1091 406 response. User agents are encouraged to inspect the headers 1092 of an incoming response to determine if it is acceptable. 1094 If the response could be unacceptable, a user agent SHOULD 1095 temporarily stop receipt of more data and query the user for a 1096 decision on further actions. 1098 9.4.8. 407 Proxy Authentication Required 1100 This code is similar to 401 (Unauthorized), but indicates that the 1101 client must first authenticate itself with the proxy (see [Part7]). 1103 9.4.9. 408 Request Timeout 1105 The client did not produce a request within the time that the server 1106 was prepared to wait. The client MAY repeat the request without 1107 modifications at any later time. 1109 9.4.10. 409 Conflict 1111 The request could not be completed due to a conflict with the current 1112 state of the resource. This code is only allowed in situations where 1113 it is expected that the user might be able to resolve the conflict 1114 and resubmit the request. The response body SHOULD include enough 1115 information for the user to recognize the source of the conflict. 1116 Ideally, the response entity would include enough information for the 1117 user or user agent to fix the problem; however, that might not be 1118 possible and is not required. 1120 Conflicts are most likely to occur in response to a PUT request. For 1121 example, if versioning were being used and the entity being PUT 1122 included changes to a resource which conflict with those made by an 1123 earlier (third-party) request, the server might use the 409 response 1124 to indicate that it can't complete the request. In this case, the 1125 response entity would likely contain a list of the differences 1126 between the two versions in a format defined by the response Content- 1127 Type. 1129 9.4.11. 410 Gone 1131 The requested resource is no longer available at the server and no 1132 forwarding address is known. This condition is expected to be 1133 considered permanent. Clients with link editing capabilities SHOULD 1134 delete references to the Request-URI after user approval. If the 1135 server does not know, or has no facility to determine, whether or not 1136 the condition is permanent, the status code 404 (Not Found) SHOULD be 1137 used instead. This response is cacheable unless indicated otherwise. 1139 The 410 response is primarily intended to assist the task of web 1140 maintenance by notifying the recipient that the resource is 1141 intentionally unavailable and that the server owners desire that 1142 remote links to that resource be removed. Such an event is common 1143 for limited-time, promotional services and for resources belonging to 1144 individuals no longer working at the server's site. It is not 1145 necessary to mark all permanently unavailable resources as "gone" or 1146 to keep the mark for any length of time -- that is left to the 1147 discretion of the server owner. 1149 9.4.12. 411 Length Required 1151 The server refuses to accept the request without a defined Content- 1152 Length. The client MAY repeat the request if it adds a valid 1153 Content-Length header field containing the length of the message-body 1154 in the request message. 1156 9.4.13. 412 Precondition Failed 1158 The precondition given in one or more of the request-header fields 1159 evaluated to false when it was tested on the server, as defined in 1160 [Part4]. 1162 9.4.14. 413 Request Entity Too Large 1164 The server is refusing to process a request because the request 1165 entity is larger than the server is willing or able to process. The 1166 server MAY close the connection to prevent the client from continuing 1167 the request. 1169 If the condition is temporary, the server SHOULD include a Retry- 1170 After header field to indicate that it is temporary and after what 1171 time the client MAY try again. 1173 9.4.15. 414 Request-URI Too Long 1175 The server is refusing to service the request because the Request-URI 1176 is longer than the server is willing to interpret. This rare 1177 condition is only likely to occur when a client has improperly 1178 converted a POST request to a GET request with long query 1179 information, when the client has descended into a URI "black hole" of 1180 redirection (e.g., a redirected URI prefix that points to a suffix of 1181 itself), or when the server is under attack by a client attempting to 1182 exploit security holes present in some servers using fixed-length 1183 buffers for reading or manipulating the Request-URI. 1185 9.4.16. 415 Unsupported Media Type 1187 The server is refusing to service the request because the entity of 1188 the request is in a format not supported by the requested resource 1189 for the requested method. 1191 9.4.17. 416 Requested Range Not Satisfiable 1193 The request included a Range request-header field (Section 5.4 of 1194 [Part5]) and none of the range-specifier values in this field overlap 1195 the current extent of the selected resource. 1197 9.4.18. 417 Expectation Failed 1199 The expectation given in an Expect request-header field (see 1200 Section 10.2) could not be met by this server, or, if the server is a 1201 proxy, the server has unambiguous evidence that the request could not 1202 be met by the next-hop server. 1204 9.5. Server Error 5xx 1206 Response status codes beginning with the digit "5" indicate cases in 1207 which the server is aware that it has erred or is incapable of 1208 performing the request. Except when responding to a HEAD request, 1209 the server SHOULD include an entity containing an explanation of the 1210 error situation, and whether it is a temporary or permanent 1211 condition. User agents SHOULD display any included entity to the 1212 user. These response codes are applicable to any request method. 1214 9.5.1. 500 Internal Server Error 1216 The server encountered an unexpected condition which prevented it 1217 from fulfilling the request. 1219 9.5.2. 501 Not Implemented 1221 The server does not support the functionality required to fulfill the 1222 request. This is the appropriate response when the server does not 1223 recognize the request method and is not capable of supporting it for 1224 any resource. 1226 9.5.3. 502 Bad Gateway 1228 The server, while acting as a gateway or proxy, received an invalid 1229 response from the upstream server it accessed in attempting to 1230 fulfill the request. 1232 9.5.4. 503 Service Unavailable 1234 The server is currently unable to handle the request due to a 1235 temporary overloading or maintenance of the server. The implication 1236 is that this is a temporary condition which will be alleviated after 1237 some delay. If known, the length of the delay MAY be indicated in a 1238 Retry-After header. If no Retry-After is given, the client SHOULD 1239 handle the response as it would for a 500 response. 1241 Note: The existence of the 503 status code does not imply that a 1242 server must use it when becoming overloaded. Some servers may 1243 wish to simply refuse the connection. 1245 9.5.5. 504 Gateway Timeout 1247 The server, while acting as a gateway or proxy, did not receive a 1248 timely response from the upstream server specified by the URI (e.g. 1249 HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed 1250 to access in attempting to complete the request. 1252 Note: Note to implementors: some deployed proxies are known to 1253 return 400 or 500 when DNS lookups time out. 1255 9.5.6. 505 HTTP Version Not Supported 1257 The server does not support, or refuses to support, the HTTP protocol 1258 version that was used in the request message. The server is 1259 indicating that it is unable or unwilling to complete the request 1260 using the same major version as the client, as described in Section 1261 3.1 of [Part1], other than with this error message. The response 1262 SHOULD contain an entity describing why that version is not supported 1263 and what other protocols are supported by that server. 1265 10. Header Field Definitions 1267 This section defines the syntax and semantics of HTTP/1.1 header 1268 fields related to request and response semantics. 1270 For entity-header fields, both sender and recipient refer to either 1271 the client or the server, depending on who sends and who receives the 1272 entity. 1274 10.1. Allow 1276 The Allow entity-header field lists the set of methods supported by 1277 the resource identified by the Request-URI. The purpose of this 1278 field is strictly to inform the recipient of valid methods associated 1279 with the resource. An Allow header field MUST be present in a 405 1280 (Method Not Allowed) response. 1282 Allow = "Allow" ":" #Method 1284 Example of use: 1286 Allow: GET, HEAD, PUT 1288 This field cannot prevent a client from trying other methods. 1289 However, the indications given by the Allow header field value SHOULD 1290 be followed. The actual set of allowed methods is defined by the 1291 origin server at the time of each request. 1293 The Allow header field MAY be provided with a PUT request to 1294 recommend the methods to be supported by the new or modified 1295 resource. The server is not required to support these methods and 1296 SHOULD include an Allow header in the response giving the actual 1297 supported methods. 1299 A proxy MUST NOT modify the Allow header field even if it does not 1300 understand all the methods specified, since the user agent might have 1301 other means of communicating with the origin server. 1303 10.2. Expect 1305 The Expect request-header field is used to indicate that particular 1306 server behaviors are required by the client. 1308 Expect = "Expect" ":" 1#expectation 1310 expectation = "100-continue" | expectation-extension 1311 expectation-extension = token [ "=" ( token | quoted-string ) 1312 *expect-params ] 1314 expect-params = ";" token [ "=" ( token | quoted-string ) ] 1316 A server that does not understand or is unable to comply with any of 1317 the expectation values in the Expect field of a request MUST respond 1318 with appropriate error status. The server MUST respond with a 417 1319 (Expectation Failed) status if any of the expectations cannot be met 1320 or, if there are other problems with the request, some other 4xx 1321 status. 1323 This header field is defined with extensible syntax to allow for 1324 future extensions. If a server receives a request containing an 1325 Expect field that includes an expectation-extension that it does not 1326 support, it MUST respond with a 417 (Expectation Failed) status. 1328 Comparison of expectation values is case-insensitive for unquoted 1329 tokens (including the 100-continue token), and is case-sensitive for 1330 quoted-string expectation-extensions. 1332 The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST 1333 return a 417 (Expectation Failed) status if it receives a request 1334 with an expectation that it cannot meet. However, the Expect 1335 request-header itself is end-to-end; it MUST be forwarded if the 1336 request is forwarded. 1338 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the 1339 Expect header. 1341 See Section 7.2.3 of [Part1] for the use of the 100 (Continue) 1342 status. 1344 10.3. From 1346 The From request-header field, if given, SHOULD contain an Internet 1347 e-mail address for the human user who controls the requesting user 1348 agent. The address SHOULD be machine-usable, as defined by "mailbox" 1349 in Section 3.4 of [RFC2822]: 1351 From = "From" ":" mailbox 1353 An example is: 1355 From: webmaster@example.org 1357 This header field MAY be used for logging purposes and as a means for 1358 identifying the source of invalid or unwanted requests. It SHOULD 1359 NOT be used as an insecure form of access protection. The 1360 interpretation of this field is that the request is being performed 1361 on behalf of the person given, who accepts responsibility for the 1362 method performed. In particular, robot agents SHOULD include this 1363 header so that the person responsible for running the robot can be 1364 contacted if problems occur on the receiving end. 1366 The Internet e-mail address in this field MAY be separate from the 1367 Internet host which issued the request. For example, when a request 1368 is passed through a proxy the original issuer's address SHOULD be 1369 used. 1371 The client SHOULD NOT send the From header field without the user's 1372 approval, as it might conflict with the user's privacy interests or 1373 their site's security policy. It is strongly recommended that the 1374 user be able to disable, enable, and modify the value of this field 1375 at any time prior to a request. 1377 10.4. Location 1379 The Location response-header field is used to redirect the recipient 1380 to a location other than the Request-URI for completion of the 1381 request or identification of a new resource. For 201 (Created) 1382 responses, the Location is that of the new resource which was created 1383 by the request. For 3xx responses, the location SHOULD indicate the 1384 server's preferred URI for automatic redirection to the resource. 1385 The field value consists of a single absolute URI. 1387 Location = "Location" ":" absoluteURI [ "#" fragment ] 1389 An example is: 1391 Location: http://www.example.org/pub/WWW/People.html 1393 Note: The Content-Location header field (Section 5.7 of [Part3]) 1394 differs from Location in that the Content-Location identifies the 1395 original location of the entity enclosed in the request. It is 1396 therefore possible for a response to contain header fields for 1397 both Location and Content-Location. 1399 There are circumstances in which a fragment identifier in a Location 1400 URL would not be appropriate: 1402 o With a 201 Created response, because in this usage the Location 1403 header specifies the URL for the entire created resource. 1405 o With a 300 Multiple Choices, since the choice decision is intended 1406 to be made on resource characteristics and not fragment 1407 characteristics. 1409 o With 305 Use Proxy. 1411 10.5. Max-Forwards 1413 The Max-Forwards request-header field provides a mechanism with the 1414 TRACE (Section 8.8) and OPTIONS (Section 8.2) methods to limit the 1415 number of proxies or gateways that can forward the request to the 1416 next inbound server. This can be useful when the client is 1417 attempting to trace a request chain which appears to be failing or 1418 looping in mid-chain. 1420 Max-Forwards = "Max-Forwards" ":" 1*DIGIT 1422 The Max-Forwards value is a decimal integer indicating the remaining 1423 number of times this request message may be forwarded. 1425 Each proxy or gateway recipient of a TRACE or OPTIONS request 1426 containing a Max-Forwards header field MUST check and update its 1427 value prior to forwarding the request. If the received value is zero 1428 (0), the recipient MUST NOT forward the request; instead, it MUST 1429 respond as the final recipient. If the received Max-Forwards value 1430 is greater than zero, then the forwarded message MUST contain an 1431 updated Max-Forwards field with a value decremented by one (1). 1433 The Max-Forwards header field MAY be ignored for all other methods 1434 defined by this specification and for any extension methods for which 1435 it is not explicitly referred to as part of that method definition. 1437 10.6. Referer 1439 The Referer[sic] request-header field allows the client to specify, 1440 for the server's benefit, the address (URI) of the resource from 1441 which the Request-URI was obtained (the "referrer", although the 1442 header field is misspelled.) The Referer request-header allows a 1443 server to generate lists of back-links to resources for interest, 1444 logging, optimized caching, etc. It also allows obsolete or mistyped 1445 links to be traced for maintenance. The Referer field MUST NOT be 1446 sent if the Request-URI was obtained from a source that does not have 1447 its own URI, such as input from the user keyboard. 1449 Referer = "Referer" ":" ( absoluteURI | relativeURI ) 1451 Example: 1453 Referer: http://www.example.org/hypertext/Overview.html 1455 If the field value is a relative URI, it SHOULD be interpreted 1456 relative to the Request-URI. The URI MUST NOT include a fragment. 1458 See Section 12.2 for security considerations. 1460 10.7. Retry-After 1462 The Retry-After response-header field can be used with a 503 (Service 1463 Unavailable) response to indicate how long the service is expected to 1464 be unavailable to the requesting client. This field MAY also be used 1465 with any 3xx (Redirection) response to indicate the minimum time the 1466 user-agent is asked wait before issuing the redirected request. The 1467 value of this field can be either an HTTP-date or an integer number 1468 of seconds (in decimal) after the time of the response. 1470 Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) 1472 Two examples of its use are 1474 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 1475 Retry-After: 120 1477 In the latter example, the delay is 2 minutes. 1479 10.8. Server 1481 The Server response-header field contains information about the 1482 software used by the origin server to handle the request. The field 1483 can contain multiple product tokens (Section 2) and comments 1484 identifying the server and any significant subproducts. The product 1485 tokens are listed in order of their significance for identifying the 1486 application. 1488 Server = "Server" ":" 1*( product | comment ) 1490 Example: 1492 Server: CERN/3.0 libwww/2.17 1494 If the response is being forwarded through a proxy, the proxy 1495 application MUST NOT modify the Server response-header. Instead, it 1496 MUST include a Via field (as described in Section 8.9 of [Part1]). 1498 Note: Revealing the specific software version of the server might 1499 allow the server machine to become more vulnerable to attacks 1500 against software that is known to contain security holes. Server 1501 implementors are encouraged to make this field a configurable 1502 option. 1504 10.9. User-Agent 1506 The User-Agent request-header field contains information about the 1507 user agent originating the request. This is for statistical 1508 purposes, the tracing of protocol violations, and automated 1509 recognition of user agents for the sake of tailoring responses to 1510 avoid particular user agent limitations. User agents SHOULD include 1511 this field with requests. The field can contain multiple product 1512 tokens (Section 2) and comments identifying the agent and any 1513 subproducts which form a significant part of the user agent. By 1514 convention, the product tokens are listed in order of their 1515 significance for identifying the application. 1517 User-Agent = "User-Agent" ":" 1*( product | comment ) 1519 Example: 1521 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1523 11. IANA Considerations 1525 TBD. 1527 12. Security Considerations 1529 This section is meant to inform application developers, information 1530 providers, and users of the security limitations in HTTP/1.1 as 1531 described by this document. The discussion does not include 1532 definitive solutions to the problems revealed, though it does make 1533 some suggestions for reducing security risks. 1535 12.1. Transfer of Sensitive Information 1537 Like any generic data transfer protocol, HTTP cannot regulate the 1538 content of the data that is transferred, nor is there any a priori 1539 method of determining the sensitivity of any particular piece of 1540 information within the context of any given request. Therefore, 1541 applications SHOULD supply as much control over this information as 1542 possible to the provider of that information. Four header fields are 1543 worth special mention in this context: Server, Via, Referer and From. 1545 Revealing the specific software version of the server might allow the 1546 server machine to become more vulnerable to attacks against software 1547 that is known to contain security holes. Implementors SHOULD make 1548 the Server header field a configurable option. 1550 Proxies which serve as a portal through a network firewall SHOULD 1551 take special precautions regarding the transfer of header information 1552 that identifies the hosts behind the firewall. In particular, they 1553 SHOULD remove, or replace with sanitized versions, any Via fields 1554 generated behind the firewall. 1556 The Referer header allows reading patterns to be studied and reverse 1557 links drawn. Although it can be very useful, its power can be abused 1558 if user details are not separated from the information contained in 1559 the Referer. Even when the personal information has been removed, 1560 the Referer header might indicate a private document's URI whose 1561 publication would be inappropriate. 1563 The information sent in the From field might conflict with the user's 1564 privacy interests or their site's security policy, and hence it 1565 SHOULD NOT be transmitted without the user being able to disable, 1566 enable, and modify the contents of the field. The user MUST be able 1567 to set the contents of this field within a user preference or 1568 application defaults configuration. 1570 We suggest, though do not require, that a convenient toggle interface 1571 be provided for the user to enable or disable the sending of From and 1572 Referer information. 1574 The User-Agent (Section 10.9) or Server (Section 10.8) header fields 1575 can sometimes be used to determine that a specific client or server 1576 have a particular security hole which might be exploited. 1577 Unfortunately, this same information is often used for other valuable 1578 purposes for which HTTP currently has no better mechanism. 1580 12.2. Encoding Sensitive Information in URI's 1582 Because the source of a link might be private information or might 1583 reveal an otherwise private information source, it is strongly 1584 recommended that the user be able to select whether or not the 1585 Referer field is sent. For example, a browser client could have a 1586 toggle switch for browsing openly/anonymously, which would 1587 respectively enable/disable the sending of Referer and From 1588 information. 1590 Clients SHOULD NOT include a Referer header field in a (non-secure) 1591 HTTP request if the referring page was transferred with a secure 1592 protocol. 1594 Authors of services which use the HTTP protocol SHOULD NOT use GET 1595 based forms for the submission of sensitive data, because this will 1596 cause this data to be encoded in the Request-URI. Many existing 1597 servers, proxies, and user agents will log the request URI in some 1598 place where it might be visible to third parties. Servers can use 1599 POST-based form submission instead 1601 12.3. Location Headers and Spoofing 1603 If a single server supports multiple organizations that do not trust 1604 one another, then it MUST check the values of Location and Content- 1605 Location headers in responses that are generated under control of 1606 said organizations to make sure that they do not attempt to 1607 invalidate resources over which they have no authority. 1609 13. Acknowledgments 1611 14. References 1613 14.1. Normative References 1615 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1616 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1617 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 1618 and Message Parsing", draft-ietf-httpbis-p1-messaging-01 1619 (work in progress), January 2008. 1621 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1622 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1623 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 1624 and Content Negotiation", draft-ietf-httpbis-p3-payload-01 1625 (work in progress), January 2008. 1627 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1628 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1629 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 1630 Requests", draft-ietf-httpbis-p4-conditional-01 (work in 1631 progress), January 2008. 1633 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1634 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1635 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 1636 Partial Responses", draft-ietf-httpbis-p5-range-01 (work 1637 in progress), January 2008. 1639 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1640 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1641 and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", 1642 draft-ietf-httpbis-p6-cache-01 (work in progress), 1643 January 2008. 1645 [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1646 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1647 and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", 1648 draft-ietf-httpbis-p7-auth-01 (work in progress), 1649 January 2008. 1651 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1652 Requirement Levels", BCP 14, RFC 2119, March 1997. 1654 14.2. Informative References 1656 [Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web 1657 proxy servers", draft-luotonen-web-proxy-tunneling-01 1658 (work in progress), August 1998. 1660 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1661 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1663 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 1664 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 1665 RFC 2068, January 1997. 1667 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1668 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1669 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1671 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1672 April 2001. 1674 Appendix A. Compatibility with Previous Versions 1676 A.1. Changes from RFC 2068 1678 Clarified which error code should be used for inbound server failures 1679 (e.g. DNS failures). (Section 9.5.5). 1681 201 (Created) had a race that required an Etag be sent when a 1682 resource is first created. (Section 9.2.2). 1684 Rewrite of message transmission requirements to make it much harder 1685 for implementors to get it wrong, as the consequences of errors here 1686 can have significant impact on the Internet, and to deal with the 1687 following problems: 1689 1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where 1690 this was incorrectly placing a requirement on the behavior of an 1691 implementation of a future version of HTTP/1.x 1693 2. Made it clear that user-agents should retry requests, not 1694 "clients" in general. 1696 3. Converted requirements for clients to ignore unexpected 100 1697 (Continue) responses, and for proxies to forward 100 responses, 1698 into a general requirement for 1xx responses. 1700 4. Modified some TCP-specific language, to make it clearer that non- 1701 TCP transports are possible for HTTP. 1703 5. Require that the origin server MUST NOT wait for the request body 1704 before it sends a required 100 (Continue) response. 1706 6. Allow, rather than require, a server to omit 100 (Continue) if it 1707 has already seen some of the request body. 1709 7. Allow servers to defend against denial-of-service attacks and 1710 broken clients. 1712 This change adds the Expect header and 417 status code. 1714 Clean up confusion between 403 and 404 responses. (Section 9.4.4, 1715 9.4.5, and 9.4.11) 1717 The PATCH, LINK, UNLINK methods were defined but not commonly 1718 implemented in previous versions of this specification. See 1719 [RFC2068]. 1721 A.2. Changes from RFC 2616 1723 Clarify definition of POST. (Section 8.5) 1725 Failed to consider that there are many other request methods that are 1726 safe to automatically redirect, and further that the user agent is 1727 able to make that determination based on the request method 1728 semantics. (Sections 9.3.2, 9.3.3 and 9.3.8 ) 1730 Correct syntax of Location header to allow fragment, as referred 1731 symbol wasn't what was expected, and add some clarifications as to 1732 when it would not be appropriate. (Section 10.4) 1734 In the description of the Server header, the Via field was described 1735 as a SHOULD. The requirement was and is stated correctly in the 1736 description of the Via header in Section 8.9 of [Part1]. 1737 (Section 10.8) 1739 Appendix B. Change Log (to be removed by RFC Editor before publication) 1741 B.1. Since RFC2616 1743 Extracted relevant partitions from [RFC2616]. 1745 B.2. Since draft-ietf-httpbis-p2-semantics-00 1747 Closed issues: 1749 o : "Via is a 1750 MUST" () 1752 o : "Fragments 1753 allowed in Location" 1754 () 1756 o : "Safe 1757 Methods vs Redirection" 1758 () 1760 o : "Revise 1761 description of the POST method" 1762 () 1764 o : "Normative 1765 and Informative references" 1767 o : "RFC2606 1768 Compliance" 1770 o : 1771 "Informative references" 1773 o : "Redundant 1774 cross-references" 1776 Other changes: 1778 o Move definitions of 304 and 412 condition codes to [Part4] 1780 Index 1782 1 1783 100 Continue (status code) 17 1784 101 Switching Protocols (status code) 18 1786 2 1787 200 OK (status code) 18 1788 201 Created (status code) 18 1789 202 Accepted (status code) 19 1790 203 Non-Authoritative Information (status code) 19 1791 204 No Content (status code) 19 1792 205 Reset Content (status code) 20 1793 206 Partial Content (status code) 20 1795 3 1796 300 Multiple Choices (status code) 20 1797 301 Moved Permanently (status code) 21 1798 302 Found (status code) 21 1799 303 See Other (status code) 22 1800 304 Not Modified (status code) 22 1801 305 Use Proxy (status code) 22 1802 306 (Unused) (status code) 23 1803 307 Temporary Redirect (status code) 23 1805 4 1806 400 Bad Request (status code) 24 1807 401 Unauthorized (status code) 24 1808 402 Payment Required (status code) 24 1809 403 Forbidden (status code) 24 1810 404 Not Found (status code) 24 1811 405 Method Not Allowed (status code) 24 1812 406 Not Acceptable (status code) 24 1813 407 Proxy Authentication Required (status code) 25 1814 408 Request Timeout (status code) 25 1815 409 Conflict (status code) 25 1816 410 Gone (status code) 26 1817 411 Length Required (status code) 26 1818 412 Precondition Failed (status code) 26 1819 413 Request Entity Too Large (status code) 26 1820 414 Request-URI Too Long (status code) 27 1821 415 Unsupported Media Type (status code) 27 1822 416 Requested Range Not Satisfiable (status code) 27 1823 417 Expectation Failed (status code) 27 1825 5 1826 500 Internal Server Error (status code) 27 1827 501 Not Implemented (status code) 28 1828 502 Bad Gateway (status code) 28 1829 503 Service Unavailable (status code) 28 1830 504 Gateway Timeout (status code) 28 1831 505 HTTP Version Not Supported (status code) 28 1833 A 1834 Allow header 29 1836 C 1837 CONNECT method 17 1839 D 1840 DELETE method 16 1842 E 1843 Expect header 29 1845 F 1846 From header 30 1848 G 1849 GET method 13 1850 Grammar 1851 Allow 29 1852 Expect 29 1853 expect-params 29 1854 expectation 29 1855 expectation-extension 29 1856 extension-code 9 1857 extension-method 7 1858 From 30 1859 Location 31 1860 Max-Forwards 32 1861 Method 7 1862 product 6 1863 product-version 6 1864 Reason-Phrase 9 1865 Referer 32 1866 request-header 8 1867 response-header 10 1868 Retry-After 33 1869 Server 33 1870 Status-Code 9 1871 User-Agent 34 1873 H 1874 HEAD method 13 1875 Headers 1876 Allow 29 1877 Expect 29 1878 From 30 1879 Location 31 1880 Max-Forwards 32 1881 Referer 32 1882 Retry-After 33 1883 Server 33 1884 User-Agent 34 1886 L 1887 LINK method 38 1888 Location header 31 1890 M 1891 Max-Forwards header 32 1892 Methods 1893 CONNECT 17 1894 DELETE 16 1895 GET 13 1896 HEAD 13 1897 LINK 38 1898 OPTIONS 12 1899 PATCH 38 1900 POST 14 1901 PUT 15 1902 TRACE 16 1903 UNLINK 38 1905 O 1906 OPTIONS method 12 1908 P 1909 PATCH method 38 1910 POST method 14 1911 PUT method 15 1913 R 1914 Referer header 32 1915 Retry-After header 33 1917 S 1918 Server header 33 1919 Status Codes 1920 100 Continue 17 1921 101 Switching Protocols 18 1922 200 OK 18 1923 201 Created 18 1924 202 Accepted 19 1925 203 Non-Authoritative Information 19 1926 204 No Content 19 1927 205 Reset Content 20 1928 206 Partial Content 20 1929 300 Multiple Choices 20 1930 301 Moved Permanently 21 1931 302 Found 21 1932 303 See Other 22 1933 304 Not Modified 22 1934 305 Use Proxy 22 1935 306 (Unused) 23 1936 307 Temporary Redirect 23 1937 400 Bad Request 24 1938 401 Unauthorized 24 1939 402 Payment Required 24 1940 403 Forbidden 24 1941 404 Not Found 24 1942 405 Method Not Allowed 24 1943 406 Not Acceptable 24 1944 407 Proxy Authentication Required 25 1945 408 Request Timeout 25 1946 409 Conflict 25 1947 410 Gone 26 1948 411 Length Required 26 1949 412 Precondition Failed 26 1950 413 Request Entity Too Large 26 1951 414 Request-URI Too Long 27 1952 415 Unsupported Media Type 27 1953 416 Requested Range Not Satisfiable 27 1954 417 Expectation Failed 27 1955 500 Internal Server Error 27 1956 501 Not Implemented 28 1957 502 Bad Gateway 28 1958 503 Service Unavailable 28 1959 504 Gateway Timeout 28 1960 505 HTTP Version Not Supported 28 1962 T 1963 TRACE method 16 1965 U 1966 UNLINK method 38 1967 User-Agent header 34 1969 Authors' Addresses 1971 Roy T. Fielding (editor) 1972 Day Software 1973 23 Corporate Plaza DR, Suite 280 1974 Newport Beach, CA 92660 1975 USA 1977 Phone: +1-949-706-5300 1978 Fax: +1-949-706-5305 1979 Email: fielding@gbiv.com 1980 URI: http://roy.gbiv.com/ 1982 Jim Gettys 1983 One Laptop per Child 1984 21 Oak Knoll Road 1985 Carlisle, MA 01741 1986 USA 1988 Email: jg@laptop.org 1989 URI: http://www.laptop.org/ 1991 Jeffrey C. Mogul 1992 Hewlett-Packard Company 1993 HP Labs, Large Scale Systems Group 1994 1501 Page Mill Road, MS 1177 1995 Palo Alto, CA 94304 1996 USA 1998 Email: JeffMogul@acm.org 2000 Henrik Frystyk Nielsen 2001 Microsoft Corporation 2002 1 Microsoft Way 2003 Redmond, WA 98052 2004 USA 2006 Email: henrikn@microsoft.com 2007 Larry Masinter 2008 Adobe Systems, Incorporated 2009 345 Park Ave 2010 San Jose, CA 95110 2011 USA 2013 Email: LMM@acm.org 2014 URI: http://larry.masinter.net/ 2016 Paul J. Leach 2017 Microsoft Corporation 2018 1 Microsoft Way 2019 Redmond, WA 98052 2021 Email: paulle@microsoft.com 2023 Tim Berners-Lee 2024 World Wide Web Consortium 2025 MIT Computer Science and Artificial Intelligence Laboratory 2026 The Stata Center, Building 32 2027 32 Vassar Street 2028 Cambridge, MA 02139 2029 USA 2031 Email: timbl@w3.org 2032 URI: http://www.w3.org/People/Berners-Lee/ 2034 Yves Lafon (editor) 2035 World Wide Web Consortium 2036 W3C / ERCIM 2037 2004, rte des Lucioles 2038 Sophia-Antipolis, AM 06902 2039 France 2041 Email: ylafon@w3.org 2042 URI: http://www.raubacapeu.net/people/yves/ 2043 Julian F. Reschke (editor) 2044 greenbytes GmbH 2045 Hafenweg 16 2046 Muenster, NW 48155 2047 Germany 2049 Phone: +49 251 2807760 2050 Fax: +49 251 2807761 2051 Email: julian.reschke@greenbytes.de 2052 URI: http://greenbytes.de/tech/webdav/ 2054 Full Copyright Statement 2056 Copyright (C) The IETF Trust (2008). 2058 This document is subject to the rights, licenses and restrictions 2059 contained in BCP 78, and except as set forth therein, the authors 2060 retain all their rights. 2062 This document and the information contained herein are provided on an 2063 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2064 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2065 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2066 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2067 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2068 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2070 Intellectual Property 2072 The IETF takes no position regarding the validity or scope of any 2073 Intellectual Property Rights or other rights that might be claimed to 2074 pertain to the implementation or use of the technology described in 2075 this document or the extent to which any license under such rights 2076 might or might not be available; nor does it represent that it has 2077 made any independent effort to identify any such rights. Information 2078 on the procedures with respect to rights in RFC documents can be 2079 found in BCP 78 and BCP 79. 2081 Copies of IPR disclosures made to the IETF Secretariat and any 2082 assurances of licenses to be made available, or the result of an 2083 attempt made to obtain a general license or permission for the use of 2084 such proprietary rights by implementers or users of this 2085 specification can be obtained from the IETF on-line IPR repository at 2086 http://www.ietf.org/ipr. 2088 The IETF invites any interested party to bring to its attention any 2089 copyrights, patents or patent applications, or other proprietary 2090 rights that may cover technology that may be required to implement 2091 this standard. Please address the information to the IETF at 2092 ietf-ipr@ietf.org. 2094 Acknowledgment 2096 Funding for the RFC Editor function is provided by the IETF 2097 Administrative Support Activity (IASA).