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