idnits 2.17.1 draft-ietf-httpbis-p2-semantics-03.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 2269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2293. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2817, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC2817, updated by this document, for RFC5378 checks: 1998-11-18) -- The document seems to 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 (June 17, 2008) is 5791 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-03 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-03 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-03 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-03 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-03 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-03 -- 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) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 12 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 Updates: 2817 (if approved) One Laptop per Child 6 Intended status: Standards Track J. Mogul 7 Expires: December 19, 2008 HP 8 H. Frystyk 9 Microsoft 10 L. Masinter 11 Adobe Systems 12 P. Leach 13 Microsoft 14 T. Berners-Lee 15 W3C/MIT 16 Y. Lafon, Ed. 17 W3C 18 J. Reschke, Ed. 19 greenbytes 20 June 17, 2008 22 HTTP/1.1, part 2: Message Semantics 23 draft-ietf-httpbis-p2-semantics-03 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 December 19, 2008. 50 Abstract 52 The Hypertext Transfer Protocol (HTTP) is an application-level 53 protocol for distributed, collaborative, hypermedia information 54 systems. HTTP has been in use by the World Wide Web global 55 information initiative since 1990. This document is Part 2 of the 56 seven-part specification that defines the protocol referred to as 57 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines 58 the semantics of HTTP messages as expressed by request methods, 59 request-header fields, response status codes, and response-header 60 fields. 62 Editorial Note (To be removed by RFC Editor) 64 Discussion of this draft should take place on the HTTPBIS working 65 group mailing list (ietf-http-wg@w3.org). The current issues list is 66 at and related 67 documents (including fancy diffs) can be found at 68 . 70 The changes in this draft are summarized in Appendix B.4. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 76 2. Notational Conventions and Generic Grammar . . . . . . . . . . 6 77 3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 8 79 5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 9 80 5.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 11 81 6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 11 82 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 12 84 8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 12 85 8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 12 86 8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 13 87 8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18 96 9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 18 97 9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 19 98 9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 19 99 9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 19 100 9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 19 101 9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 20 102 9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 20 103 9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 20 104 9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 21 105 9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 21 106 9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 21 107 9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 21 108 9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 22 109 9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 22 110 9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 23 111 9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 23 112 9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 24 113 9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 24 114 9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 24 115 9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 24 116 9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 25 117 9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 25 118 9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 25 119 9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 25 120 9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 25 121 9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 26 122 9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 26 123 9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 26 124 9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 26 125 9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 27 126 9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 27 127 9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 27 128 9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 28 129 9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 28 130 9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 28 131 9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 28 132 9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 28 133 9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 28 134 9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 29 135 9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 29 136 9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 29 137 9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 29 138 9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 29 139 9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 29 140 9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 30 141 9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 30 142 10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 30 143 10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 30 144 10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 31 145 10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 146 10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 32 147 10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 33 148 10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 33 149 10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 34 150 10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 34 151 10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 35 152 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 153 11.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 35 154 11.2. Message Header Registration . . . . . . . . . . . . . . . 37 155 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37 156 12.1. Transfer of Sensitive Information . . . . . . . . . . . . 37 157 12.2. Encoding Sensitive Information in URIs . . . . . . . . . . 38 158 12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 39 159 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 160 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 161 14.1. Normative References . . . . . . . . . . . . . . . . . . . 39 162 14.2. Informative References . . . . . . . . . . . . . . . . . . 40 163 Appendix A. Compatibility with Previous Versions . . . . . . . . 40 164 A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 40 165 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 41 166 Appendix B. Change Log (to be removed by RFC Editor before 167 publication) . . . . . . . . . . . . . . . . . . . . 42 169 B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 42 170 B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 42 171 B.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 43 172 B.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 43 173 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 174 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 175 Intellectual Property and Copyright Statements . . . . . . . . . . 51 177 1. Introduction 179 This document defines HTTP/1.1 request and response semantics. Each 180 HTTP message, as defined in [Part1], is in the form of either a 181 request or a response. An HTTP server listens on a connection for 182 HTTP requests and responds to each request, in the order received on 183 that connection, with one or more HTTP response messages. This 184 document defines the commonly agreed upon semantics of the HTTP 185 uniform interface, the intentions defined by each request method, and 186 the various response messages that might be expected as a result of 187 applying that method for the requested resource. 189 This document is currently disorganized in order to minimize the 190 changes between drafts and enable reviewers to see the smaller errata 191 changes. The next draft will reorganize the sections to better 192 reflect the content. In particular, the sections will be ordered 193 according to the typical processing of an HTTP request message (after 194 message parsing): resource mapping, general header fields, methods, 195 request modifiers, response status, and resource metadata. The 196 current mess reflects how widely dispersed these topics and 197 associated requirements had become in [RFC2616]. 199 1.1. Requirements 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 203 document are to be interpreted as described in [RFC2119]. 205 An implementation is not compliant if it fails to satisfy one or more 206 of the MUST or REQUIRED level requirements for the protocols it 207 implements. An implementation that satisfies all the MUST or 208 REQUIRED level and all the SHOULD level requirements for its 209 protocols is said to be "unconditionally compliant"; one that 210 satisfies all the MUST level requirements but not all the SHOULD 211 level requirements for its protocols is said to be "conditionally 212 compliant." 214 2. Notational Conventions and Generic Grammar 216 This specification uses the ABNF syntax defined in Section 2.1 of 217 [Part1] and the core rules defined in Section 2.2 of [Part1]: 218 [[abnf.dep: ABNF syntax and basic rules will be adopted from RFC 219 5234, see .]] 221 DIGIT = 222 comment = 223 quoted-string = 224 token = 226 The ABNF rules below are defined in other parts: 228 absoluteURI = 229 fragment = 230 Host = 231 HTTP-date = 232 product = 233 relativeURI = 234 TE = 236 Accept = 237 Accept-Charset = 238 239 Accept-Encoding = 240 241 Accept-Language = 242 244 ETag = 245 If-Match = 246 If-Modified-Since = 247 248 If-None-Match = 249 If-Unmodified-Since = 250 252 Accept-Ranges = 253 If-Range = 254 Range = 256 Age = 257 Vary = 259 Authorization = 260 Proxy-Authenticate = 261 262 Proxy-Authorization = 263 264 WWW-Authenticate = 265 267 3. Method 269 The Method token indicates the method to be performed on the resource 270 identified by the Request-URI. The method is case-sensitive. 272 Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 8.2 273 | %x47.45.54 ; "GET", Section 8.3 274 | %x48.45.41.44 ; "HEAD", Section 8.4 275 | %x50.4F.53.54 ; "POST", Section 8.5 276 | %x50.55.54 ; "PUT", Section 8.6 277 | %x44.45.4C.45.54.45 ; "DELETE", Section 8.7 278 | %x54.52.41.43.45 ; "TRACE", Section 8.8 279 | %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 8.9 280 | extension-method 281 extension-method = token 283 The list of methods allowed by a resource can be specified in an 284 Allow header field (Section 10.1). The return code of the response 285 always notifies the client whether a method is currently allowed on a 286 resource, since the set of allowed methods can change dynamically. 287 An origin server SHOULD return the status code 405 (Method Not 288 Allowed) if the method is known by the origin server but not allowed 289 for the requested resource, and 501 (Not Implemented) if the method 290 is unrecognized or not implemented by the origin server. The methods 291 GET and HEAD MUST be supported by all general-purpose servers. All 292 other methods are OPTIONAL; however, if the above methods are 293 implemented, they MUST be implemented with the same semantics as 294 those specified in Section 8. 296 4. Request Header Fields 298 The request-header fields allow the client to pass additional 299 information about the request, and about the client itself, to the 300 server. These fields act as request modifiers, with semantics 301 equivalent to the parameters on a programming language method 302 invocation. 304 request-header = Accept ; [Part3], Section 6.1 305 | Accept-Charset ; [Part3], Section 6.2 306 | Accept-Encoding ; [Part3], Section 6.3 307 | Accept-Language ; [Part3], Section 6.4 308 | Authorization ; [Part7], Section 4.1 309 | Expect ; Section 10.2 310 | From ; Section 10.3 311 | Host ; [Part1], Section 8.4 312 | If-Match ; [Part4], Section 7.2 313 | If-Modified-Since ; [Part4], Section 7.3 314 | If-None-Match ; [Part4], Section 7.4 315 | If-Range ; [Part5], Section 6.3 316 | If-Unmodified-Since ; [Part4], Section 7.5 317 | Max-Forwards ; Section 10.5 318 | Proxy-Authorization ; [Part7], Section 4.3 319 | Range ; [Part5], Section 6.4 320 | Referer ; Section 10.6 321 | TE ; [Part1], Section 8.8 322 | User-Agent ; Section 10.9 324 Request-header field names can be extended reliably only in 325 combination with a change in the protocol version. However, new or 326 experimental header fields MAY be given the semantics of request- 327 header fields if all parties in the communication recognize them to 328 be request-header fields. Unrecognized header fields are treated as 329 entity-header fields. 331 5. Status Code and Reason Phrase 333 The Status-Code element is a 3-digit integer result code of the 334 attempt to understand and satisfy the request. The status codes 335 listed below are defined in Section 9. The Reason-Phrase is intended 336 to give a short textual description of the Status-Code. The Status- 337 Code is intended for use by automata and the Reason-Phrase is 338 intended for the human user. The client is not required to examine 339 or display the Reason-Phrase. 341 The individual values of the numeric status codes defined for 342 HTTP/1.1, and an example set of corresponding Reason-Phrase's, are 343 presented below. The reason phrases listed here are only 344 recommendations -- they MAY be replaced by local equivalents without 345 affecting the protocol. 347 Status-Code = 348 "100" ; Section 9.1.1: Continue 349 | "101" ; Section 9.1.2: Switching Protocols 350 | "200" ; Section 9.2.1: OK 351 | "201" ; Section 9.2.2: Created 352 | "202" ; Section 9.2.3: Accepted 353 | "203" ; Section 9.2.4: Non-Authoritative Information 354 | "204" ; Section 9.2.5: No Content 355 | "205" ; Section 9.2.6: Reset Content 356 | "206" ; Section 9.2.7: Partial Content 357 | "300" ; Section 9.3.1: Multiple Choices 358 | "301" ; Section 9.3.2: Moved Permanently 359 | "302" ; Section 9.3.3: Found 360 | "303" ; Section 9.3.4: See Other 361 | "304" ; Section 9.3.5: Not Modified 362 | "305" ; Section 9.3.6: Use Proxy 363 | "307" ; Section 9.3.8: Temporary Redirect 364 | "400" ; Section 9.4.1: Bad Request 365 | "401" ; Section 9.4.2: Unauthorized 366 | "402" ; Section 9.4.3: Payment Required 367 | "403" ; Section 9.4.4: Forbidden 368 | "404" ; Section 9.4.5: Not Found 369 | "405" ; Section 9.4.6: Method Not Allowed 370 | "406" ; Section 9.4.7: Not Acceptable 371 | "407" ; Section 9.4.8: Proxy Authentication Required 372 | "408" ; Section 9.4.9: Request Time-out 373 | "409" ; Section 9.4.10: Conflict 374 | "410" ; Section 9.4.11: Gone 375 | "411" ; Section 9.4.12: Length Required 376 | "412" ; Section 9.4.13: Precondition Failed 377 | "413" ; Section 9.4.14: Request Entity Too Large 378 | "414" ; Section 9.4.15: Request-URI Too Large 379 | "415" ; Section 9.4.16: Unsupported Media Type 380 | "416" ; Section 9.4.17: Requested range not satisfiable 381 | "417" ; Section 9.4.18: Expectation Failed 382 | "500" ; Section 9.5.1: Internal Server Error 383 | "501" ; Section 9.5.2: Not Implemented 384 | "502" ; Section 9.5.3: Bad Gateway 385 | "503" ; Section 9.5.4: Service Unavailable 386 | "504" ; Section 9.5.5: Gateway Time-out 387 | "505" ; Section 9.5.6: HTTP Version not supported 388 | extension-code 390 extension-code = 3DIGIT 391 Reason-Phrase = * 393 HTTP status codes are extensible. HTTP applications are not required 394 to understand the meaning of all registered status codes, though such 395 understanding is obviously desirable. However, applications MUST 396 understand the class of any status code, as indicated by the first 397 digit, and treat any unrecognized response as being equivalent to the 398 x00 status code of that class, with the exception that an 399 unrecognized response MUST NOT be cached. For example, if an 400 unrecognized status code of 431 is received by the client, it can 401 safely assume that there was something wrong with its request and 402 treat the response as if it had received a 400 status code. In such 403 cases, user agents SHOULD present to the user the entity returned 404 with the response, since that entity is likely to include human- 405 readable information which will explain the unusual status. 407 5.1. Status Code Registry 409 The HTTP Status Code Registry defines the name space for the Status- 410 Code token in the Status line of an HTTP response. 412 Values to be added to this name space are subject to IETF review 413 ([RFC5226], Section 4.1). Any document registering new status codes 414 should be traceable through statuses of either 'Obsoletes' or 415 'Updates' to this document. 417 The registry itself is maintained at 418 . 420 6. Response Header Fields 422 The response-header fields allow the server to pass additional 423 information about the response which cannot be placed in the Status- 424 Line. These header fields give information about the server and 425 about further access to the resource identified by the Request-URI. 427 response-header = Accept-Ranges ; [Part5], Section 6.1 428 | Age ; [Part6], Section 16.1 429 | Allow ; Section 10.1 430 | ETag ; [Part4], Section 7.1 431 | Location ; Section 10.4 432 | Proxy-Authenticate ; [Part7], Section 4.2 433 | Retry-After ; Section 10.7 434 | Server ; Section 10.8 435 | Vary ; [Part6], Section 16.5 436 | WWW-Authenticate ; [Part7], Section 4.4 438 Response-header field names can be extended reliably only in 439 combination with a change in the protocol version. However, new or 440 experimental header fields MAY be given the semantics of response- 441 header fields if all parties in the communication recognize them to 442 be response-header fields. Unrecognized header fields are treated as 443 entity-header fields. 445 7. Entity 447 Request and Response messages MAY transfer an entity if not otherwise 448 restricted by the request method or response status code. An entity 449 consists of entity-header fields and an entity-body, although some 450 responses will only include the entity-headers. HTTP entity-body and 451 entity-header fields are defined in [Part3]. 453 An entity-body is only present in a message when a message-body is 454 present, as described in Section 4.3 of [Part1]. The entity-body is 455 obtained from the message-body by decoding any Transfer-Encoding that 456 might have been applied to ensure safe and proper transfer of the 457 message. 459 8. Method Definitions 461 The set of common methods for HTTP/1.1 is defined below. Although 462 this set can be expanded, additional methods cannot be assumed to 463 share the same semantics for separately extended clients and servers. 465 8.1. Safe and Idempotent Methods 467 8.1.1. Safe Methods 469 Implementors should be aware that the software represents the user in 470 their interactions over the Internet, and should be careful to allow 471 the user to be aware of any actions they might take which may have an 472 unexpected significance to themselves or others. 474 In particular, the convention has been established that the GET and 475 HEAD methods SHOULD NOT have the significance of taking an action 476 other than retrieval. These methods ought to be considered "safe". 477 This allows user agents to represent other methods, such as POST, PUT 478 and DELETE, in a special way, so that the user is made aware of the 479 fact that a possibly unsafe action is being requested. 481 Naturally, it is not possible to ensure that the server does not 482 generate side-effects as a result of performing a GET request; in 483 fact, some dynamic resources consider that a feature. The important 484 distinction here is that the user did not request the side-effects, 485 so therefore cannot be held accountable for them. 487 8.1.2. Idempotent Methods 489 Methods can also have the property of "idempotence" in that (aside 490 from error or expiration issues) the side-effects of N > 0 identical 491 requests is the same as for a single request. The methods GET, HEAD, 492 PUT and DELETE share this property. Also, the methods OPTIONS and 493 TRACE SHOULD NOT have side effects, and so are inherently idempotent. 495 However, it is possible that a sequence of several requests is non- 496 idempotent, even if all of the methods executed in that sequence are 497 idempotent. (A sequence is idempotent if a single execution of the 498 entire sequence always yields a result that is not changed by a 499 reexecution of all, or part, of that sequence.) For example, a 500 sequence is non-idempotent if its result depends on a value that is 501 later modified in the same sequence. 503 A sequence that never has side effects is idempotent, by definition 504 (provided that no concurrent operations are being executed on the 505 same set of resources). 507 8.2. OPTIONS 509 The OPTIONS method represents a request for information about the 510 communication options available on the request/response chain 511 identified by the Request-URI. This method allows the client to 512 determine the options and/or requirements associated with a resource, 513 or the capabilities of a server, without implying a resource action 514 or initiating a resource retrieval. 516 Responses to this method are not cacheable. 518 If the OPTIONS request includes an entity-body (as indicated by the 519 presence of Content-Length or Transfer-Encoding), then the media type 520 MUST be indicated by a Content-Type field. Although this 521 specification does not define any use for such a body, future 522 extensions to HTTP might use the OPTIONS body to make more detailed 523 queries on the server. A server that does not support such an 524 extension MAY discard the request body. 526 If the Request-URI is an asterisk ("*"), the OPTIONS request is 527 intended to apply to the server in general rather than to a specific 528 resource. Since a server's communication options typically depend on 529 the resource, the "*" request is only useful as a "ping" or "no-op" 530 type of method; it does nothing beyond allowing the client to test 531 the capabilities of the server. For example, this can be used to 532 test a proxy for HTTP/1.1 compliance (or lack thereof). 534 If the Request-URI is not an asterisk, the OPTIONS request applies 535 only to the options that are available when communicating with that 536 resource. 538 A 200 response SHOULD include any header fields that indicate 539 optional features implemented by the server and applicable to that 540 resource (e.g., Allow), possibly including extensions not defined by 541 this specification. The response body, if any, SHOULD also include 542 information about the communication options. The format for such a 543 body is not defined by this specification, but might be defined by 544 future extensions to HTTP. Content negotiation MAY be used to select 545 the appropriate response format. If no response body is included, 546 the response MUST include a Content-Length field with a field-value 547 of "0". 549 The Max-Forwards request-header field MAY be used to target a 550 specific proxy in the request chain. When a proxy receives an 551 OPTIONS request on an absoluteURI for which request forwarding is 552 permitted, the proxy MUST check for a Max-Forwards field. If the 553 Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward 554 the message; instead, the proxy SHOULD respond with its own 555 communication options. If the Max-Forwards field-value is an integer 556 greater than zero, the proxy MUST decrement the field-value when it 557 forwards the request. If no Max-Forwards field is present in the 558 request, then the forwarded request MUST NOT include a Max-Forwards 559 field. 561 8.3. GET 563 The GET method means retrieve whatever information (in the form of an 564 entity) is identified by the Request-URI. If the Request-URI refers 565 to a data-producing process, it is the produced data which shall be 566 returned as the entity in the response and not the source text of the 567 process, unless that text happens to be the output of the process. 569 The semantics of the GET method change to a "conditional GET" if the 570 request message includes an If-Modified-Since, If-Unmodified-Since, 571 If-Match, If-None-Match, or If-Range header field. A conditional GET 572 method requests that the entity be transferred only under the 573 circumstances described by the conditional header field(s). The 574 conditional GET method is intended to reduce unnecessary network 575 usage by allowing cached entities to be refreshed without requiring 576 multiple requests or transferring data already held by the client. 578 The semantics of the GET method change to a "partial GET" if the 579 request message includes a Range header field. A partial GET 580 requests that only part of the entity be transferred, as described in 581 Section 6.4 of [Part5]. The partial GET method is intended to reduce 582 unnecessary network usage by allowing partially-retrieved entities to 583 be completed without transferring data already held by the client. 585 The response to a GET request is cacheable if and only if it meets 586 the requirements for HTTP caching described in [Part6]. 588 See Section 12.2 for security considerations when used for forms. 590 8.4. HEAD 592 The HEAD method is identical to GET except that the server MUST NOT 593 return a message-body in the response. The metainformation contained 594 in the HTTP headers in response to a HEAD request SHOULD be identical 595 to the information sent in response to a GET request. This method 596 can be used for obtaining metainformation about the entity implied by 597 the request without transferring the entity-body itself. This method 598 is often used for testing hypertext links for validity, 599 accessibility, and recent modification. 601 The response to a HEAD request MAY be cacheable in the sense that the 602 information contained in the response MAY be used to update a 603 previously cached entity from that resource. If the new field values 604 indicate that the cached entity differs from the current entity (as 605 would be indicated by a change in Content-Length, Content-MD5, ETag 606 or Last-Modified), then the cache MUST treat the cache entry as 607 stale. 609 8.5. POST 611 The POST method is used to request that the origin server accept the 612 entity enclosed in the request as data to be processed by the 613 resource identified by the Request-URI in the Request-Line. POST is 614 designed to allow a uniform method to cover the following functions: 616 o Annotation of existing resources; 618 o Posting a message to a bulletin board, newsgroup, mailing list, or 619 similar group of articles; 621 o Providing a block of data, such as the result of submitting a 622 form, to a data-handling process; 624 o Extending a database through an append operation. 626 The actual function performed by the POST method is determined by the 627 server and is usually dependent on the Request-URI. 629 The action performed by the POST method might not result in a 630 resource that can be identified by a URI. In this case, either 200 631 (OK) or 204 (No Content) is the appropriate response status, 632 depending on whether or not the response includes an entity that 633 describes the result. 635 If a resource has been created on the origin server, the response 636 SHOULD be 201 (Created) and contain an entity which describes the 637 status of the request and refers to the new resource, and a Location 638 header (see Section 10.4). 640 Responses to this method are not cacheable, unless the response 641 includes appropriate Cache-Control or Expires header fields. 642 However, the 303 (See Other) response can be used to direct the user 643 agent to retrieve a cacheable resource. 645 8.6. PUT 647 The PUT method requests that the enclosed entity be stored at the 648 supplied Request-URI. If the Request-URI refers to an already 649 existing resource, the enclosed entity SHOULD be considered as a 650 modified version of the one residing on the origin server. If the 651 Request-URI does not point to an existing resource, and that URI is 652 capable of being defined as a new resource by the requesting user 653 agent, the origin server can create the resource with that URI. If a 654 new resource is created at the Request-URI, the origin server MUST 655 inform the user agent via the 201 (Created) response. If an existing 656 resource is modified, either the 200 (OK) or 204 (No Content) 657 response codes SHOULD be sent to indicate successful completion of 658 the request. If the resource could not be created or modified with 659 the Request-URI, an appropriate error response SHOULD be given that 660 reflects the nature of the problem. The recipient of the entity MUST 661 NOT ignore any Content-* (e.g. Content-Range) headers that it does 662 not understand or implement and MUST return a 501 (Not Implemented) 663 response in such cases. 665 If the request passes through a cache and the Request-URI identifies 666 one or more currently cached entities, those entries SHOULD be 667 treated as stale. Responses to this method are not cacheable. 669 The fundamental difference between the POST and PUT requests is 670 reflected in the different meaning of the Request-URI. The URI in a 671 POST request identifies the resource that will handle the enclosed 672 entity. That resource might be a data-accepting process, a gateway 673 to some other protocol, or a separate entity that accepts 674 annotations. In contrast, the URI in a PUT request identifies the 675 entity enclosed with the request -- the user agent knows what URI is 676 intended and the server MUST NOT attempt to apply the request to some 677 other resource. If the server desires that the request be applied to 678 a different URI, it MUST send a 301 (Moved Permanently) response; the 679 user agent MAY then make its own decision regarding whether or not to 680 redirect the request. 682 A single resource MAY be identified by many different URIs. For 683 example, an article might have a URI for identifying "the current 684 version" which is separate from the URI identifying each particular 685 version. In this case, a PUT request on a general URI might result 686 in several other URIs being defined by the origin server. 688 HTTP/1.1 does not define how a PUT method affects the state of an 689 origin server. 691 Unless otherwise specified for a particular entity-header, the 692 entity-headers in the PUT request SHOULD be applied to the resource 693 created or modified by the PUT. 695 8.7. DELETE 697 The DELETE method requests that the origin server delete the resource 698 identified by the Request-URI. This method MAY be overridden by 699 human intervention (or other means) on the origin server. The client 700 cannot be guaranteed that the operation has been carried out, even if 701 the status code returned from the origin server indicates that the 702 action has been completed successfully. However, the server SHOULD 703 NOT indicate success unless, at the time the response is given, it 704 intends to delete the resource or move it to an inaccessible 705 location. 707 A successful response SHOULD be 200 (OK) if the response includes an 708 entity describing the status, 202 (Accepted) if the action has not 709 yet been enacted, or 204 (No Content) if the action has been enacted 710 but the response does not include an entity. 712 If the request passes through a cache and the Request-URI identifies 713 one or more currently cached entities, those entries SHOULD be 714 treated as stale. Responses to this method are not cacheable. 716 8.8. TRACE 718 The TRACE method is used to invoke a remote, application-layer loop- 719 back of the request message. The final recipient of the request 720 SHOULD reflect the message received back to the client as the entity- 721 body of a 200 (OK) response. The final recipient is either the 722 origin server or the first proxy or gateway to receive a Max-Forwards 723 value of zero (0) in the request (see Section 10.5). A TRACE request 724 MUST NOT include an entity. 726 TRACE allows the client to see what is being received at the other 727 end of the request chain and use that data for testing or diagnostic 728 information. The value of the Via header field (Section 8.9 of 729 [Part1]) is of particular interest, since it acts as a trace of the 730 request chain. Use of the Max-Forwards header field allows the 731 client to limit the length of the request chain, which is useful for 732 testing a chain of proxies forwarding messages in an infinite loop. 734 If the request is valid, the response SHOULD contain the entire 735 request message in the entity-body, with a Content-Type of "message/ 736 http" (see Appendix A.1 of [Part1]). Responses to this method MUST 737 NOT be cached. 739 8.9. CONNECT 741 This specification reserves the method name CONNECT for use with a 742 proxy that can dynamically switch to being a tunnel (e.g. SSL 743 tunneling [Luo1998]). 745 9. Status Code Definitions 747 Each Status-Code is described below, including a description of which 748 method(s) it can follow and any metainformation required in the 749 response. 751 9.1. Informational 1xx 753 This class of status code indicates a provisional response, 754 consisting only of the Status-Line and optional headers, and is 755 terminated by an empty line. There are no required headers for this 756 class of status code. Since HTTP/1.0 did not define any 1xx status 757 codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client 758 except under experimental conditions. 760 A client MUST be prepared to accept one or more 1xx status responses 761 prior to a regular response, even if the client does not expect a 100 762 (Continue) status message. Unexpected 1xx status responses MAY be 763 ignored by a user agent. 765 Proxies MUST forward 1xx responses, unless the connection between the 766 proxy and its client has been closed, or unless the proxy itself 767 requested the generation of the 1xx response. (For example, if a 768 proxy adds a "Expect: 100-continue" field when it forwards a request, 769 then it need not forward the corresponding 100 (Continue) 770 response(s).) 772 9.1.1. 100 Continue 774 The client SHOULD continue with its request. This interim response 775 is used to inform the client that the initial part of the request has 776 been received and has not yet been rejected by the server. The 777 client SHOULD continue by sending the remainder of the request or, if 778 the request has already been completed, ignore this response. The 779 server MUST send a final response after the request has been 780 completed. See Section 7.2.3 of [Part1] for detailed discussion of 781 the use and handling of this status code. 783 9.1.2. 101 Switching Protocols 785 The server understands and is willing to comply with the client's 786 request, via the Upgrade message header field (Section 6.4 of 787 [Part5]), for a change in the application protocol being used on this 788 connection. The server will switch protocols to those defined by the 789 response's Upgrade header field immediately after the empty line 790 which terminates the 101 response. 792 The protocol SHOULD be switched only when it is advantageous to do 793 so. For example, switching to a newer version of HTTP is 794 advantageous over older versions, and switching to a real-time, 795 synchronous protocol might be advantageous when delivering resources 796 that use such features. 798 9.2. Successful 2xx 800 This class of status code indicates that the client's request was 801 successfully received, understood, and accepted. 803 9.2.1. 200 OK 805 The request has succeeded. The information returned with the 806 response is dependent on the method used in the request, for example: 808 GET an entity corresponding to the requested resource is sent in the 809 response; 811 HEAD the entity-header fields corresponding to the requested 812 resource are sent in the response without any message-body; 814 POST an entity describing or containing the result of the action; 816 TRACE an entity containing the request message as received by the 817 end server. 819 9.2.2. 201 Created 821 The request has been fulfilled and resulted in a new resource being 822 created. The newly created resource can be referenced by the URI(s) 823 returned in the entity of the response, with the most specific URI 824 for the resource given by a Location header field. The response 825 SHOULD include an entity containing a list of resource 826 characteristics and location(s) from which the user or user agent can 827 choose the one most appropriate. The entity format is specified by 828 the media type given in the Content-Type header field. The origin 829 server MUST create the resource before returning the 201 status code. 830 If the action cannot be carried out immediately, the server SHOULD 831 respond with 202 (Accepted) response instead. 833 A 201 response MAY contain an ETag response header field indicating 834 the current value of the entity tag for the requested variant just 835 created, see Section 7.1 of [Part4]. 837 9.2.3. 202 Accepted 839 The request has been accepted for processing, but the processing has 840 not been completed. The request might or might not eventually be 841 acted upon, as it might be disallowed when processing actually takes 842 place. There is no facility for re-sending a status code from an 843 asynchronous operation such as this. 845 The 202 response is intentionally non-committal. Its purpose is to 846 allow a server to accept a request for some other process (perhaps a 847 batch-oriented process that is only run once per day) without 848 requiring that the user agent's connection to the server persist 849 until the process is completed. The entity returned with this 850 response SHOULD include an indication of the request's current status 851 and either a pointer to a status monitor or some estimate of when the 852 user can expect the request to be fulfilled. 854 9.2.4. 203 Non-Authoritative Information 856 The returned metainformation in the entity-header is not the 857 definitive set as available from the origin server, but is gathered 858 from a local or a third-party copy. The set presented MAY be a 859 subset or superset of the original version. For example, including 860 local annotation information about the resource might result in a 861 superset of the metainformation known by the origin server. Use of 862 this response code is not required and is only appropriate when the 863 response would otherwise be 200 (OK). 865 9.2.5. 204 No Content 867 The server has fulfilled the request but does not need to return an 868 entity-body, and might want to return updated metainformation. The 869 response MAY include new or updated metainformation in the form of 870 entity-headers, which if present SHOULD be associated with the 871 requested variant. 873 If the client is a user agent, it SHOULD NOT change its document view 874 from that which caused the request to be sent. This response is 875 primarily intended to allow input for actions to take place without 876 causing a change to the user agent's active document view, although 877 any new or updated metainformation SHOULD be applied to the document 878 currently in the user agent's active view. 880 The 204 response MUST NOT include a message-body, and thus is always 881 terminated by the first empty line after the header fields. 883 9.2.6. 205 Reset Content 885 The server has fulfilled the request and the user agent SHOULD reset 886 the document view which caused the request to be sent. This response 887 is primarily intended to allow input for actions to take place via 888 user input, followed by a clearing of the form in which the input is 889 given so that the user can easily initiate another input action. The 890 response MUST NOT include an entity. 892 9.2.7. 206 Partial Content 894 The server has fulfilled the partial GET request for the resource and 895 the enclosed entity is a partial representation as defined in 896 [Part5]. 898 9.3. Redirection 3xx 900 This class of status code indicates that further action needs to be 901 taken by the user agent in order to fulfill the request. The action 902 required MAY be carried out by the user agent without interaction 903 with the user if and only if the method used in the second request is 904 GET or HEAD. A client SHOULD detect infinite redirection loops, 905 since such loops generate network traffic for each redirection. 907 Note: previous versions of this specification recommended a 908 maximum of five redirections. Content developers should be aware 909 that there might be clients that implement such a fixed 910 limitation. 912 9.3.1. 300 Multiple Choices 914 The requested resource corresponds to any one of a set of 915 representations, each with its own specific location, and agent- 916 driven negotiation information (Section 5 of [Part3]) is being 917 provided so that the user (or user agent) can select a preferred 918 representation and redirect its request to that location. 920 Unless it was a HEAD request, the response SHOULD include an entity 921 containing a list of resource characteristics and location(s) from 922 which the user or user agent can choose the one most appropriate. 923 The entity format is specified by the media type given in the 924 Content-Type header field. Depending upon the format and the 925 capabilities of the user agent, selection of the most appropriate 926 choice MAY be performed automatically. However, this specification 927 does not define any standard for such automatic selection. 929 If the server has a preferred choice of representation, it SHOULD 930 include the specific URI for that representation in the Location 931 field; user agents MAY use the Location field value for automatic 932 redirection. This response is cacheable unless indicated otherwise. 934 9.3.2. 301 Moved Permanently 936 The requested resource has been assigned a new permanent URI and any 937 future references to this resource SHOULD use one of the returned 938 URIs. Clients with link editing capabilities ought to automatically 939 re-link references to the Request-URI to one or more of the new 940 references returned by the server, where possible. This response is 941 cacheable unless indicated otherwise. 943 The new permanent URI SHOULD be given by the Location field in the 944 response. Unless the request method was HEAD, the entity of the 945 response SHOULD contain a short hypertext note with a hyperlink to 946 the new URI(s). 948 If the 301 status code is received in response to a request method 949 that is known to be "safe", as defined in Section 8.1.1, then the 950 request MAY be automatically redirected by the user agent without 951 confirmation. Otherwise, the user agent MUST NOT automatically 952 redirect the request unless it can be confirmed by the user, since 953 this might change the conditions under which the request was issued. 955 Note: When automatically redirecting a POST request after 956 receiving a 301 status code, some existing HTTP/1.0 user agents 957 will erroneously change it into a GET request. 959 9.3.3. 302 Found 961 The requested resource resides temporarily under a different URI. 962 Since the redirection might be altered on occasion, the client SHOULD 963 continue to use the Request-URI for future requests. This response 964 is only cacheable if indicated by a Cache-Control or Expires header 965 field. 967 The temporary URI SHOULD be given by the Location field in the 968 response. Unless the request method was HEAD, the entity of the 969 response SHOULD contain a short hypertext note with a hyperlink to 970 the new URI(s). 972 If the 302 status code is received in response to a request method 973 that is known to be "safe", as defined in Section 8.1.1, then the 974 request MAY be automatically redirected by the user agent without 975 confirmation. Otherwise, the user agent MUST NOT automatically 976 redirect the request unless it can be confirmed by the user, since 977 this might change the conditions under which the request was issued. 979 Note: [RFC1945] and [RFC2068] specify that the client is not 980 allowed to change the method on the redirected request. However, 981 most existing user agent implementations treat 302 as if it were a 982 303 response, performing a GET on the Location field-value 983 regardless of the original request method. The status codes 303 984 and 307 have been added for servers that wish to make 985 unambiguously clear which kind of reaction is expected of the 986 client. 988 9.3.4. 303 See Other 990 The server directs the user agent to a different resource, indicated 991 by a URI in the Location header field, that provides an indirect 992 response to the original request. The user agent MAY perform a GET 993 request on the URI in the Location field in order to obtain a 994 representation corresponding to the response, be redirected again, or 995 end with an error status. The Location URI is not a substitute 996 reference for the originally requested resource. 998 The 303 status is generally applicable to any HTTP method. It is 999 primarily used to allow the output of a POST action to redirect the 1000 user agent to a selected resource, since doing so provides the 1001 information corresponding to the POST response in a form that can be 1002 separately identified, bookmarked, and cached independent of the 1003 original request. 1005 A 303 response to a GET request indicates that the requested resource 1006 does not have a representation of its own that can be transferred by 1007 the server over HTTP. The Location URI indicates a resource that is 1008 descriptive of the requested resource such that the follow-on 1009 representation may be useful without implying that it adequately 1010 represents the previously requested resource. Note that answers to 1011 the questions of what can be represented, what representations are 1012 adequate, and what might be a useful description are outside the 1013 scope of HTTP and thus entirely determined by the resource owner(s). 1015 A 303 response SHOULD NOT be cached unless it is indicated as 1016 cacheable by Cache-Control or Expires header fields. Except for 1017 responses to a HEAD request, the entity of a 303 response SHOULD 1018 contain a short hypertext note with a hyperlink to the Location URI. 1020 9.3.5. 304 Not Modified 1022 The response to the request has not been modified since the 1023 conditions indicated by the client's conditional GET request, as 1024 defined in [Part4]. 1026 9.3.6. 305 Use Proxy 1028 The 305 status was defined in a previous version of this 1029 specification (see Appendix A.2), and is now deprecated. 1031 9.3.7. 306 (Unused) 1033 The 306 status code was used in a previous version of the 1034 specification, is no longer used, and the code is reserved. 1036 9.3.8. 307 Temporary Redirect 1038 The requested resource resides temporarily under a different URI. 1039 Since the redirection MAY be altered on occasion, the client SHOULD 1040 continue to use the Request-URI for future requests. This response 1041 is only cacheable if indicated by a Cache-Control or Expires header 1042 field. 1044 The temporary URI SHOULD be given by the Location field in the 1045 response. Unless the request method was HEAD, the entity of the 1046 response SHOULD contain a short hypertext note with a hyperlink to 1047 the new URI(s) , since many pre-HTTP/1.1 user agents do not 1048 understand the 307 status. Therefore, the note SHOULD contain the 1049 information necessary for a user to repeat the original request on 1050 the new URI. 1052 If the 307 status code is received in response to a request method 1053 that is known to be "safe", as defined in Section 8.1.1, then the 1054 request MAY be automatically redirected by the user agent without 1055 confirmation. Otherwise, the user agent MUST NOT automatically 1056 redirect the request unless it can be confirmed by the user, since 1057 this might change the conditions under which the request was issued. 1059 9.4. Client Error 4xx 1061 The 4xx class of status code is intended for cases in which the 1062 client seems to have erred. Except when responding to a HEAD 1063 request, the server SHOULD include an entity containing an 1064 explanation of the error situation, and whether it is a temporary or 1065 permanent condition. These status codes are applicable to any 1066 request method. User agents SHOULD display any included entity to 1067 the user. 1069 If the client is sending data, a server implementation using TCP 1070 SHOULD be careful to ensure that the client acknowledges receipt of 1071 the packet(s) containing the response, before the server closes the 1072 input connection. If the client continues sending data to the server 1073 after the close, the server's TCP stack will send a reset packet to 1074 the client, which may erase the client's unacknowledged input buffers 1075 before they can be read and interpreted by the HTTP application. 1077 9.4.1. 400 Bad Request 1079 The request could not be understood by the server due to malformed 1080 syntax. The client SHOULD NOT repeat the request without 1081 modifications. 1083 9.4.2. 401 Unauthorized 1085 The request requires user authentication (see [Part7]). 1087 9.4.3. 402 Payment Required 1089 This code is reserved for future use. 1091 9.4.4. 403 Forbidden 1093 The server understood the request, but is refusing to fulfill it. 1094 Authorization will not help and the request SHOULD NOT be repeated. 1095 If the request method was not HEAD and the server wishes to make 1096 public why the request has not been fulfilled, it SHOULD describe the 1097 reason for the refusal in the entity. If the server does not wish to 1098 make this information available to the client, the status code 404 1099 (Not Found) can be used instead. 1101 9.4.5. 404 Not Found 1103 The server has not found anything matching the Request-URI. No 1104 indication is given of whether the condition is temporary or 1105 permanent. The 410 (Gone) status code SHOULD be used if the server 1106 knows, through some internally configurable mechanism, that an old 1107 resource is permanently unavailable and has no forwarding address. 1108 This status code is commonly used when the server does not wish to 1109 reveal exactly why the request has been refused, or when no other 1110 response is applicable. 1112 9.4.6. 405 Method Not Allowed 1114 The method specified in the Request-Line is not allowed for the 1115 resource identified by the Request-URI. The response MUST include an 1116 Allow header containing a list of valid methods for the requested 1117 resource. 1119 9.4.7. 406 Not Acceptable 1121 The resource identified by the request is only capable of generating 1122 response entities which have content characteristics not acceptable 1123 according to the accept headers sent in the request. 1125 Unless it was a HEAD request, the response SHOULD include an entity 1126 containing a list of available entity characteristics and location(s) 1127 from which the user or user agent can choose the one most 1128 appropriate. The entity format is specified by the media type given 1129 in the Content-Type header field. Depending upon the format and the 1130 capabilities of the user agent, selection of the most appropriate 1131 choice MAY be performed automatically. However, this specification 1132 does not define any standard for such automatic selection. 1134 Note: HTTP/1.1 servers are allowed to return responses which are 1135 not acceptable according to the accept headers sent in the 1136 request. In some cases, this may even be preferable to sending a 1137 406 response. User agents are encouraged to inspect the headers 1138 of an incoming response to determine if it is acceptable. 1140 If the response could be unacceptable, a user agent SHOULD 1141 temporarily stop receipt of more data and query the user for a 1142 decision on further actions. 1144 9.4.8. 407 Proxy Authentication Required 1146 This code is similar to 401 (Unauthorized), but indicates that the 1147 client must first authenticate itself with the proxy (see [Part7]). 1149 9.4.9. 408 Request Timeout 1151 The client did not produce a request within the time that the server 1152 was prepared to wait. The client MAY repeat the request without 1153 modifications at any later time. 1155 9.4.10. 409 Conflict 1157 The request could not be completed due to a conflict with the current 1158 state of the resource. This code is only allowed in situations where 1159 it is expected that the user might be able to resolve the conflict 1160 and resubmit the request. The response body SHOULD include enough 1161 information for the user to recognize the source of the conflict. 1162 Ideally, the response entity would include enough information for the 1163 user or user agent to fix the problem; however, that might not be 1164 possible and is not required. 1166 Conflicts are most likely to occur in response to a PUT request. For 1167 example, if versioning were being used and the entity being PUT 1168 included changes to a resource which conflict with those made by an 1169 earlier (third-party) request, the server might use the 409 response 1170 to indicate that it can't complete the request. In this case, the 1171 response entity would likely contain a list of the differences 1172 between the two versions in a format defined by the response Content- 1173 Type. 1175 9.4.11. 410 Gone 1177 The requested resource is no longer available at the server and no 1178 forwarding address is known. This condition is expected to be 1179 considered permanent. Clients with link editing capabilities SHOULD 1180 delete references to the Request-URI after user approval. If the 1181 server does not know, or has no facility to determine, whether or not 1182 the condition is permanent, the status code 404 (Not Found) SHOULD be 1183 used instead. This response is cacheable unless indicated otherwise. 1185 The 410 response is primarily intended to assist the task of web 1186 maintenance by notifying the recipient that the resource is 1187 intentionally unavailable and that the server owners desire that 1188 remote links to that resource be removed. Such an event is common 1189 for limited-time, promotional services and for resources belonging to 1190 individuals no longer working at the server's site. It is not 1191 necessary to mark all permanently unavailable resources as "gone" or 1192 to keep the mark for any length of time -- that is left to the 1193 discretion of the server owner. 1195 9.4.12. 411 Length Required 1197 The server refuses to accept the request without a defined Content- 1198 Length. The client MAY repeat the request if it adds a valid 1199 Content-Length header field containing the length of the message-body 1200 in the request message. 1202 9.4.13. 412 Precondition Failed 1204 The precondition given in one or more of the request-header fields 1205 evaluated to false when it was tested on the server, as defined in 1206 [Part4]. 1208 9.4.14. 413 Request Entity Too Large 1210 The server is refusing to process a request because the request 1211 entity is larger than the server is willing or able to process. The 1212 server MAY close the connection to prevent the client from continuing 1213 the request. 1215 If the condition is temporary, the server SHOULD include a Retry- 1216 After header field to indicate that it is temporary and after what 1217 time the client MAY try again. 1219 9.4.15. 414 Request-URI Too Long 1221 The server is refusing to service the request because the Request-URI 1222 is longer than the server is willing to interpret. This rare 1223 condition is only likely to occur when a client has improperly 1224 converted a POST request to a GET request with long query 1225 information, when the client has descended into a URI "black hole" of 1226 redirection (e.g., a redirected URI prefix that points to a suffix of 1227 itself), or when the server is under attack by a client attempting to 1228 exploit security holes present in some servers using fixed-length 1229 buffers for reading or manipulating the Request-URI. 1231 9.4.16. 415 Unsupported Media Type 1233 The server is refusing to service the request because the entity of 1234 the request is in a format not supported by the requested resource 1235 for the requested method. 1237 9.4.17. 416 Requested Range Not Satisfiable 1239 The request included a Range request-header field (Section 6.4 of 1240 [Part5]) and none of the range-specifier values in this field overlap 1241 the current extent of the selected resource. 1243 9.4.18. 417 Expectation Failed 1245 The expectation given in an Expect request-header field (see 1246 Section 10.2) could not be met by this server, or, if the server is a 1247 proxy, the server has unambiguous evidence that the request could not 1248 be met by the next-hop server. 1250 9.5. Server Error 5xx 1252 Response status codes beginning with the digit "5" indicate cases in 1253 which the server is aware that it has erred or is incapable of 1254 performing the request. Except when responding to a HEAD request, 1255 the server SHOULD include an entity containing an explanation of the 1256 error situation, and whether it is a temporary or permanent 1257 condition. User agents SHOULD display any included entity to the 1258 user. These response codes are applicable to any request method. 1260 9.5.1. 500 Internal Server Error 1262 The server encountered an unexpected condition which prevented it 1263 from fulfilling the request. 1265 9.5.2. 501 Not Implemented 1267 The server does not support the functionality required to fulfill the 1268 request. This is the appropriate response when the server does not 1269 recognize the request method and is not capable of supporting it for 1270 any resource. 1272 9.5.3. 502 Bad Gateway 1274 The server, while acting as a gateway or proxy, received an invalid 1275 response from the upstream server it accessed in attempting to 1276 fulfill the request. 1278 9.5.4. 503 Service Unavailable 1280 The server is currently unable to handle the request due to a 1281 temporary overloading or maintenance of the server. The implication 1282 is that this is a temporary condition which will be alleviated after 1283 some delay. If known, the length of the delay MAY be indicated in a 1284 Retry-After header. If no Retry-After is given, the client SHOULD 1285 handle the response as it would for a 500 response. 1287 Note: The existence of the 503 status code does not imply that a 1288 server must use it when becoming overloaded. Some servers may 1289 wish to simply refuse the connection. 1291 9.5.5. 504 Gateway Timeout 1293 The server, while acting as a gateway or proxy, did not receive a 1294 timely response from the upstream server specified by the URI (e.g. 1295 HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed 1296 to access in attempting to complete the request. 1298 Note: Note to implementors: some deployed proxies are known to 1299 return 400 or 500 when DNS lookups time out. 1301 9.5.6. 505 HTTP Version Not Supported 1303 The server does not support, or refuses to support, the protocol 1304 version that was used in the request message. The server is 1305 indicating that it is unable or unwilling to complete the request 1306 using the same major version as the client, as described in Section 1307 3.1 of [Part1], other than with this error message. The response 1308 SHOULD contain an entity describing why that version is not supported 1309 and what other protocols are supported by that server. 1311 10. Header Field Definitions 1313 This section defines the syntax and semantics of HTTP/1.1 header 1314 fields related to request and response semantics. 1316 For entity-header fields, both sender and recipient refer to either 1317 the client or the server, depending on who sends and who receives the 1318 entity. 1320 10.1. Allow 1322 The Allow response-header field lists the set of methods advertised 1323 as supported by the resource identified by the Request-URI. The 1324 purpose of this field is strictly to inform the recipient of valid 1325 methods associated with the resource. An Allow header field MUST be 1326 present in a 405 (Method Not Allowed) response. 1328 Allow = "Allow" ":" #Method 1330 Example of use: 1332 Allow: GET, HEAD, PUT 1334 The actual set of allowed methods is defined by the origin server at 1335 the time of each request. 1337 A proxy MUST NOT modify the Allow header field even if it does not 1338 understand all the methods specified, since the user agent might have 1339 other means of communicating with the origin server. 1341 10.2. Expect 1343 The Expect request-header field is used to indicate that particular 1344 server behaviors are required by the client. 1346 Expect = "Expect" ":" 1#expectation 1348 expectation = "100-continue" | expectation-extension 1349 expectation-extension = token [ "=" ( token | quoted-string ) 1350 *expect-params ] 1351 expect-params = ";" token [ "=" ( token | quoted-string ) ] 1353 A server that does not understand or is unable to comply with any of 1354 the expectation values in the Expect field of a request MUST respond 1355 with appropriate error status. The server MUST respond with a 417 1356 (Expectation Failed) status if any of the expectations cannot be met 1357 or, if there are other problems with the request, some other 4xx 1358 status. 1360 This header field is defined with extensible syntax to allow for 1361 future extensions. If a server receives a request containing an 1362 Expect field that includes an expectation-extension that it does not 1363 support, it MUST respond with a 417 (Expectation Failed) status. 1365 Comparison of expectation values is case-insensitive for unquoted 1366 tokens (including the 100-continue token), and is case-sensitive for 1367 quoted-string expectation-extensions. 1369 The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST 1370 return a 417 (Expectation Failed) status if it receives a request 1371 with an expectation that it cannot meet. However, the Expect 1372 request-header itself is end-to-end; it MUST be forwarded if the 1373 request is forwarded. 1375 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the 1376 Expect header. 1378 See Section 7.2.3 of [Part1] for the use of the 100 (Continue) 1379 status. 1381 10.3. From 1383 The From request-header field, if given, SHOULD contain an Internet 1384 e-mail address for the human user who controls the requesting user 1385 agent. The address SHOULD be machine-usable, as defined by "mailbox" 1386 in Section 3.4 of [RFC2822]: 1388 From = "From" ":" mailbox 1390 mailbox = 1392 An example is: 1394 From: webmaster@example.org 1396 This header field MAY be used for logging purposes and as a means for 1397 identifying the source of invalid or unwanted requests. It SHOULD 1398 NOT be used as an insecure form of access protection. The 1399 interpretation of this field is that the request is being performed 1400 on behalf of the person given, who accepts responsibility for the 1401 method performed. In particular, robot agents SHOULD include this 1402 header so that the person responsible for running the robot can be 1403 contacted if problems occur on the receiving end. 1405 The Internet e-mail address in this field MAY be separate from the 1406 Internet host which issued the request. For example, when a request 1407 is passed through a proxy the original issuer's address SHOULD be 1408 used. 1410 The client SHOULD NOT send the From header field without the user's 1411 approval, as it might conflict with the user's privacy interests or 1412 their site's security policy. It is strongly recommended that the 1413 user be able to disable, enable, and modify the value of this field 1414 at any time prior to a request. 1416 10.4. Location 1418 The Location response-header field is used for the identification of 1419 a new resource or to redirect the recipient to a location other than 1420 the Request-URI for completion of the request. For 201 (Created) 1421 responses, the Location is that of the new resource which was created 1422 by the request. For 3xx responses, the location SHOULD indicate the 1423 server's preferred URI for automatic redirection to the resource. 1424 The field value consists of a single absolute URI. 1426 Location = "Location" ":" absoluteURI [ "#" fragment ] 1428 An example is: 1430 Location: http://www.example.org/pub/WWW/People.html 1432 Note: The Content-Location header field (Section 6.7 of [Part3]) 1433 differs from Location in that the Content-Location identifies the 1434 original location of the entity enclosed in the request. It is 1435 therefore possible for a response to contain header fields for 1436 both Location and Content-Location. 1438 There are circumstances in which a fragment identifier in a Location 1439 URL would not be appropriate: 1441 o With a 201 Created response, because in this usage the Location 1442 header specifies the URL for the entire created resource. 1444 o With a 300 Multiple Choices, since the choice decision is intended 1445 to be made on resource characteristics and not fragment 1446 characteristics. 1448 o With 305 Use Proxy. 1450 10.5. Max-Forwards 1452 The Max-Forwards request-header field provides a mechanism with the 1453 TRACE (Section 8.8) and OPTIONS (Section 8.2) methods to limit the 1454 number of proxies or gateways that can forward the request to the 1455 next inbound server. This can be useful when the client is 1456 attempting to trace a request chain which appears to be failing or 1457 looping in mid-chain. 1459 Max-Forwards = "Max-Forwards" ":" 1*DIGIT 1461 The Max-Forwards value is a decimal integer indicating the remaining 1462 number of times this request message may be forwarded. 1464 Each proxy or gateway recipient of a TRACE or OPTIONS request 1465 containing a Max-Forwards header field MUST check and update its 1466 value prior to forwarding the request. If the received value is zero 1467 (0), the recipient MUST NOT forward the request; instead, it MUST 1468 respond as the final recipient. If the received Max-Forwards value 1469 is greater than zero, then the forwarded message MUST contain an 1470 updated Max-Forwards field with a value decremented by one (1). 1472 The Max-Forwards header field MAY be ignored for all other methods 1473 defined by this specification and for any extension methods for which 1474 it is not explicitly referred to as part of that method definition. 1476 10.6. Referer 1478 The Referer[sic] request-header field allows the client to specify, 1479 for the server's benefit, the address (URI) of the resource from 1480 which the Request-URI was obtained (the "referrer", although the 1481 header field is misspelled.) The Referer request-header allows a 1482 server to generate lists of back-links to resources for interest, 1483 logging, optimized caching, etc. It also allows obsolete or mistyped 1484 links to be traced for maintenance. The Referer field MUST NOT be 1485 sent if the Request-URI was obtained from a source that does not have 1486 its own URI, such as input from the user keyboard. 1488 Referer = "Referer" ":" ( absoluteURI | relativeURI ) 1490 Example: 1492 Referer: http://www.example.org/hypertext/Overview.html 1494 If the field value is a relative URI, it SHOULD be interpreted 1495 relative to the Request-URI. The URI MUST NOT include a fragment. 1496 See Section 12.2 for security considerations. 1498 10.7. Retry-After 1500 The Retry-After response-header field can be used with a 503 (Service 1501 Unavailable) response to indicate how long the service is expected to 1502 be unavailable to the requesting client. This field MAY also be used 1503 with any 3xx (Redirection) response to indicate the minimum time the 1504 user-agent is asked wait before issuing the redirected request. The 1505 value of this field can be either an HTTP-date or an integer number 1506 of seconds (in decimal) after the time of the response. 1508 Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) 1510 Time spans are non-negative decimal integers, representing time in 1511 seconds. 1513 delta-seconds = 1*DIGIT 1515 Two examples of its use are 1517 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 1518 Retry-After: 120 1520 In the latter example, the delay is 2 minutes. 1522 10.8. Server 1524 The Server response-header field contains information about the 1525 software used by the origin server to handle the request. The field 1526 can contain multiple product tokens (Section 3.5 of [Part1]) and 1527 comments identifying the server and any significant subproducts. The 1528 product tokens are listed in order of their significance for 1529 identifying the application. 1531 Server = "Server" ":" 1*( product | comment ) 1533 Example: 1535 Server: CERN/3.0 libwww/2.17 1537 If the response is being forwarded through a proxy, the proxy 1538 application MUST NOT modify the Server response-header. Instead, it 1539 MUST include a Via field (as described in Section 8.9 of [Part1]). 1541 Note: Revealing the specific software version of the server might 1542 allow the server machine to become more vulnerable to attacks 1543 against software that is known to contain security holes. Server 1544 implementors are encouraged to make this field a configurable 1545 option. 1547 10.9. User-Agent 1549 The User-Agent request-header field contains information about the 1550 user agent originating the request. This is for statistical 1551 purposes, the tracing of protocol violations, and automated 1552 recognition of user agents for the sake of tailoring responses to 1553 avoid particular user agent limitations. User agents SHOULD include 1554 this field with requests. The field can contain multiple product 1555 tokens (Section 3.5 of [Part1]) and comments identifying the agent 1556 and any subproducts which form a significant part of the user agent. 1557 By convention, the product tokens are listed in order of their 1558 significance for identifying the application. 1560 User-Agent = "User-Agent" ":" 1*( product | comment ) 1562 Example: 1564 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1566 11. IANA Considerations 1568 11.1. Status Code Registry 1570 The registration procedure for HTTP Status Codes -- previously 1571 defined in Section 7.1 of [RFC2817] -- is now defined by Section 5.1 1572 of this document. 1574 The HTTP Status Code Registry located at 1575 should be updated 1576 with the registrations below: 1578 +-------+---------------------------------+----------------+ 1579 | Value | Description | Reference | 1580 +-------+---------------------------------+----------------+ 1581 | 100 | Continue | Section 9.1.1 | 1582 | 101 | Switching Protocols | Section 9.1.2 | 1583 | 200 | OK | Section 9.2.1 | 1584 | 201 | Created | Section 9.2.2 | 1585 | 202 | Accepted | Section 9.2.3 | 1586 | 203 | Non-Authoritative Information | Section 9.2.4 | 1587 | 204 | No Content | Section 9.2.5 | 1588 | 205 | Reset Content | Section 9.2.6 | 1589 | 206 | Partial Content | Section 9.2.7 | 1590 | 300 | Multiple Choices | Section 9.3.1 | 1591 | 301 | Moved Permanently | Section 9.3.2 | 1592 | 302 | Found | Section 9.3.3 | 1593 | 303 | See Other | Section 9.3.4 | 1594 | 304 | Not Modified | Section 9.3.5 | 1595 | 305 | Use Proxy | Section 9.3.6 | 1596 | 306 | (Unused) | Section 9.3.7 | 1597 | 307 | Temporary Redirect | Section 9.3.8 | 1598 | 400 | Bad Request | Section 9.4.1 | 1599 | 401 | Unauthorized | Section 9.4.2 | 1600 | 402 | Payment Required | Section 9.4.3 | 1601 | 403 | Forbidden | Section 9.4.4 | 1602 | 404 | Not Found | Section 9.4.5 | 1603 | 405 | Method Not Allowed | Section 9.4.6 | 1604 | 406 | Not Acceptable | Section 9.4.7 | 1605 | 407 | Proxy Authentication Required | Section 9.4.8 | 1606 | 408 | Request Timeout | Section 9.4.9 | 1607 | 409 | Conflict | Section 9.4.10 | 1608 | 410 | Gone | Section 9.4.11 | 1609 | 411 | Length Required | Section 9.4.12 | 1610 | 412 | Precondition Failed | Section 9.4.13 | 1611 | 413 | Request Entity Too Large | Section 9.4.14 | 1612 | 414 | Request-URI Too Long | Section 9.4.15 | 1613 | 415 | Unsupported Media Type | Section 9.4.16 | 1614 | 416 | Requested Range Not Satisfiable | Section 9.4.17 | 1615 | 417 | Expectation Failed | Section 9.4.18 | 1616 | 500 | Internal Server Error | Section 9.5.1 | 1617 | 501 | Not Implemented | Section 9.5.2 | 1618 | 502 | Bad Gateway | Section 9.5.3 | 1619 | 503 | Service Unavailable | Section 9.5.4 | 1620 | 504 | Gateway Timeout | Section 9.5.5 | 1621 | 505 | HTTP Version Not Supported | Section 9.5.6 | 1622 +-------+---------------------------------+----------------+ 1624 11.2. Message Header Registration 1626 The Message Header Registry located at should be 1628 updated with the permanent registrations below (see [RFC3864]): 1630 +-------------------+----------+----------+--------------+ 1631 | Header Field Name | Protocol | Status | Reference | 1632 +-------------------+----------+----------+--------------+ 1633 | Allow | http | standard | Section 10.1 | 1634 | Expect | http | standard | Section 10.2 | 1635 | From | http | standard | Section 10.3 | 1636 | Location | http | standard | Section 10.4 | 1637 | Max-Forwards | http | standard | Section 10.5 | 1638 | Referer | http | standard | Section 10.6 | 1639 | Retry-After | http | standard | Section 10.7 | 1640 | Server | http | standard | Section 10.8 | 1641 | User-Agent | http | standard | Section 10.9 | 1642 +-------------------+----------+----------+--------------+ 1644 The change controller is: "IETF (iesg@ietf.org) - Internet 1645 Engineering Task Force". 1647 12. Security Considerations 1649 This section is meant to inform application developers, information 1650 providers, and users of the security limitations in HTTP/1.1 as 1651 described by this document. The discussion does not include 1652 definitive solutions to the problems revealed, though it does make 1653 some suggestions for reducing security risks. 1655 12.1. Transfer of Sensitive Information 1657 Like any generic data transfer protocol, HTTP cannot regulate the 1658 content of the data that is transferred, nor is there any a priori 1659 method of determining the sensitivity of any particular piece of 1660 information within the context of any given request. Therefore, 1661 applications SHOULD supply as much control over this information as 1662 possible to the provider of that information. Four header fields are 1663 worth special mention in this context: Server, Via, Referer and From. 1665 Revealing the specific software version of the server might allow the 1666 server machine to become more vulnerable to attacks against software 1667 that is known to contain security holes. Implementors SHOULD make 1668 the Server header field a configurable option. 1670 Proxies which serve as a portal through a network firewall SHOULD 1671 take special precautions regarding the transfer of header information 1672 that identifies the hosts behind the firewall. In particular, they 1673 SHOULD remove, or replace with sanitized versions, any Via fields 1674 generated behind the firewall. 1676 The Referer header allows reading patterns to be studied and reverse 1677 links drawn. Although it can be very useful, its power can be abused 1678 if user details are not separated from the information contained in 1679 the Referer. Even when the personal information has been removed, 1680 the Referer header might indicate a private document's URI whose 1681 publication would be inappropriate. 1683 The information sent in the From field might conflict with the user's 1684 privacy interests or their site's security policy, and hence it 1685 SHOULD NOT be transmitted without the user being able to disable, 1686 enable, and modify the contents of the field. The user MUST be able 1687 to set the contents of this field within a user preference or 1688 application defaults configuration. 1690 We suggest, though do not require, that a convenient toggle interface 1691 be provided for the user to enable or disable the sending of From and 1692 Referer information. 1694 The User-Agent (Section 10.9) or Server (Section 10.8) header fields 1695 can sometimes be used to determine that a specific client or server 1696 have a particular security hole which might be exploited. 1697 Unfortunately, this same information is often used for other valuable 1698 purposes for which HTTP currently has no better mechanism. 1700 12.2. Encoding Sensitive Information in URIs 1702 Because the source of a link might be private information or might 1703 reveal an otherwise private information source, it is strongly 1704 recommended that the user be able to select whether or not the 1705 Referer field is sent. For example, a browser client could have a 1706 toggle switch for browsing openly/anonymously, which would 1707 respectively enable/disable the sending of Referer and From 1708 information. 1710 Clients SHOULD NOT include a Referer header field in a (non-secure) 1711 HTTP request if the referring page was transferred with a secure 1712 protocol. 1714 Authors of services should not use GET-based forms for the submission 1715 of sensitive data because that data will be encoded in the Request- 1716 URI. Many existing servers, proxies, and user agents log or display 1717 the Request-URI in places where it might be visible to third parties. 1718 Such services can use POST-based form submission instead. 1720 12.3. Location Headers and Spoofing 1722 If a single server supports multiple organizations that do not trust 1723 one another, then it MUST check the values of Location and Content- 1724 Location headers in responses that are generated under control of 1725 said organizations to make sure that they do not attempt to 1726 invalidate resources over which they have no authority. 1728 13. Acknowledgments 1730 14. References 1732 14.1. Normative References 1734 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1735 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1736 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 1737 and Message Parsing", draft-ietf-httpbis-p1-messaging-03 1738 (work in progress), June 2008. 1740 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1741 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1742 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 1743 and Content Negotiation", draft-ietf-httpbis-p3-payload-03 1744 (work in progress), June 2008. 1746 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1747 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1748 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 1749 Requests", draft-ietf-httpbis-p4-conditional-03 (work in 1750 progress), June 2008. 1752 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1753 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1754 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 1755 Partial Responses", draft-ietf-httpbis-p5-range-03 (work 1756 in progress), June 2008. 1758 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1759 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1760 and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", 1761 draft-ietf-httpbis-p6-cache-03 (work in progress), 1762 June 2008. 1764 [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1765 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1766 and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", 1767 draft-ietf-httpbis-p7-auth-03 (work in progress), 1768 June 2008. 1770 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1771 Requirement Levels", BCP 14, RFC 2119, March 1997. 1773 14.2. Informative References 1775 [Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web 1776 proxy servers", draft-luotonen-web-proxy-tunneling-01 1777 (work in progress), August 1998. 1779 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1780 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1782 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 1783 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 1784 RFC 2068, January 1997. 1786 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1787 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1788 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1790 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 1791 HTTP/1.1", RFC 2817, May 2000. 1793 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1794 April 2001. 1796 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1797 Procedures for Message Header Fields", BCP 90, RFC 3864, 1798 September 2004. 1800 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1801 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1802 May 2008. 1804 Appendix A. Compatibility with Previous Versions 1806 A.1. Changes from RFC 2068 1808 Clarified which error code should be used for inbound server failures 1809 (e.g. DNS failures). (Section 9.5.5). 1811 201 (Created) had a race that required an Etag be sent when a 1812 resource is first created. (Section 9.2.2). 1814 Rewrite of message transmission requirements to make it much harder 1815 for implementors to get it wrong, as the consequences of errors here 1816 can have significant impact on the Internet, and to deal with the 1817 following problems: 1819 1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where 1820 this was incorrectly placing a requirement on the behavior of an 1821 implementation of a future version of HTTP/1.x 1823 2. Made it clear that user-agents should retry requests, not 1824 "clients" in general. 1826 3. Converted requirements for clients to ignore unexpected 100 1827 (Continue) responses, and for proxies to forward 100 responses, 1828 into a general requirement for 1xx responses. 1830 4. Modified some TCP-specific language, to make it clearer that non- 1831 TCP transports are possible for HTTP. 1833 5. Require that the origin server MUST NOT wait for the request body 1834 before it sends a required 100 (Continue) response. 1836 6. Allow, rather than require, a server to omit 100 (Continue) if it 1837 has already seen some of the request body. 1839 7. Allow servers to defend against denial-of-service attacks and 1840 broken clients. 1842 This change adds the Expect header and 417 status code. 1844 Clean up confusion between 403 and 404 responses. (Section 9.4.4, 1845 9.4.5, and 9.4.11) 1847 The PATCH, LINK, UNLINK methods were defined but not commonly 1848 implemented in previous versions of this specification. See Section 1849 19.6.1 of [RFC2068]. 1851 A.2. Changes from RFC 2616 1853 This document takes over the Status Code Registry, previously defined 1854 in Section 7.1 of [RFC2817]. (Section 5.1) 1856 Clarify definition of POST. (Section 8.5) 1858 Failed to consider that there are many other request methods that are 1859 safe to automatically redirect, and further that the user agent is 1860 able to make that determination based on the request method 1861 semantics. (Sections 9.3.2, 9.3.3 and 9.3.8) 1862 Deprecate 305 Use Proxy status code, because user agents did not 1863 implement it. It used to indicate that the requested resource must 1864 be accessed through the proxy given by the Location field. The 1865 Location field gave the URI of the proxy. The recipient was expected 1866 to repeat this single request via the proxy. (Section 9.3.6) 1868 Reclassify Allow header as response header, removing the option to 1869 specify it in a PUT request. Relax the server requirement on the 1870 contents of the Allow header and remove requirement on clients to 1871 always trust the header value. (Section 10.1) 1873 Correct syntax of Location header to allow fragment, as referred 1874 symbol wasn't what was expected, and add some clarifications as to 1875 when it would not be appropriate. (Section 10.4) 1877 In the description of the Server header, the Via field was described 1878 as a SHOULD. The requirement was and is stated correctly in the 1879 description of the Via header in Section 8.9 of [Part1]. 1880 (Section 10.8) 1882 Appendix B. Change Log (to be removed by RFC Editor before publication) 1884 B.1. Since RFC2616 1886 Extracted relevant partitions from [RFC2616]. 1888 B.2. Since draft-ietf-httpbis-p2-semantics-00 1890 Closed issues: 1892 o : "Via is a 1893 MUST" () 1895 o : "Fragments 1896 allowed in Location" 1897 () 1899 o : "Safe 1900 Methods vs Redirection" 1901 () 1903 o : "Revise 1904 description of the POST method" 1905 () 1907 o : "Normative 1908 and Informative references" 1910 o : "RFC2606 1911 Compliance" 1913 o : 1914 "Informative references" 1916 o : "Redundant 1917 cross-references" 1919 Other changes: 1921 o Move definitions of 304 and 412 condition codes to [Part4] 1923 B.3. Since draft-ietf-httpbis-p2-semantics-01 1925 Closed issues: 1927 o : "PUT side 1928 effects" 1930 o : "Duplicate 1931 Host header requirements" 1933 Ongoing work on ABNF conversion 1934 (): 1936 o Move "Product Tokens" section (back) into Part 1, as "token" is 1937 used in the definition of the Upgrade header. 1939 o Add explicit references to BNF syntax and rules imported from 1940 other parts of the specification. 1942 o Copy definition of delta-seconds from Part6 instead of referencing 1943 it. 1945 B.4. Since draft-ietf-httpbis-p2-semantics-02 1947 Closed issues: 1949 o : "Requiring 1950 Allow in 405 responses" 1952 o : "Status 1953 Code Registry" 1955 o : 1956 "Redirection vs. Location" 1958 o : 1959 "Cacheability of 303 response" 1961 o : "305 Use 1962 Proxy" 1964 o : 1965 "Classification for Allow header" 1967 o : "PUT - 1968 'store under' vs 'store at'" 1970 Ongoing work on IANA Message Header Registration 1971 (): 1973 o Reference RFC 3984, and update header registrations for headers 1974 defined in this document. 1976 Ongoing work on ABNF conversion 1977 (): 1979 o Replace string literals when the string really is case-sensitive 1980 (method). 1982 Index 1984 1 1985 100 Continue (status code) 19 1986 101 Switching Protocols (status code) 19 1988 2 1989 200 OK (status code) 19 1990 201 Created (status code) 20 1991 202 Accepted (status code) 20 1992 203 Non-Authoritative Information (status code) 20 1993 204 No Content (status code) 21 1994 205 Reset Content (status code) 21 1995 206 Partial Content (status code) 21 1997 3 1998 300 Multiple Choices (status code) 22 1999 301 Moved Permanently (status code) 22 2000 302 Found (status code) 23 2001 303 See Other (status code) 23 2002 304 Not Modified (status code) 24 2003 305 Use Proxy (status code) 24 2004 306 (Unused) (status code) 24 2005 307 Temporary Redirect (status code) 24 2007 4 2008 400 Bad Request (status code) 25 2009 401 Unauthorized (status code) 25 2010 402 Payment Required (status code) 25 2011 403 Forbidden (status code) 25 2012 404 Not Found (status code) 26 2013 405 Method Not Allowed (status code) 26 2014 406 Not Acceptable (status code) 26 2015 407 Proxy Authentication Required (status code) 26 2016 408 Request Timeout (status code) 27 2017 409 Conflict (status code) 27 2018 410 Gone (status code) 27 2019 411 Length Required (status code) 28 2020 412 Precondition Failed (status code) 28 2021 413 Request Entity Too Large (status code) 28 2022 414 Request-URI Too Long (status code) 28 2023 415 Unsupported Media Type (status code) 28 2024 416 Requested Range Not Satisfiable (status code) 28 2025 417 Expectation Failed (status code) 29 2027 5 2028 500 Internal Server Error (status code) 29 2029 501 Not Implemented (status code) 29 2030 502 Bad Gateway (status code) 29 2031 503 Service Unavailable (status code) 29 2032 504 Gateway Timeout (status code) 30 2033 505 HTTP Version Not Supported (status code) 30 2035 A 2036 Allow header 30 2038 C 2039 CONNECT method 18 2041 D 2042 DELETE method 17 2044 E 2045 Expect header 31 2047 F 2048 From header 31 2050 G 2051 GET method 14 2052 Grammar 2053 Allow 30 2054 delta-seconds 34 2055 Expect 31 2056 expect-params 31 2057 expectation 31 2058 expectation-extension 31 2059 extension-code 10 2060 extension-method 8 2061 From 32 2062 Location 32 2063 Max-Forwards 33 2064 Method 8 2065 Reason-Phrase 10 2066 Referer 34 2067 request-header 9 2068 response-header 11 2069 Retry-After 34 2070 Server 35 2071 Status-Code 10 2072 User-Agent 35 2074 H 2075 HEAD method 15 2076 Headers 2077 Allow 30 2078 Expect 31 2079 From 31 2080 Location 32 2081 Max-Forwards 33 2082 Referer 33 2083 Retry-After 34 2084 Server 34 2085 User-Agent 35 2087 L 2088 LINK method 41 2089 Location header 32 2091 M 2092 Max-Forwards header 33 2093 Methods 2094 CONNECT 18 2095 DELETE 17 2096 GET 14 2097 HEAD 15 2098 LINK 41 2099 OPTIONS 13 2100 PATCH 41 2101 POST 15 2102 PUT 16 2103 TRACE 17 2104 UNLINK 41 2106 O 2107 OPTIONS method 13 2109 P 2110 PATCH method 41 2111 POST method 15 2112 PUT method 16 2114 R 2115 Referer header 33 2116 Retry-After header 34 2118 S 2119 Server header 34 2120 Status Codes 2121 100 Continue 19 2122 101 Switching Protocols 19 2123 200 OK 19 2124 201 Created 20 2125 202 Accepted 20 2126 203 Non-Authoritative Information 20 2127 204 No Content 21 2128 205 Reset Content 21 2129 206 Partial Content 21 2130 300 Multiple Choices 22 2131 301 Moved Permanently 22 2132 302 Found 23 2133 303 See Other 23 2134 304 Not Modified 24 2135 305 Use Proxy 24 2136 306 (Unused) 24 2137 307 Temporary Redirect 24 2138 400 Bad Request 25 2139 401 Unauthorized 25 2140 402 Payment Required 25 2141 403 Forbidden 25 2142 404 Not Found 26 2143 405 Method Not Allowed 26 2144 406 Not Acceptable 26 2145 407 Proxy Authentication Required 26 2146 408 Request Timeout 27 2147 409 Conflict 27 2148 410 Gone 27 2149 411 Length Required 28 2150 412 Precondition Failed 28 2151 413 Request Entity Too Large 28 2152 414 Request-URI Too Long 28 2153 415 Unsupported Media Type 28 2154 416 Requested Range Not Satisfiable 28 2155 417 Expectation Failed 29 2156 500 Internal Server Error 29 2157 501 Not Implemented 29 2158 502 Bad Gateway 29 2159 503 Service Unavailable 29 2160 504 Gateway Timeout 30 2161 505 HTTP Version Not Supported 30 2163 T 2164 TRACE method 17 2166 U 2167 UNLINK method 41 2168 User-Agent header 35 2170 Authors' Addresses 2172 Roy T. Fielding (editor) 2173 Day Software 2174 23 Corporate Plaza DR, Suite 280 2175 Newport Beach, CA 92660 2176 USA 2178 Phone: +1-949-706-5300 2179 Fax: +1-949-706-5305 2180 Email: fielding@gbiv.com 2181 URI: http://roy.gbiv.com/ 2183 Jim Gettys 2184 One Laptop per Child 2185 21 Oak Knoll Road 2186 Carlisle, MA 01741 2187 USA 2189 Email: jg@laptop.org 2190 URI: http://www.laptop.org/ 2191 Jeffrey C. Mogul 2192 Hewlett-Packard Company 2193 HP Labs, Large Scale Systems Group 2194 1501 Page Mill Road, MS 1177 2195 Palo Alto, CA 94304 2196 USA 2198 Email: JeffMogul@acm.org 2200 Henrik Frystyk Nielsen 2201 Microsoft Corporation 2202 1 Microsoft Way 2203 Redmond, WA 98052 2204 USA 2206 Email: henrikn@microsoft.com 2208 Larry Masinter 2209 Adobe Systems, Incorporated 2210 345 Park Ave 2211 San Jose, CA 95110 2212 USA 2214 Email: LMM@acm.org 2215 URI: http://larry.masinter.net/ 2217 Paul J. Leach 2218 Microsoft Corporation 2219 1 Microsoft Way 2220 Redmond, WA 98052 2222 Email: paulle@microsoft.com 2224 Tim Berners-Lee 2225 World Wide Web Consortium 2226 MIT Computer Science and Artificial Intelligence Laboratory 2227 The Stata Center, Building 32 2228 32 Vassar Street 2229 Cambridge, MA 02139 2230 USA 2232 Email: timbl@w3.org 2233 URI: http://www.w3.org/People/Berners-Lee/ 2234 Yves Lafon (editor) 2235 World Wide Web Consortium 2236 W3C / ERCIM 2237 2004, rte des Lucioles 2238 Sophia-Antipolis, AM 06902 2239 France 2241 Email: ylafon@w3.org 2242 URI: http://www.raubacapeu.net/people/yves/ 2244 Julian F. Reschke (editor) 2245 greenbytes GmbH 2246 Hafenweg 16 2247 Muenster, NW 48155 2248 Germany 2250 Phone: +49 251 2807760 2251 Fax: +49 251 2807761 2252 Email: julian.reschke@greenbytes.de 2253 URI: http://greenbytes.de/tech/webdav/ 2255 Full Copyright Statement 2257 Copyright (C) The IETF Trust (2008). 2259 This document is subject to the rights, licenses and restrictions 2260 contained in BCP 78, and except as set forth therein, the authors 2261 retain all their rights. 2263 This document and the information contained herein are provided on an 2264 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2265 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2266 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2267 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2268 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2269 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2271 Intellectual Property 2273 The IETF takes no position regarding the validity or scope of any 2274 Intellectual Property Rights or other rights that might be claimed to 2275 pertain to the implementation or use of the technology described in 2276 this document or the extent to which any license under such rights 2277 might or might not be available; nor does it represent that it has 2278 made any independent effort to identify any such rights. Information 2279 on the procedures with respect to rights in RFC documents can be 2280 found in BCP 78 and BCP 79. 2282 Copies of IPR disclosures made to the IETF Secretariat and any 2283 assurances of licenses to be made available, or the result of an 2284 attempt made to obtain a general license or permission for the use of 2285 such proprietary rights by implementers or users of this 2286 specification can be obtained from the IETF on-line IPR repository at 2287 http://www.ietf.org/ipr. 2289 The IETF invites any interested party to bring to its attention any 2290 copyrights, patents or patent applications, or other proprietary 2291 rights that may cover technology that may be required to implement 2292 this standard. Please address the information to the IETF at 2293 ietf-ipr@ietf.org.