idnits 2.17.1 draft-ietf-httpbis-p2-semantics-05.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 2373. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2397. 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 (November 16, 2008) is 5630 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-05 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-05 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-05 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-05 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-05 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-05 -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 11 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: May 20, 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 November 16, 2008 22 HTTP/1.1, part 2: Message Semantics 23 draft-ietf-httpbis-p2-semantics-05 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 May 20, 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.6. 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 . . . . . . . . . . . . . . . . 10 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 B.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 46 177 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 178 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 179 Intellectual Property and Copyright Statements . . . . . . . . . . 54 181 1. Introduction 183 This document defines HTTP/1.1 request and response semantics. Each 184 HTTP message, as defined in [Part1], is in the form of either a 185 request or a response. An HTTP server listens on a connection for 186 HTTP requests and responds to each request, in the order received on 187 that connection, with one or more HTTP response messages. This 188 document defines the commonly agreed upon semantics of the HTTP 189 uniform interface, the intentions defined by each request method, and 190 the various response messages that might be expected as a result of 191 applying that method for the requested resource. 193 This document is currently disorganized in order to minimize the 194 changes between drafts and enable reviewers to see the smaller errata 195 changes. The next draft will reorganize the sections to better 196 reflect the content. In particular, the sections will be ordered 197 according to the typical processing of an HTTP request message (after 198 message parsing): resource mapping, general header fields, methods, 199 request modifiers, response status, and resource metadata. The 200 current mess reflects how widely dispersed these topics and 201 associated requirements had become in [RFC2616]. 203 1.1. Requirements 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in [RFC2119]. 209 An implementation is not compliant if it fails to satisfy one or more 210 of the MUST or REQUIRED level requirements for the protocols it 211 implements. An implementation that satisfies all the MUST or 212 REQUIRED level and all the SHOULD level requirements for its 213 protocols is said to be "unconditionally compliant"; one that 214 satisfies all the MUST level requirements but not all the SHOULD 215 level requirements for its protocols is said to be "conditionally 216 compliant." 218 2. Notational Conventions and Generic Grammar 220 This specification uses the ABNF syntax defined in Section 2.1 of 221 [Part1] and the core rules defined in Section 2.2 of [Part1]: 223 DIGIT = 224 comment = 225 quoted-string = 226 token = 227 OWS = 228 RWS = 230 The ABNF rules below are defined in other parts: 232 absolute-URI = 233 fragment = 234 Host = 235 HTTP-date = 236 product = 237 relativeURI = 238 TE = 240 Accept = 241 Accept-Charset = 242 243 Accept-Encoding = 244 245 Accept-Language = 246 248 ETag = 249 If-Match = 250 If-Modified-Since = 251 252 If-None-Match = 253 If-Unmodified-Since = 254 256 Accept-Ranges = 257 If-Range = 258 Range = 260 Age = 261 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) 307 o Safe ("yes" or "no", see Section 8.1.1) 309 o Pointer to specification text 311 Values to be added to this name space are subject to IETF review 312 ([RFC5226], Section 4.1). Any document registering new method names 313 should be traceable through statuses of either 'Obsoletes' or 314 'Updates' to this document. 316 The registry itself is maintained at 317 . 319 4. Request Header Fields 321 The request-header fields allow the client to pass additional 322 information about the request, and about the client itself, to the 323 server. These fields act as request modifiers, with semantics 324 equivalent to the parameters on a programming language method 325 invocation. 327 request-header = Accept ; [Part3], Section 6.1 328 / Accept-Charset ; [Part3], Section 6.2 329 / Accept-Encoding ; [Part3], Section 6.3 330 / Accept-Language ; [Part3], Section 6.4 331 / Authorization ; [Part7], Section 4.1 332 / Expect ; Section 10.2 333 / From ; Section 10.3 334 / Host ; [Part1], Section 8.4 335 / If-Match ; [Part4], Section 7.2 336 / If-Modified-Since ; [Part4], Section 7.3 337 / If-None-Match ; [Part4], Section 7.4 338 / If-Range ; [Part5], Section 6.3 339 / If-Unmodified-Since ; [Part4], Section 7.5 340 / Max-Forwards ; Section 10.5 341 / Proxy-Authorization ; [Part7], Section 4.3 342 / Range ; [Part5], Section 6.4 343 / Referer ; Section 10.6 344 / TE ; [Part1], Section 8.8 345 / User-Agent ; Section 10.9 347 Request-header field names can be extended reliably only in 348 combination with a change in the protocol version. However, new or 349 experimental header fields MAY be given the semantics of request- 350 header fields if all parties in the communication recognize them to 351 be request-header fields. Unrecognized header fields are treated as 352 entity-header fields. 354 5. Status Code and Reason Phrase 356 The Status-Code element is a 3-digit integer result code of the 357 attempt to understand and satisfy the request. The status codes 358 listed below are defined in Section 9. The Reason-Phrase is intended 359 to give a short textual description of the Status-Code. The Status- 360 Code is intended for use by automata and the Reason-Phrase is 361 intended for the human user. The client is not required to examine 362 or display the Reason-Phrase. 364 The individual values of the numeric status codes defined for 365 HTTP/1.1, and an example set of corresponding Reason-Phrase's, are 366 presented below. The reason phrases listed here are only 367 recommendations -- they MAY be replaced by local equivalents without 368 affecting the protocol. 370 Status-Code = 371 "100" ; Section 9.1.1: Continue 372 / "101" ; Section 9.1.2: Switching Protocols 373 / "200" ; Section 9.2.1: OK 374 / "201" ; Section 9.2.2: Created 375 / "202" ; Section 9.2.3: Accepted 376 / "203" ; Section 9.2.4: Non-Authoritative Information 377 / "204" ; Section 9.2.5: No Content 378 / "205" ; Section 9.2.6: Reset Content 379 / "206" ; Section 9.2.7: Partial Content 380 / "300" ; Section 9.3.1: Multiple Choices 381 / "301" ; Section 9.3.2: Moved Permanently 382 / "302" ; Section 9.3.3: Found 383 / "303" ; Section 9.3.4: See Other 384 / "304" ; Section 9.3.5: Not Modified 385 / "305" ; Section 9.3.6: Use Proxy 386 / "307" ; Section 9.3.8: Temporary Redirect 387 / "400" ; Section 9.4.1: Bad Request 388 / "401" ; Section 9.4.2: Unauthorized 389 / "402" ; Section 9.4.3: Payment Required 390 / "403" ; Section 9.4.4: Forbidden 391 / "404" ; Section 9.4.5: Not Found 392 / "405" ; Section 9.4.6: Method Not Allowed 393 / "406" ; Section 9.4.7: Not Acceptable 394 / "407" ; Section 9.4.8: Proxy Authentication Required 395 / "408" ; Section 9.4.9: Request Time-out 396 / "409" ; Section 9.4.10: Conflict 397 / "410" ; Section 9.4.11: Gone 398 / "411" ; Section 9.4.12: Length Required 399 / "412" ; Section 9.4.13: Precondition Failed 400 / "413" ; Section 9.4.14: Request Entity Too Large 401 / "414" ; Section 9.4.15: Request-URI Too Large 402 / "415" ; Section 9.4.16: Unsupported Media Type 403 / "416" ; Section 9.4.17: Requested range not satisfiable 404 / "417" ; Section 9.4.18: Expectation Failed 405 / "500" ; Section 9.5.1: Internal Server Error 406 / "501" ; Section 9.5.2: Not Implemented 407 / "502" ; Section 9.5.3: Bad Gateway 408 / "503" ; Section 9.5.4: Service Unavailable 409 / "504" ; Section 9.5.5: Gateway Time-out 410 / "505" ; Section 9.5.6: HTTP Version not supported 411 / extension-code 413 extension-code = 3DIGIT 414 Reason-Phrase = * 416 HTTP status codes are extensible. HTTP applications are not required 417 to understand the meaning of all registered status codes, though such 418 understanding is obviously desirable. However, applications MUST 419 understand the class of any status code, as indicated by the first 420 digit, and treat any unrecognized response as being equivalent to the 421 x00 status code of that class, with the exception that an 422 unrecognized response MUST NOT be cached. For example, if an 423 unrecognized status code of 431 is received by the client, it can 424 safely assume that there was something wrong with its request and 425 treat the response as if it had received a 400 status code. In such 426 cases, user agents SHOULD present to the user the entity returned 427 with the response, since that entity is likely to include human- 428 readable information which will explain the unusual status. 430 5.1. Status Code Registry 432 The HTTP Status Code Registry defines the name space for the Status- 433 Code token in the Status line of an HTTP response. 435 Values to be added to this name space are subject to IETF review 436 ([RFC5226], Section 4.1). Any document registering new status codes 437 should be traceable through statuses of either 'Obsoletes' or 438 'Updates' to this document. 440 The registry itself is maintained at 441 . 443 6. Response Header Fields 445 The response-header fields allow the server to pass additional 446 information about the response which cannot be placed in the Status- 447 Line. These header fields give information about the server and 448 about further access to the resource identified by the Request-URI. 450 response-header = Accept-Ranges ; [Part5], Section 6.1 451 / Age ; [Part6], Section 16.1 452 / Allow ; Section 10.1 453 / ETag ; [Part4], Section 7.1 454 / Location ; Section 10.4 455 / Proxy-Authenticate ; [Part7], Section 4.2 456 / Retry-After ; Section 10.7 457 / Server ; Section 10.8 458 / Vary ; [Part6], Section 16.5 459 / WWW-Authenticate ; [Part7], Section 4.4 461 Response-header field names can be extended reliably only in 462 combination with a change in the protocol version. However, new or 463 experimental header fields MAY be given the semantics of response- 464 header fields if all parties in the communication recognize them to 465 be response-header fields. Unrecognized header fields are treated as 466 entity-header fields. 468 7. Entity 470 Request and Response messages MAY transfer an entity if not otherwise 471 restricted by the request method or response status code. An entity 472 consists of entity-header fields and an entity-body, although some 473 responses will only include the entity-headers. HTTP entity-body and 474 entity-header fields are defined in [Part3]. 476 An entity-body is only present in a message when a message-body is 477 present, as described in Section 4.3 of [Part1]. The entity-body is 478 obtained from the message-body by decoding any Transfer-Encoding that 479 might have been applied to ensure safe and proper transfer of the 480 message. 482 8. Method Definitions 484 The set of common methods for HTTP/1.1 is defined below. Although 485 this set can be expanded, additional methods cannot be assumed to 486 share the same semantics for separately extended clients and servers. 488 8.1. Safe and Idempotent Methods 490 8.1.1. Safe Methods 492 Implementors should be aware that the software represents the user in 493 their interactions over the Internet, and should be careful to allow 494 the user to be aware of any actions they might take which may have an 495 unexpected significance to themselves or others. 497 In particular, the convention has been established that the GET and 498 HEAD methods SHOULD NOT have the significance of taking an action 499 other than retrieval. These methods ought to be considered "safe". 500 This allows user agents to represent other methods, such as POST, PUT 501 and DELETE, in a special way, so that the user is made aware of the 502 fact that a possibly unsafe action is being requested. 504 Naturally, it is not possible to ensure that the server does not 505 generate side-effects as a result of performing a GET request; in 506 fact, some dynamic resources consider that a feature. The important 507 distinction here is that the user did not request the side-effects, 508 so therefore cannot be held accountable for them. 510 8.1.2. Idempotent Methods 512 Methods can also have the property of "idempotence" in that (aside 513 from error or expiration issues) the side-effects of N > 0 identical 514 requests is the same as for a single request. The methods GET, HEAD, 515 PUT and DELETE share this property. Also, the methods OPTIONS and 516 TRACE SHOULD NOT have side effects, and so are inherently idempotent. 518 However, it is possible that a sequence of several requests is non- 519 idempotent, even if all of the methods executed in that sequence are 520 idempotent. (A sequence is idempotent if a single execution of the 521 entire sequence always yields a result that is not changed by a 522 reexecution of all, or part, of that sequence.) For example, a 523 sequence is non-idempotent if its result depends on a value that is 524 later modified in the same sequence. 526 A sequence that never has side effects is idempotent, by definition 527 (provided that no concurrent operations are being executed on the 528 same set of resources). 530 8.2. OPTIONS 532 The OPTIONS method represents a request for information about the 533 communication options available on the request/response chain 534 identified by the Request-URI. This method allows the client to 535 determine the options and/or requirements associated with a resource, 536 or the capabilities of a server, without implying a resource action 537 or initiating a resource retrieval. 539 Responses to this method are not cacheable. 541 If the OPTIONS request includes an entity-body (as indicated by the 542 presence of Content-Length or Transfer-Encoding), then the media type 543 MUST be indicated by a Content-Type field. Although this 544 specification does not define any use for such a body, future 545 extensions to HTTP might use the OPTIONS body to make more detailed 546 queries on the server. 548 If the Request-URI is an asterisk ("*"), the OPTIONS request is 549 intended to apply to the server in general rather than to a specific 550 resource. Since a server's communication options typically depend on 551 the resource, the "*" request is only useful as a "ping" or "no-op" 552 type of method; it does nothing beyond allowing the client to test 553 the capabilities of the server. For example, this can be used to 554 test a proxy for HTTP/1.1 compliance (or lack thereof). 556 If the Request-URI is not an asterisk, the OPTIONS request applies 557 only to the options that are available when communicating with that 558 resource. 560 A 200 response SHOULD include any header fields that indicate 561 optional features implemented by the server and applicable to that 562 resource (e.g., Allow), possibly including extensions not defined by 563 this specification. The response body, if any, SHOULD also include 564 information about the communication options. The format for such a 565 body is not defined by this specification, but might be defined by 566 future extensions to HTTP. Content negotiation MAY be used to select 567 the appropriate response format. If no response body is included, 568 the response MUST include a Content-Length field with a field-value 569 of "0". 571 The Max-Forwards request-header field MAY be used to target a 572 specific proxy in the request chain. When a proxy receives an 573 OPTIONS request on an absolute-URI for which request forwarding is 574 permitted, the proxy MUST check for a Max-Forwards field. If the 575 Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward 576 the message; instead, the proxy SHOULD respond with its own 577 communication options. If the Max-Forwards field-value is an integer 578 greater than zero, the proxy MUST decrement the field-value when it 579 forwards the request. If no Max-Forwards field is present in the 580 request, then the forwarded request MUST NOT include a Max-Forwards 581 field. 583 8.3. GET 585 The GET method means retrieve whatever information (in the form of an 586 entity) is identified by the Request-URI. If the Request-URI refers 587 to a data-producing process, it is the produced data which shall be 588 returned as the entity in the response and not the source text of the 589 process, unless that text happens to be the output of the process. 591 The semantics of the GET method change to a "conditional GET" if the 592 request message includes an If-Modified-Since, If-Unmodified-Since, 593 If-Match, If-None-Match, or If-Range header field. A conditional GET 594 method requests that the entity be transferred only under the 595 circumstances described by the conditional header field(s). The 596 conditional GET method is intended to reduce unnecessary network 597 usage by allowing cached entities to be refreshed without requiring 598 multiple requests or transferring data already held by the client. 600 The semantics of the GET method change to a "partial GET" if the 601 request message includes a Range header field. A partial GET 602 requests that only part of the entity be transferred, as described in 603 Section 6.4 of [Part5]. The partial GET method is intended to reduce 604 unnecessary network usage by allowing partially-retrieved entities to 605 be completed without transferring data already held by the client. 607 The response to a GET request is cacheable if and only if it meets 608 the requirements for HTTP caching described in [Part6]. 610 See Section 12.2 for security considerations when used for forms. 612 8.4. HEAD 614 The HEAD method is identical to GET except that the server MUST NOT 615 return a message-body in the response. The metainformation contained 616 in the HTTP headers in response to a HEAD request SHOULD be identical 617 to the information sent in response to a GET request. This method 618 can be used for obtaining metainformation about the entity implied by 619 the request without transferring the entity-body itself. This method 620 is often used for testing hypertext links for validity, 621 accessibility, and recent modification. 623 The response to a HEAD request MAY be cacheable in the sense that the 624 information contained in the response MAY be used to update a 625 previously cached entity from that resource. If the new field values 626 indicate that the cached entity differs from the current entity (as 627 would be indicated by a change in Content-Length, Content-MD5, ETag 628 or Last-Modified), then the cache MUST treat the cache entry as 629 stale. 631 8.5. POST 633 The POST method is used to request that the origin server accept the 634 entity enclosed in the request as data to be processed by the 635 resource identified by the Request-URI in the Request-Line. POST is 636 designed to allow a uniform method to cover the following functions: 638 o Annotation of existing resources; 640 o Posting a message to a bulletin board, newsgroup, mailing list, or 641 similar group of articles; 643 o Providing a block of data, such as the result of submitting a 644 form, to a data-handling process; 646 o Extending a database through an append operation. 648 The actual function performed by the POST method is determined by the 649 server and is usually dependent on the Request-URI. 651 The action performed by the POST method might not result in a 652 resource that can be identified by a URI. In this case, either 200 653 (OK) or 204 (No Content) is the appropriate response status, 654 depending on whether or not the response includes an entity that 655 describes the result. 657 If a resource has been created on the origin server, the response 658 SHOULD be 201 (Created) and contain an entity which describes the 659 status of the request and refers to the new resource, and a Location 660 header (see Section 10.4). 662 Responses to this method are not cacheable, unless the response 663 includes appropriate Cache-Control or Expires header fields. 664 However, the 303 (See Other) response can be used to direct the user 665 agent to retrieve a cacheable resource. 667 8.6. PUT 669 The PUT method requests that the enclosed entity be stored at the 670 supplied Request-URI. If the Request-URI refers to an already 671 existing resource, the enclosed entity SHOULD be considered as a 672 modified version of the one residing on the origin server. If the 673 Request-URI does not point to an existing resource, and that URI is 674 capable of being defined as a new resource by the requesting user 675 agent, the origin server can create the resource with that URI. If a 676 new resource is created at the Request-URI, the origin server MUST 677 inform the user agent via the 201 (Created) response. If an existing 678 resource is modified, either the 200 (OK) or 204 (No Content) 679 response codes SHOULD be sent to indicate successful completion of 680 the request. If the resource could not be created or modified with 681 the Request-URI, an appropriate error response SHOULD be given that 682 reflects the nature of the problem. The recipient of the entity MUST 683 NOT ignore any Content-* headers (headers starting with the prefix 684 'Content-') that it does not understand or implement and MUST return 685 a 501 (Not Implemented) response in such cases. 687 If the request passes through a cache and the Request-URI identifies 688 one or more currently cached entities, those entries SHOULD be 689 treated as stale. Responses to this method are not cacheable. 691 The fundamental difference between the POST and PUT requests is 692 reflected in the different meaning of the Request-URI. The URI in a 693 POST request identifies the resource that will handle the enclosed 694 entity. That resource might be a data-accepting process, a gateway 695 to some other protocol, or a separate entity that accepts 696 annotations. In contrast, the URI in a PUT request identifies the 697 entity enclosed with the request -- the user agent knows what URI is 698 intended and the server MUST NOT attempt to apply the request to some 699 other resource. If the server desires that the request be applied to 700 a different URI, it MUST send a 301 (Moved Permanently) response; the 701 user agent MAY then make its own decision regarding whether or not to 702 redirect the request. 704 A single resource MAY be identified by many different URIs. For 705 example, an article might have a URI for identifying "the current 706 version" which is separate from the URI identifying each particular 707 version. In this case, a PUT request on a general URI might result 708 in several other URIs being defined by the origin server. 710 HTTP/1.1 does not define how a PUT method affects the state of an 711 origin server. 713 Unless otherwise specified for a particular entity-header, the 714 entity-headers in the PUT request SHOULD be applied to the resource 715 created or modified by the PUT. 717 8.7. DELETE 719 The DELETE method requests that the origin server delete the resource 720 identified by the Request-URI. This method MAY be overridden by 721 human intervention (or other means) on the origin server. The client 722 cannot be guaranteed that the operation has been carried out, even if 723 the status code returned from the origin server indicates that the 724 action has been completed successfully. However, the server SHOULD 725 NOT indicate success unless, at the time the response is given, it 726 intends to delete the resource or move it to an inaccessible 727 location. 729 A successful response SHOULD be 200 (OK) if the response includes an 730 entity describing the status, 202 (Accepted) if the action has not 731 yet been enacted, or 204 (No Content) if the action has been enacted 732 but the response does not include an entity. 734 If the request passes through a cache and the Request-URI identifies 735 one or more currently cached entities, those entries SHOULD be 736 treated as stale. Responses to this method are not cacheable. 738 8.8. TRACE 740 The TRACE method is used to invoke a remote, application-layer loop- 741 back of the request message. The final recipient of the request 742 SHOULD reflect the message received back to the client as the entity- 743 body of a 200 (OK) response. The final recipient is either the 744 origin server or the first proxy or gateway to receive a Max-Forwards 745 value of zero (0) in the request (see Section 10.5). A TRACE request 746 MUST NOT include an entity. 748 TRACE allows the client to see what is being received at the other 749 end of the request chain and use that data for testing or diagnostic 750 information. The value of the Via header field (Section 8.9 of 751 [Part1]) is of particular interest, since it acts as a trace of the 752 request chain. Use of the Max-Forwards header field allows the 753 client to limit the length of the request chain, which is useful for 754 testing a chain of proxies forwarding messages in an infinite loop. 756 If the request is valid, the response SHOULD contain the entire 757 request message in the entity-body, with a Content-Type of "message/ 758 http" (see Section 9.3.1 of [Part1]). Responses to this method MUST 759 NOT be cached. 761 8.9. CONNECT 763 This specification reserves the method name CONNECT for use with a 764 proxy that can dynamically switch to being a tunnel (e.g. SSL 765 tunneling [RFC2817]). 767 9. Status Code Definitions 769 Each Status-Code is described below, including a description of which 770 method(s) it can follow and any metainformation required in the 771 response. 773 9.1. Informational 1xx 775 This class of status code indicates a provisional response, 776 consisting only of the Status-Line and optional headers, and is 777 terminated by an empty line. There are no required headers for this 778 class of status code. Since HTTP/1.0 did not define any 1xx status 779 codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client 780 except under experimental conditions. 782 A client MUST be prepared to accept one or more 1xx status responses 783 prior to a regular response, even if the client does not expect a 100 784 (Continue) status message. Unexpected 1xx status responses MAY be 785 ignored by a user agent. 787 Proxies MUST forward 1xx responses, unless the connection between the 788 proxy and its client has been closed, or unless the proxy itself 789 requested the generation of the 1xx response. (For example, if a 790 proxy adds a "Expect: 100-continue" field when it forwards a request, 791 then it need not forward the corresponding 100 (Continue) 792 response(s).) 794 9.1.1. 100 Continue 796 The client SHOULD continue with its request. This interim response 797 is used to inform the client that the initial part of the request has 798 been received and has not yet been rejected by the server. The 799 client SHOULD continue by sending the remainder of the request or, if 800 the request has already been completed, ignore this response. The 801 server MUST send a final response after the request has been 802 completed. See Section 7.2.3 of [Part1] for detailed discussion of 803 the use and handling of this status code. 805 9.1.2. 101 Switching Protocols 807 The server understands and is willing to comply with the client's 808 request, via the Upgrade message header field (Section 6.4 of 809 [Part5]), for a change in the application protocol being used on this 810 connection. The server will switch protocols to those defined by the 811 response's Upgrade header field immediately after the empty line 812 which terminates the 101 response. 814 The protocol SHOULD be switched only when it is advantageous to do 815 so. For example, switching to a newer version of HTTP is 816 advantageous over older versions, and switching to a real-time, 817 synchronous protocol might be advantageous when delivering resources 818 that use such features. 820 9.2. Successful 2xx 822 This class of status code indicates that the client's request was 823 successfully received, understood, and accepted. 825 9.2.1. 200 OK 827 The request has succeeded. The information returned with the 828 response is dependent on the method used in the request, for example: 830 GET an entity corresponding to the requested resource is sent in the 831 response; 833 HEAD the entity-header fields corresponding to the requested 834 resource are sent in the response without any message-body; 836 POST an entity describing or containing the result of the action; 838 TRACE an entity containing the request message as received by the 839 end server. 841 9.2.2. 201 Created 843 The request has been fulfilled and resulted in a new resource being 844 created. The newly created resource can be referenced by the URI(s) 845 returned in the entity of the response, with the most specific URI 846 for the resource given by a Location header field. The response 847 SHOULD include an entity containing a list of resource 848 characteristics and location(s) from which the user or user agent can 849 choose the one most appropriate. The entity format is specified by 850 the media type given in the Content-Type header field. The origin 851 server MUST create the resource before returning the 201 status code. 852 If the action cannot be carried out immediately, the server SHOULD 853 respond with 202 (Accepted) response instead. 855 A 201 response MAY contain an ETag response header field indicating 856 the current value of the entity tag for the requested variant just 857 created, see Section 7.1 of [Part4]. 859 9.2.3. 202 Accepted 861 The request has been accepted for processing, but the processing has 862 not been completed. The request might or might not eventually be 863 acted upon, as it might be disallowed when processing actually takes 864 place. There is no facility for re-sending a status code from an 865 asynchronous operation such as this. 867 The 202 response is intentionally non-committal. Its purpose is to 868 allow a server to accept a request for some other process (perhaps a 869 batch-oriented process that is only run once per day) without 870 requiring that the user agent's connection to the server persist 871 until the process is completed. The entity returned with this 872 response SHOULD include an indication of the request's current status 873 and either a pointer to a status monitor or some estimate of when the 874 user can expect the request to be fulfilled. 876 9.2.4. 203 Non-Authoritative Information 878 The returned metainformation in the entity-header is not the 879 definitive set as available from the origin server, but is gathered 880 from a local or a third-party copy. The set presented MAY be a 881 subset or superset of the original version. For example, including 882 local annotation information about the resource might result in a 883 superset of the metainformation known by the origin server. Use of 884 this response code is not required and is only appropriate when the 885 response would otherwise be 200 (OK). 887 9.2.5. 204 No Content 889 The server has fulfilled the request but does not need to return an 890 entity-body, and might want to return updated metainformation. The 891 response MAY include new or updated metainformation in the form of 892 entity-headers, which if present SHOULD be associated with the 893 requested variant. 895 If the client is a user agent, it SHOULD NOT change its document view 896 from that which caused the request to be sent. This response is 897 primarily intended to allow input for actions to take place without 898 causing a change to the user agent's active document view, although 899 any new or updated metainformation SHOULD be applied to the document 900 currently in the user agent's active view. 902 The 204 response MUST NOT include a message-body, and thus is always 903 terminated by the first empty line after the header fields. 905 9.2.6. 205 Reset Content 907 The server has fulfilled the request and the user agent SHOULD reset 908 the document view which caused the request to be sent. This response 909 is primarily intended to allow input for actions to take place via 910 user input, followed by a clearing of the form in which the input is 911 given so that the user can easily initiate another input action. The 912 response MUST NOT include an entity. 914 9.2.7. 206 Partial Content 916 The server has fulfilled the partial GET request for the resource and 917 the enclosed entity is a partial representation as defined in 918 [Part5]. 920 9.3. Redirection 3xx 922 This class of status code indicates that further action needs to be 923 taken by the user agent in order to fulfill the request. The action 924 required MAY be carried out by the user agent without interaction 925 with the user if and only if the method used in the second request is 926 GET or HEAD. A client SHOULD detect infinite redirection loops, 927 since such loops generate network traffic for each redirection. 929 Note: previous versions of this specification recommended a 930 maximum of five redirections. Content developers should be aware 931 that there might be clients that implement such a fixed 932 limitation. 934 9.3.1. 300 Multiple Choices 936 The requested resource corresponds to any one of a set of 937 representations, each with its own specific location, and agent- 938 driven negotiation information (Section 5 of [Part3]) is being 939 provided so that the user (or user agent) can select a preferred 940 representation and redirect its request to that location. 942 Unless it was a HEAD request, the response SHOULD include an entity 943 containing a list of resource characteristics and location(s) from 944 which the user or user agent can choose the one most appropriate. 945 The entity format is specified by the media type given in the 946 Content-Type header field. Depending upon the format and the 947 capabilities of the user agent, selection of the most appropriate 948 choice MAY be performed automatically. However, this specification 949 does not define any standard for such automatic selection. 951 If the server has a preferred choice of representation, it SHOULD 952 include the specific URI for that representation in the Location 953 field; user agents MAY use the Location field value for automatic 954 redirection. This response is cacheable unless indicated otherwise. 956 9.3.2. 301 Moved Permanently 958 The requested resource has been assigned a new permanent URI and any 959 future references to this resource SHOULD use one of the returned 960 URIs. Clients with link editing capabilities ought to automatically 961 re-link references to the Request-URI to one or more of the new 962 references returned by the server, where possible. This response is 963 cacheable unless indicated otherwise. 965 The new permanent URI SHOULD be given by the Location field in the 966 response. Unless the request method was HEAD, the entity of the 967 response SHOULD contain a short hypertext note with a hyperlink to 968 the new URI(s). 970 If the 301 status code is received in response to a request method 971 that is known to be "safe", as defined in Section 8.1.1, then the 972 request MAY be automatically redirected by the user agent without 973 confirmation. Otherwise, the user agent MUST NOT automatically 974 redirect the request unless it can be confirmed by the user, since 975 this might change the conditions under which the request was issued. 977 Note: When automatically redirecting a POST request after 978 receiving a 301 status code, some existing HTTP/1.0 user agents 979 will erroneously change it into a GET request. 981 9.3.3. 302 Found 983 The requested resource resides temporarily under a different URI. 984 Since the redirection might be altered on occasion, the client SHOULD 985 continue to use the Request-URI for future requests. This response 986 is only cacheable if indicated by a Cache-Control or Expires header 987 field. 989 The temporary URI SHOULD be given by the Location field in the 990 response. Unless the request method was HEAD, the entity of the 991 response SHOULD contain a short hypertext note with a hyperlink to 992 the new URI(s). 994 If the 302 status code is received in response to a request method 995 that is known to be "safe", as defined in Section 8.1.1, then the 996 request MAY be automatically redirected by the user agent without 997 confirmation. Otherwise, the user agent MUST NOT automatically 998 redirect the request unless it can be confirmed by the user, since 999 this might change the conditions under which the request was issued. 1001 Note: [RFC1945] and [RFC2068] specify that the client is not 1002 allowed to change the method on the redirected request. However, 1003 most existing user agent implementations treat 302 as if it were a 1004 303 response, performing a GET on the Location field-value 1005 regardless of the original request method. The status codes 303 1006 and 307 have been added for servers that wish to make 1007 unambiguously clear which kind of reaction is expected of the 1008 client. 1010 9.3.4. 303 See Other 1012 The server directs the user agent to a different resource, indicated 1013 by a URI in the Location header field, that provides an indirect 1014 response to the original request. The user agent MAY perform a GET 1015 request on the URI in the Location field in order to obtain a 1016 representation corresponding to the response, be redirected again, or 1017 end with an error status. The Location URI is not a substitute 1018 reference for the originally requested resource. 1020 The 303 status is generally applicable to any HTTP method. It is 1021 primarily used to allow the output of a POST action to redirect the 1022 user agent to a selected resource, since doing so provides the 1023 information corresponding to the POST response in a form that can be 1024 separately identified, bookmarked, and cached independent of the 1025 original request. 1027 A 303 response to a GET request indicates that the requested resource 1028 does not have a representation of its own that can be transferred by 1029 the server over HTTP. The Location URI indicates a resource that is 1030 descriptive of the requested resource such that the follow-on 1031 representation may be useful without implying that it adequately 1032 represents the previously requested resource. Note that answers to 1033 the questions of what can be represented, what representations are 1034 adequate, and what might be a useful description are outside the 1035 scope of HTTP and thus entirely determined by the resource owner(s). 1037 A 303 response SHOULD NOT be cached unless it is indicated as 1038 cacheable by Cache-Control or Expires header fields. Except for 1039 responses to a HEAD request, the entity of a 303 response SHOULD 1040 contain a short hypertext note with a hyperlink to the Location URI. 1042 9.3.5. 304 Not Modified 1044 The response to the request has not been modified since the 1045 conditions indicated by the client's conditional GET request, as 1046 defined in [Part4]. 1048 9.3.6. 305 Use Proxy 1050 The 305 status was defined in a previous version of this 1051 specification (see Appendix A.2), and is now deprecated. 1053 9.3.7. 306 (Unused) 1055 The 306 status code was used in a previous version of the 1056 specification, is no longer used, and the code is reserved. 1058 9.3.8. 307 Temporary Redirect 1060 The requested resource resides temporarily under a different URI. 1061 Since the redirection MAY be altered on occasion, the client SHOULD 1062 continue to use the Request-URI for future requests. This response 1063 is only cacheable if indicated by a Cache-Control or Expires header 1064 field. 1066 The temporary URI SHOULD be given by the Location field in the 1067 response. Unless the request method was HEAD, the entity of the 1068 response SHOULD contain a short hypertext note with a hyperlink to 1069 the new URI(s) , since many pre-HTTP/1.1 user agents do not 1070 understand the 307 status. Therefore, the note SHOULD contain the 1071 information necessary for a user to repeat the original request on 1072 the new URI. 1074 If the 307 status code is received in response to a request method 1075 that is known to be "safe", as defined in Section 8.1.1, then the 1076 request MAY be automatically redirected by the user agent without 1077 confirmation. Otherwise, the user agent MUST NOT automatically 1078 redirect the request unless it can be confirmed by the user, since 1079 this might change the conditions under which the request was issued. 1081 9.4. Client Error 4xx 1083 The 4xx class of status code is intended for cases in which the 1084 client seems to have erred. Except when responding to a HEAD 1085 request, the server SHOULD include an entity containing an 1086 explanation of the error situation, and whether it is a temporary or 1087 permanent condition. These status codes are applicable to any 1088 request method. User agents SHOULD display any included entity to 1089 the user. 1091 If the client is sending data, a server implementation using TCP 1092 SHOULD be careful to ensure that the client acknowledges receipt of 1093 the packet(s) containing the response, before the server closes the 1094 input connection. If the client continues sending data to the server 1095 after the close, the server's TCP stack will send a reset packet to 1096 the client, which may erase the client's unacknowledged input buffers 1097 before they can be read and interpreted by the HTTP application. 1099 9.4.1. 400 Bad Request 1101 The request could not be understood by the server due to malformed 1102 syntax. The client SHOULD NOT repeat the request without 1103 modifications. 1105 9.4.2. 401 Unauthorized 1107 The request requires user authentication (see [Part7]). 1109 9.4.3. 402 Payment Required 1111 This code is reserved for future use. 1113 9.4.4. 403 Forbidden 1115 The server understood the request, but is refusing to fulfill it. 1116 Authorization will not help and the request SHOULD NOT be repeated. 1117 If the request method was not HEAD and the server wishes to make 1118 public why the request has not been fulfilled, it SHOULD describe the 1119 reason for the refusal in the entity. If the server does not wish to 1120 make this information available to the client, the status code 404 1121 (Not Found) can be used instead. 1123 9.4.5. 404 Not Found 1125 The server has not found anything matching the Request-URI. No 1126 indication is given of whether the condition is temporary or 1127 permanent. The 410 (Gone) status code SHOULD be used if the server 1128 knows, through some internally configurable mechanism, that an old 1129 resource is permanently unavailable and has no forwarding address. 1130 This status code is commonly used when the server does not wish to 1131 reveal exactly why the request has been refused, or when no other 1132 response is applicable. 1134 9.4.6. 405 Method Not Allowed 1136 The method specified in the Request-Line is not allowed for the 1137 resource identified by the Request-URI. The response MUST include an 1138 Allow header containing a list of valid methods for the requested 1139 resource. 1141 9.4.7. 406 Not Acceptable 1143 The resource identified by the request is only capable of generating 1144 response entities which have content characteristics not acceptable 1145 according to the accept headers sent in the request. 1147 Unless it was a HEAD request, the response SHOULD include an entity 1148 containing a list of available entity characteristics and location(s) 1149 from which the user or user agent can choose the one most 1150 appropriate. The entity format is specified by the media type given 1151 in the Content-Type header field. Depending upon the format and the 1152 capabilities of the user agent, selection of the most appropriate 1153 choice MAY be performed automatically. However, this specification 1154 does not define any standard for such automatic selection. 1156 Note: HTTP/1.1 servers are allowed to return responses which are 1157 not acceptable according to the accept headers sent in the 1158 request. In some cases, this may even be preferable to sending a 1159 406 response. User agents are encouraged to inspect the headers 1160 of an incoming response to determine if it is acceptable. 1162 If the response could be unacceptable, a user agent SHOULD 1163 temporarily stop receipt of more data and query the user for a 1164 decision on further actions. 1166 9.4.8. 407 Proxy Authentication Required 1168 This code is similar to 401 (Unauthorized), but indicates that the 1169 client must first authenticate itself with the proxy (see [Part7]). 1171 9.4.9. 408 Request Timeout 1173 The client did not produce a request within the time that the server 1174 was prepared to wait. The client MAY repeat the request without 1175 modifications at any later time. 1177 9.4.10. 409 Conflict 1179 The request could not be completed due to a conflict with the current 1180 state of the resource. This code is only allowed in situations where 1181 it is expected that the user might be able to resolve the conflict 1182 and resubmit the request. The response body SHOULD include enough 1183 information for the user to recognize the source of the conflict. 1184 Ideally, the response entity would include enough information for the 1185 user or user agent to fix the problem; however, that might not be 1186 possible and is not required. 1188 Conflicts are most likely to occur in response to a PUT request. For 1189 example, if versioning were being used and the entity being PUT 1190 included changes to a resource which conflict with those made by an 1191 earlier (third-party) request, the server might use the 409 response 1192 to indicate that it can't complete the request. In this case, the 1193 response entity would likely contain a list of the differences 1194 between the two versions in a format defined by the response Content- 1195 Type. 1197 9.4.11. 410 Gone 1199 The requested resource is no longer available at the server and no 1200 forwarding address is known. This condition is expected to be 1201 considered permanent. Clients with link editing capabilities SHOULD 1202 delete references to the Request-URI after user approval. If the 1203 server does not know, or has no facility to determine, whether or not 1204 the condition is permanent, the status code 404 (Not Found) SHOULD be 1205 used instead. This response is cacheable unless indicated otherwise. 1207 The 410 response is primarily intended to assist the task of web 1208 maintenance by notifying the recipient that the resource is 1209 intentionally unavailable and that the server owners desire that 1210 remote links to that resource be removed. Such an event is common 1211 for limited-time, promotional services and for resources belonging to 1212 individuals no longer working at the server's site. It is not 1213 necessary to mark all permanently unavailable resources as "gone" or 1214 to keep the mark for any length of time -- that is left to the 1215 discretion of the server owner. 1217 9.4.12. 411 Length Required 1219 The server refuses to accept the request without a defined Content- 1220 Length. The client MAY repeat the request if it adds a valid 1221 Content-Length header field containing the length of the message-body 1222 in the request message. 1224 9.4.13. 412 Precondition Failed 1226 The precondition given in one or more of the request-header fields 1227 evaluated to false when it was tested on the server, as defined in 1228 [Part4]. 1230 9.4.14. 413 Request Entity Too Large 1232 The server is refusing to process a request because the request 1233 entity is larger than the server is willing or able to process. The 1234 server MAY close the connection to prevent the client from continuing 1235 the request. 1237 If the condition is temporary, the server SHOULD include a Retry- 1238 After header field to indicate that it is temporary and after what 1239 time the client MAY try again. 1241 9.4.15. 414 Request-URI Too Long 1243 The server is refusing to service the request because the Request-URI 1244 is longer than the server is willing to interpret. This rare 1245 condition is only likely to occur when a client has improperly 1246 converted a POST request to a GET request with long query 1247 information, when the client has descended into a URI "black hole" of 1248 redirection (e.g., a redirected URI prefix that points to a suffix of 1249 itself), or when the server is under attack by a client attempting to 1250 exploit security holes present in some servers using fixed-length 1251 buffers for reading or manipulating the Request-URI. 1253 9.4.16. 415 Unsupported Media Type 1255 The server is refusing to service the request because the entity of 1256 the request is in a format not supported by the requested resource 1257 for the requested method. 1259 9.4.17. 416 Requested Range Not Satisfiable 1261 The request included a Range request-header field (Section 6.4 of 1262 [Part5]) and none of the range-specifier values in this field overlap 1263 the current extent of the selected resource. 1265 9.4.18. 417 Expectation Failed 1267 The expectation given in an Expect request-header field (see 1268 Section 10.2) could not be met by this server, or, if the server is a 1269 proxy, the server has unambiguous evidence that the request could not 1270 be met by the next-hop server. 1272 9.5. Server Error 5xx 1274 Response status codes beginning with the digit "5" indicate cases in 1275 which the server is aware that it has erred or is incapable of 1276 performing the request. Except when responding to a HEAD request, 1277 the server SHOULD include an entity containing an explanation of the 1278 error situation, and whether it is a temporary or permanent 1279 condition. User agents SHOULD display any included entity to the 1280 user. These response codes are applicable to any request method. 1282 9.5.1. 500 Internal Server Error 1284 The server encountered an unexpected condition which prevented it 1285 from fulfilling the request. 1287 9.5.2. 501 Not Implemented 1289 The server does not support the functionality required to fulfill the 1290 request. This is the appropriate response when the server does not 1291 recognize the request method and is not capable of supporting it for 1292 any resource. 1294 9.5.3. 502 Bad Gateway 1296 The server, while acting as a gateway or proxy, received an invalid 1297 response from the upstream server it accessed in attempting to 1298 fulfill the request. 1300 9.5.4. 503 Service Unavailable 1302 The server is currently unable to handle the request due to a 1303 temporary overloading or maintenance of the server. The implication 1304 is that this is a temporary condition which will be alleviated after 1305 some delay. If known, the length of the delay MAY be indicated in a 1306 Retry-After header. If no Retry-After is given, the client SHOULD 1307 handle the response as it would for a 500 response. 1309 Note: The existence of the 503 status code does not imply that a 1310 server must use it when becoming overloaded. Some servers may 1311 wish to simply refuse the connection. 1313 9.5.5. 504 Gateway Timeout 1315 The server, while acting as a gateway or proxy, did not receive a 1316 timely response from the upstream server specified by the URI (e.g. 1317 HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed 1318 to access in attempting to complete the request. 1320 Note: Note to implementors: some deployed proxies are known to 1321 return 400 or 500 when DNS lookups time out. 1323 9.5.6. 505 HTTP Version Not Supported 1325 The server does not support, or refuses to support, the protocol 1326 version that was used in the request message. The server is 1327 indicating that it is unable or unwilling to complete the request 1328 using the same major version as the client, as described in Section 1329 3.1 of [Part1], other than with this error message. The response 1330 SHOULD contain an entity describing why that version is not supported 1331 and what other protocols are supported by that server. 1333 10. Header Field Definitions 1335 This section defines the syntax and semantics of HTTP/1.1 header 1336 fields related to request and response semantics. 1338 For entity-header fields, both sender and recipient refer to either 1339 the client or the server, depending on who sends and who receives the 1340 entity. 1342 10.1. Allow 1344 The response-header field "Allow" lists the set of methods advertised 1345 as supported by the resource identified by the Request-URI. The 1346 purpose of this field is strictly to inform the recipient of valid 1347 methods associated with the resource. An Allow header field MUST be 1348 present in a 405 (Method Not Allowed) response. 1350 Allow = "Allow" ":" OWS Allow-v 1351 Allow-v = #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 request-header field "Expect" is used to indicate that particular 1367 server behaviors are required by the client. 1369 Expect = "Expect" ":" OWS Expect-v 1370 Expect-v = 1#expectation 1372 expectation = "100-continue" / expectation-extension 1373 expectation-extension = token [ "=" ( token / quoted-string ) 1374 *expect-params ] 1375 expect-params = ";" token [ "=" ( token / quoted-string ) ] 1377 A server that does not understand or is unable to comply with any of 1378 the expectation values in the Expect field of a request MUST respond 1379 with appropriate error status. The server MUST respond with a 417 1380 (Expectation Failed) status if any of the expectations cannot be met 1381 or, if there are other problems with the request, some other 4xx 1382 status. 1384 This header field is defined with extensible syntax to allow for 1385 future extensions. If a server receives a request containing an 1386 Expect field that includes an expectation-extension that it does not 1387 support, it MUST respond with a 417 (Expectation Failed) status. 1389 Comparison of expectation values is case-insensitive for unquoted 1390 tokens (including the 100-continue token), and is case-sensitive for 1391 quoted-string expectation-extensions. 1393 The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST 1394 return a 417 (Expectation Failed) status if it receives a request 1395 with an expectation that it cannot meet. However, the Expect 1396 request-header itself is end-to-end; it MUST be forwarded if the 1397 request is forwarded. 1399 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the 1400 Expect header. 1402 See Section 7.2.3 of [Part1] for the use of the 100 (Continue) 1403 status. 1405 10.3. From 1407 The request-header field "From", if given, SHOULD contain an Internet 1408 e-mail address for the human user who controls the requesting user 1409 agent. The address SHOULD be machine-usable, as defined by "mailbox" 1410 in Section 3.4 of [RFC5322]: 1412 From = "From" ":" OWS From-v 1413 From-v = mailbox 1415 mailbox = 1417 An example is: 1419 From: webmaster@example.org 1421 This header field MAY be used for logging purposes and as a means for 1422 identifying the source of invalid or unwanted requests. It SHOULD 1423 NOT be used as an insecure form of access protection. The 1424 interpretation of this field is that the request is being performed 1425 on behalf of the person given, who accepts responsibility for the 1426 method performed. In particular, robot agents SHOULD include this 1427 header so that the person responsible for running the robot can be 1428 contacted if problems occur on the receiving end. 1430 The Internet e-mail address in this field MAY be separate from the 1431 Internet host which issued the request. For example, when a request 1432 is passed through a proxy the original issuer's address SHOULD be 1433 used. 1435 The client SHOULD NOT send the From header field without the user's 1436 approval, as it might conflict with the user's privacy interests or 1437 their site's security policy. It is strongly recommended that the 1438 user be able to disable, enable, and modify the value of this field 1439 at any time prior to a request. 1441 10.4. Location 1443 The response-header field "Location" is used for the identification 1444 of a new resource or to redirect the recipient to a location other 1445 than the Request-URI for completion of the request. For 201 1446 (Created) responses, the Location is that of the new resource which 1447 was created by the request. For 3xx responses, the location SHOULD 1448 indicate the server's preferred URI for automatic redirection to the 1449 resource. The field value consists of a single absolute URI. 1451 Location = "Location" ":" OWS Location-v 1452 Location-v = absolute-URI [ "#" fragment ] 1454 An example is: 1456 Location: http://www.example.org/pub/WWW/People.html 1458 Note: The Content-Location header field (Section 6.7 of [Part3]) 1459 differs from Location in that the Content-Location identifies the 1460 original location of the entity enclosed in the response. It is 1461 therefore possible for a response to contain header fields for 1462 both Location and Content-Location. 1464 There are circumstances in which a fragment identifier in a Location 1465 URL would not be appropriate: 1467 o With a 201 Created response, because in this usage the Location 1468 header specifies the URL for the entire created resource. 1470 o With a 300 Multiple Choices, since the choice decision is intended 1471 to be made on resource characteristics and not fragment 1472 characteristics. 1474 o With 305 Use Proxy. 1476 10.5. Max-Forwards 1478 The request-header "Max-Forwards" field provides a mechanism with the 1479 TRACE (Section 8.8) and OPTIONS (Section 8.2) methods to limit the 1480 number of proxies or gateways that can forward the request to the 1481 next inbound server. This can be useful when the client is 1482 attempting to trace a request chain which appears to be failing or 1483 looping in mid-chain. 1485 Max-Forwards = "Max-Forwards" ":" OWS Max-Forwards-v 1486 Max-Forwards-v = 1*DIGIT 1488 The Max-Forwards value is a decimal integer indicating the remaining 1489 number of times this request message may be forwarded. 1491 Each proxy or gateway recipient of a TRACE or OPTIONS request 1492 containing a Max-Forwards header field MUST check and update its 1493 value prior to forwarding the request. If the received value is zero 1494 (0), the recipient MUST NOT forward the request; instead, it MUST 1495 respond as the final recipient. If the received Max-Forwards value 1496 is greater than zero, then the forwarded message MUST contain an 1497 updated Max-Forwards field with a value decremented by one (1). 1499 The Max-Forwards header field MAY be ignored for all other methods 1500 defined by this specification and for any extension methods for which 1501 it is not explicitly referred to as part of that method definition. 1503 10.6. Referer 1505 The request-header field "Referer" [sic] allows the client to 1506 specify, for the server's benefit, the address (URI) of the resource 1507 from which the Request-URI was obtained (the "referrer", although the 1508 header field is misspelled.) The Referer request-header allows a 1509 server to generate lists of back-links to resources for interest, 1510 logging, optimized caching, etc. It also allows obsolete or mistyped 1511 links to be traced for maintenance. The Referer field MUST NOT be 1512 sent if the Request-URI was obtained from a source that does not have 1513 its own URI, such as input from the user keyboard. 1515 Referer = "Referer" ":" OWS Referer-v 1516 Referer-v = absolute-URI / relativeURI 1518 Example: 1520 Referer: http://www.example.org/hypertext/Overview.html 1522 If the field value is a relative URI, it SHOULD be interpreted 1523 relative to the Request-URI. The URI MUST NOT include a fragment. 1524 See Section 12.2 for security considerations. 1526 10.7. Retry-After 1528 The response-header "Retry-After" field can be used with a 503 1529 (Service Unavailable) response to indicate how long the service is 1530 expected to be unavailable to the requesting client. This field MAY 1531 also be used with any 3xx (Redirection) response to indicate the 1532 minimum time the user-agent is asked wait before issuing the 1533 redirected request. The value of this field can be either an HTTP- 1534 date or an integer number of seconds (in decimal) after the time of 1535 the response. 1537 Retry-After = "Retry-After" ":" OWS Retry-After-v 1538 Retry-After-v = HTTP-date / delta-seconds 1540 Time spans are non-negative decimal integers, representing time in 1541 seconds. 1543 delta-seconds = 1*DIGIT 1545 Two examples of its use are 1547 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 1548 Retry-After: 120 1550 In the latter example, the delay is 2 minutes. 1552 10.8. Server 1554 The response-header field "Server" contains information about the 1555 software used by the origin server to handle the request. The field 1556 can contain multiple product tokens (Section 3.5 of [Part1]) and 1557 comments identifying the server and any significant subproducts. The 1558 product tokens are listed in order of their significance for 1559 identifying the application. 1561 Server = "Server" ":" OWS Server-v 1562 Server-v = product 1563 *( RWS ( product / comment ) ) 1565 Example: 1567 Server: CERN/3.0 libwww/2.17 1569 If the response is being forwarded through a proxy, the proxy 1570 application MUST NOT modify the Server response-header. Instead, it 1571 MUST include a Via field (as described in Section 8.9 of [Part1]). 1573 Note: Revealing the specific software version of the server might 1574 allow the server machine to become more vulnerable to attacks 1575 against software that is known to contain security holes. Server 1576 implementors are encouraged to make this field a configurable 1577 option. 1579 10.9. User-Agent 1581 The request-header field "User-Agent" contains information about the 1582 user agent originating the request. This is for statistical 1583 purposes, the tracing of protocol violations, and automated 1584 recognition of user agents for the sake of tailoring responses to 1585 avoid particular user agent limitations. User agents SHOULD include 1586 this field with requests. The field can contain multiple product 1587 tokens (Section 3.5 of [Part1]) and comments identifying the agent 1588 and any subproducts which form a significant part of the user agent. 1589 By convention, the product tokens are listed in order of their 1590 significance for identifying the application. 1592 User-Agent = "User-Agent" ":" OWS User-Agent-v 1593 User-Agent-v = product 1594 *( RWS ( product / comment ) ) 1596 Example: 1598 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1600 11. IANA Considerations 1602 11.1. Method Registry 1604 The registration procedure for HTTP Methods is defined by Section 3.1 1605 of this document. 1607 The HTTP Method Registry located at 1608 should be populated 1609 with the registrations below: 1611 +---------+------+-------------+ 1612 | Method | Safe | Reference | 1613 +---------+------+-------------+ 1614 | CONNECT | no | Section 8.9 | 1615 | DELETE | no | Section 8.7 | 1616 | GET | yes | Section 8.3 | 1617 | HEAD | yes | Section 8.4 | 1618 | OPTIONS | yes | Section 8.2 | 1619 | POST | no | Section 8.5 | 1620 | PUT | no | Section 8.6 | 1621 | TRACE | yes | Section 8.8 | 1622 +---------+------+-------------+ 1624 11.2. Status Code Registry 1626 The registration procedure for HTTP Status Codes -- previously 1627 defined in Section 7.1 of [RFC2817] -- is now defined by Section 5.1 1628 of this document. 1630 The HTTP Status Code Registry located at 1631 should be updated 1632 with the registrations below: 1634 +-------+---------------------------------+----------------+ 1635 | Value | Description | Reference | 1636 +-------+---------------------------------+----------------+ 1637 | 100 | Continue | Section 9.1.1 | 1638 | 101 | Switching Protocols | Section 9.1.2 | 1639 | 200 | OK | Section 9.2.1 | 1640 | 201 | Created | Section 9.2.2 | 1641 | 202 | Accepted | Section 9.2.3 | 1642 | 203 | Non-Authoritative Information | Section 9.2.4 | 1643 | 204 | No Content | Section 9.2.5 | 1644 | 205 | Reset Content | Section 9.2.6 | 1645 | 206 | Partial Content | Section 9.2.7 | 1646 | 300 | Multiple Choices | Section 9.3.1 | 1647 | 301 | Moved Permanently | Section 9.3.2 | 1648 | 302 | Found | Section 9.3.3 | 1649 | 303 | See Other | Section 9.3.4 | 1650 | 304 | Not Modified | Section 9.3.5 | 1651 | 305 | Use Proxy | Section 9.3.6 | 1652 | 306 | (Unused) | Section 9.3.7 | 1653 | 307 | Temporary Redirect | Section 9.3.8 | 1654 | 400 | Bad Request | Section 9.4.1 | 1655 | 401 | Unauthorized | Section 9.4.2 | 1656 | 402 | Payment Required | Section 9.4.3 | 1657 | 403 | Forbidden | Section 9.4.4 | 1658 | 404 | Not Found | Section 9.4.5 | 1659 | 405 | Method Not Allowed | Section 9.4.6 | 1660 | 406 | Not Acceptable | Section 9.4.7 | 1661 | 407 | Proxy Authentication Required | Section 9.4.8 | 1662 | 408 | Request Timeout | Section 9.4.9 | 1663 | 409 | Conflict | Section 9.4.10 | 1664 | 410 | Gone | Section 9.4.11 | 1665 | 411 | Length Required | Section 9.4.12 | 1666 | 412 | Precondition Failed | Section 9.4.13 | 1667 | 413 | Request Entity Too Large | Section 9.4.14 | 1668 | 414 | Request-URI Too Long | Section 9.4.15 | 1669 | 415 | Unsupported Media Type | Section 9.4.16 | 1670 | 416 | Requested Range Not Satisfiable | Section 9.4.17 | 1671 | 417 | Expectation Failed | Section 9.4.18 | 1672 | 500 | Internal Server Error | Section 9.5.1 | 1673 | 501 | Not Implemented | Section 9.5.2 | 1674 | 502 | Bad Gateway | Section 9.5.3 | 1675 | 503 | Service Unavailable | Section 9.5.4 | 1676 | 504 | Gateway Timeout | Section 9.5.5 | 1677 | 505 | HTTP Version Not Supported | Section 9.5.6 | 1678 +-------+---------------------------------+----------------+ 1680 11.3. Message Header Registration 1682 The Message Header Registry located at should be 1684 updated with the permanent registrations below (see [RFC3864]): 1686 +-------------------+----------+----------+--------------+ 1687 | Header Field Name | Protocol | Status | Reference | 1688 +-------------------+----------+----------+--------------+ 1689 | Allow | http | standard | Section 10.1 | 1690 | Expect | http | standard | Section 10.2 | 1691 | From | http | standard | Section 10.3 | 1692 | Location | http | standard | Section 10.4 | 1693 | Max-Forwards | http | standard | Section 10.5 | 1694 | Referer | http | standard | Section 10.6 | 1695 | Retry-After | http | standard | Section 10.7 | 1696 | Server | http | standard | Section 10.8 | 1697 | User-Agent | http | standard | Section 10.9 | 1698 +-------------------+----------+----------+--------------+ 1700 The change controller is: "IETF (iesg@ietf.org) - Internet 1701 Engineering Task Force". 1703 12. Security Considerations 1705 This section is meant to inform application developers, information 1706 providers, and users of the security limitations in HTTP/1.1 as 1707 described by this document. The discussion does not include 1708 definitive solutions to the problems revealed, though it does make 1709 some suggestions for reducing security risks. 1711 12.1. Transfer of Sensitive Information 1713 Like any generic data transfer protocol, HTTP cannot regulate the 1714 content of the data that is transferred, nor is there any a priori 1715 method of determining the sensitivity of any particular piece of 1716 information within the context of any given request. Therefore, 1717 applications SHOULD supply as much control over this information as 1718 possible to the provider of that information. Four header fields are 1719 worth special mention in this context: Server, Via, Referer and From. 1721 Revealing the specific software version of the server might allow the 1722 server machine to become more vulnerable to attacks against software 1723 that is known to contain security holes. Implementors SHOULD make 1724 the Server header field a configurable option. 1726 Proxies which serve as a portal through a network firewall SHOULD 1727 take special precautions regarding the transfer of header information 1728 that identifies the hosts behind the firewall. In particular, they 1729 SHOULD remove, or replace with sanitized versions, any Via fields 1730 generated behind the firewall. 1732 The Referer header allows reading patterns to be studied and reverse 1733 links drawn. Although it can be very useful, its power can be abused 1734 if user details are not separated from the information contained in 1735 the Referer. Even when the personal information has been removed, 1736 the Referer header might indicate a private document's URI whose 1737 publication would be inappropriate. 1739 The information sent in the From field might conflict with the user's 1740 privacy interests or their site's security policy, and hence it 1741 SHOULD NOT be transmitted without the user being able to disable, 1742 enable, and modify the contents of the field. The user MUST be able 1743 to set the contents of this field within a user preference or 1744 application defaults configuration. 1746 We suggest, though do not require, that a convenient toggle interface 1747 be provided for the user to enable or disable the sending of From and 1748 Referer information. 1750 The User-Agent (Section 10.9) or Server (Section 10.8) header fields 1751 can sometimes be used to determine that a specific client or server 1752 have a particular security hole which might be exploited. 1753 Unfortunately, this same information is often used for other valuable 1754 purposes for which HTTP currently has no better mechanism. 1756 12.2. Encoding Sensitive Information in URIs 1758 Because the source of a link might be private information or might 1759 reveal an otherwise private information source, it is strongly 1760 recommended that the user be able to select whether or not the 1761 Referer field is sent. For example, a browser client could have a 1762 toggle switch for browsing openly/anonymously, which would 1763 respectively enable/disable the sending of Referer and From 1764 information. 1766 Clients SHOULD NOT include a Referer header field in a (non-secure) 1767 HTTP request if the referring page was transferred with a secure 1768 protocol. 1770 Authors of services should not use GET-based forms for the submission 1771 of sensitive data because that data will be encoded in the Request- 1772 URI. Many existing servers, proxies, and user agents log or display 1773 the Request-URI in places where it might be visible to third parties. 1774 Such services can use POST-based form submission instead. 1776 12.3. Location Headers and Spoofing 1778 If a single server supports multiple organizations that do not trust 1779 one another, then it MUST check the values of Location and Content- 1780 Location headers in responses that are generated under control of 1781 said organizations to make sure that they do not attempt to 1782 invalidate resources over which they have no authority. 1784 13. Acknowledgments 1786 14. References 1788 14.1. Normative References 1790 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1791 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1792 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 1793 and Message Parsing", draft-ietf-httpbis-p1-messaging-05 1794 (work in progress), November 2008. 1796 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1797 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1798 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 1799 and Content Negotiation", draft-ietf-httpbis-p3-payload-05 1800 (work in progress), November 2008. 1802 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1803 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1804 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 1805 Requests", draft-ietf-httpbis-p4-conditional-05 (work in 1806 progress), November 2008. 1808 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1809 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1810 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 1811 Partial Responses", draft-ietf-httpbis-p5-range-05 (work 1812 in progress), November 2008. 1814 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1815 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1816 and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", 1817 draft-ietf-httpbis-p6-cache-05 (work in progress), 1818 November 2008. 1820 [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1821 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1822 and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", 1823 draft-ietf-httpbis-p7-auth-05 (work in progress), 1824 November 2008. 1826 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1827 Requirement Levels", BCP 14, RFC 2119, March 1997. 1829 14.2. Informative References 1831 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1832 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1834 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 1835 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 1836 RFC 2068, January 1997. 1838 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1839 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1840 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1842 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 1843 HTTP/1.1", RFC 2817, May 2000. 1845 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1846 Procedures for Message Header Fields", BCP 90, RFC 3864, 1847 September 2004. 1849 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1850 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1851 May 2008. 1853 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 1854 October 2008. 1856 Appendix A. Compatibility with Previous Versions 1858 A.1. Changes from RFC 2068 1860 Clarified which error code should be used for inbound server failures 1861 (e.g. DNS failures). (Section 9.5.5). 1863 201 (Created) had a race that required an Etag be sent when a 1864 resource is first created. (Section 9.2.2). 1866 Rewrite of message transmission requirements to make it much harder 1867 for implementors to get it wrong, as the consequences of errors here 1868 can have significant impact on the Internet, and to deal with the 1869 following problems: 1871 1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where 1872 this was incorrectly placing a requirement on the behavior of an 1873 implementation of a future version of HTTP/1.x 1875 2. Made it clear that user-agents should retry requests, not 1876 "clients" in general. 1878 3. Converted requirements for clients to ignore unexpected 100 1879 (Continue) responses, and for proxies to forward 100 responses, 1880 into a general requirement for 1xx responses. 1882 4. Modified some TCP-specific language, to make it clearer that non- 1883 TCP transports are possible for HTTP. 1885 5. Require that the origin server MUST NOT wait for the request body 1886 before it sends a required 100 (Continue) response. 1888 6. Allow, rather than require, a server to omit 100 (Continue) if it 1889 has already seen some of the request body. 1891 7. Allow servers to defend against denial-of-service attacks and 1892 broken clients. 1894 This change adds the Expect header and 417 status code. 1896 Clean up confusion between 403 and 404 responses. (Section 9.4.4, 1897 9.4.5, and 9.4.11) 1899 The PATCH, LINK, UNLINK methods were defined but not commonly 1900 implemented in previous versions of this specification. See Section 1901 19.6.1 of [RFC2068]. 1903 A.2. Changes from RFC 2616 1905 This document takes over the Status Code Registry, previously defined 1906 in Section 7.1 of [RFC2817]. (Section 5.1) 1908 Clarify definition of POST. (Section 8.5) 1910 Failed to consider that there are many other request methods that are 1911 safe to automatically redirect, and further that the user agent is 1912 able to make that determination based on the request method 1913 semantics. (Sections 9.3.2, 9.3.3 and 9.3.8) 1915 Deprecate 305 Use Proxy status code, because user agents did not 1916 implement it. It used to indicate that the requested resource must 1917 be accessed through the proxy given by the Location field. The 1918 Location field gave the URI of the proxy. The recipient was expected 1919 to repeat this single request via the proxy. (Section 9.3.6) 1921 Reclassify Allow header as response header, removing the option to 1922 specify it in a PUT request. Relax the server requirement on the 1923 contents of the Allow header and remove requirement on clients to 1924 always trust the header value. (Section 10.1) 1926 Correct syntax of Location header to allow fragment, as referred 1927 symbol wasn't what was expected, and add some clarifications as to 1928 when it would not be appropriate. (Section 10.4) 1930 In the description of the Server header, the Via field was described 1931 as a SHOULD. The requirement was and is stated correctly in the 1932 description of the Via header in Section 8.9 of [Part1]. 1933 (Section 10.8) 1935 Appendix B. Change Log (to be removed by RFC Editor before publication) 1937 B.1. Since RFC2616 1939 Extracted relevant partitions from [RFC2616]. 1941 B.2. Since draft-ietf-httpbis-p2-semantics-00 1943 Closed issues: 1945 o : "Via is a MUST" 1946 () 1948 o : "Fragments 1949 allowed in Location" 1950 () 1952 o : "Safe Methods 1953 vs Redirection" () 1955 o : "Revise 1956 description of the POST method" 1957 () 1959 o : "Normative and 1960 Informative references" 1962 o : "RFC2606 1963 Compliance" 1965 o : "Informative 1966 references" 1968 o : "Redundant 1969 cross-references" 1971 Other changes: 1973 o Move definitions of 304 and 412 condition codes to [Part4] 1975 B.3. Since draft-ietf-httpbis-p2-semantics-01 1977 Closed issues: 1979 o : "PUT side 1980 effects" 1982 o : "Duplicate Host 1983 header requirements" 1985 Ongoing work on ABNF conversion 1986 (): 1988 o Move "Product Tokens" section (back) into Part 1, as "token" is 1989 used in the definition of the Upgrade header. 1991 o Add explicit references to BNF syntax and rules imported from 1992 other parts of the specification. 1994 o Copy definition of delta-seconds from Part6 instead of referencing 1995 it. 1997 B.4. Since draft-ietf-httpbis-p2-semantics-02 1999 Closed issues: 2001 o : "Requiring 2002 Allow in 405 responses" 2004 o : "Status Code 2005 Registry" 2007 o : "Redirection 2008 vs. Location" 2010 o : "Cacheability 2011 of 303 response" 2013 o : "305 Use Proxy" 2015 o : 2016 "Classification for Allow header" 2018 o : "PUT - 'store 2019 under' vs 'store at'" 2021 Ongoing work on IANA Message Header Registration 2022 (): 2024 o Reference RFC 3984, and update header registrations for headers 2025 defined in this document. 2027 Ongoing work on ABNF conversion 2028 (): 2030 o Replace string literals when the string really is case-sensitive 2031 (method). 2033 B.5. Since draft-ietf-httpbis-p2-semantics-03 2035 Closed issues: 2037 o : "OPTIONS 2038 request bodies" 2040 o : "Description 2041 of CONNECT should refer to RFC2817" 2043 o : "Location 2044 Content-Location reference request/response mixup" 2046 Ongoing work on Method Registry 2047 (): 2049 o Added initial proposal for registration process, plus initial 2050 content (non-HTTP/1.1 methods to be added by a separate 2051 specification). 2053 B.6. Since draft-ietf-httpbis-p2-semantics-04 2055 Closed issues: 2057 o : "Content-*" 2059 o : "RFC 2822 is 2060 updated by RFC 5322" 2062 Ongoing work on ABNF conversion 2063 (): 2065 o Use "/" instead of "|" for alternatives. 2067 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 2068 whitespace ("OWS") and required whitespace ("RWS"). 2070 o Rewrite ABNFs to spell out whitespace rules, factor out header 2071 value format definitions. 2073 Index 2075 1 2076 100 Continue (status code) 19 2077 101 Switching Protocols (status code) 20 2079 2 2080 200 OK (status code) 20 2081 201 Created (status code) 20 2082 202 Accepted (status code) 21 2083 203 Non-Authoritative Information (status code) 21 2084 204 No Content (status code) 21 2085 205 Reset Content (status code) 22 2086 206 Partial Content (status code) 22 2088 3 2089 300 Multiple Choices (status code) 22 2090 301 Moved Permanently (status code) 23 2091 302 Found (status code) 23 2092 303 See Other (status code) 24 2093 304 Not Modified (status code) 25 2094 305 Use Proxy (status code) 25 2095 306 (Unused) (status code) 25 2096 307 Temporary Redirect (status code) 25 2098 4 2099 400 Bad Request (status code) 26 2100 401 Unauthorized (status code) 26 2101 402 Payment Required (status code) 26 2102 403 Forbidden (status code) 26 2103 404 Not Found (status code) 26 2104 405 Method Not Allowed (status code) 27 2105 406 Not Acceptable (status code) 27 2106 407 Proxy Authentication Required (status code) 27 2107 408 Request Timeout (status code) 27 2108 409 Conflict (status code) 27 2109 410 Gone (status code) 28 2110 411 Length Required (status code) 28 2111 412 Precondition Failed (status code) 28 2112 413 Request Entity Too Large (status code) 29 2113 414 Request-URI Too Long (status code) 29 2114 415 Unsupported Media Type (status code) 29 2115 416 Requested Range Not Satisfiable (status code) 29 2116 417 Expectation Failed (status code) 29 2118 5 2119 500 Internal Server Error (status code) 30 2120 501 Not Implemented (status code) 30 2121 502 Bad Gateway (status code) 30 2122 503 Service Unavailable (status code) 30 2123 504 Gateway Timeout (status code) 30 2124 505 HTTP Version Not Supported (status code) 31 2126 A 2127 Allow header 31 2129 C 2130 CONNECT method 19 2132 D 2133 DELETE method 18 2135 E 2136 Expect header 31 2138 F 2139 From header 32 2141 G 2142 GET method 15 2143 Grammar 2144 Allow 31 2145 Allow-v 31 2146 delta-seconds 35 2147 Expect 32 2148 expect-params 32 2149 Expect-v 32 2150 expectation 32 2151 expectation-extension 32 2152 extension-code 11 2153 extension-method 8 2154 From 32 2155 From-v 32 2156 Location 33 2157 Location-v 33 2158 Max-Forwards 34 2159 Max-Forwards-v 34 2160 Method 8 2161 Reason-Phrase 11 2162 Referer 35 2163 Referer-v 35 2164 request-header 9 2165 response-header 12 2166 Retry-After 35 2167 Retry-After-v 35 2168 Server 36 2169 Server-v 36 2170 Status-Code 11 2171 User-Agent 36 2172 User-Agent-v 36 2174 H 2175 HEAD method 16 2176 Headers 2177 Allow 31 2178 Expect 31 2179 From 32 2180 Location 33 2181 Max-Forwards 34 2182 Referer 34 2183 Retry-After 35 2184 Server 35 2185 User-Agent 36 2187 I 2188 Idempotent Methods 14 2190 L 2191 LINK method 43 2192 Location header 33 2194 M 2195 Max-Forwards header 34 2196 Methods 2197 CONNECT 19 2198 DELETE 18 2199 GET 15 2200 HEAD 16 2201 LINK 43 2202 OPTIONS 14 2203 PATCH 43 2204 POST 16 2205 PUT 17 2206 TRACE 18 2207 UNLINK 43 2209 O 2210 OPTIONS method 14 2212 P 2213 PATCH method 43 2214 POST method 16 2215 PUT method 17 2217 R 2218 Referer header 34 2219 Retry-After header 35 2221 S 2222 Safe Methods 13 2223 Server header 35 2224 Status Codes 2225 100 Continue 19 2226 101 Switching Protocols 20 2227 200 OK 20 2228 201 Created 20 2229 202 Accepted 21 2230 203 Non-Authoritative Information 21 2231 204 No Content 21 2232 205 Reset Content 22 2233 206 Partial Content 22 2234 300 Multiple Choices 22 2235 301 Moved Permanently 23 2236 302 Found 23 2237 303 See Other 24 2238 304 Not Modified 25 2239 305 Use Proxy 25 2240 306 (Unused) 25 2241 307 Temporary Redirect 25 2242 400 Bad Request 26 2243 401 Unauthorized 26 2244 402 Payment Required 26 2245 403 Forbidden 26 2246 404 Not Found 26 2247 405 Method Not Allowed 27 2248 406 Not Acceptable 27 2249 407 Proxy Authentication Required 27 2250 408 Request Timeout 27 2251 409 Conflict 27 2252 410 Gone 28 2253 411 Length Required 28 2254 412 Precondition Failed 28 2255 413 Request Entity Too Large 29 2256 414 Request-URI Too Long 29 2257 415 Unsupported Media Type 29 2258 416 Requested Range Not Satisfiable 29 2259 417 Expectation Failed 29 2260 500 Internal Server Error 30 2261 501 Not Implemented 30 2262 502 Bad Gateway 30 2263 503 Service Unavailable 30 2264 504 Gateway Timeout 30 2265 505 HTTP Version Not Supported 31 2267 T 2268 TRACE method 18 2270 U 2271 UNLINK method 43 2272 User-Agent header 36 2274 Authors' Addresses 2276 Roy T. Fielding (editor) 2277 Day Software 2278 23 Corporate Plaza DR, Suite 280 2279 Newport Beach, CA 92660 2280 USA 2282 Phone: +1-949-706-5300 2283 Fax: +1-949-706-5305 2284 Email: fielding@gbiv.com 2285 URI: http://roy.gbiv.com/ 2287 Jim Gettys 2288 One Laptop per Child 2289 21 Oak Knoll Road 2290 Carlisle, MA 01741 2291 USA 2293 Email: jg@laptop.org 2294 URI: http://www.laptop.org/ 2295 Jeffrey C. Mogul 2296 Hewlett-Packard Company 2297 HP Labs, Large Scale Systems Group 2298 1501 Page Mill Road, MS 1177 2299 Palo Alto, CA 94304 2300 USA 2302 Email: JeffMogul@acm.org 2304 Henrik Frystyk Nielsen 2305 Microsoft Corporation 2306 1 Microsoft Way 2307 Redmond, WA 98052 2308 USA 2310 Email: henrikn@microsoft.com 2312 Larry Masinter 2313 Adobe Systems, Incorporated 2314 345 Park Ave 2315 San Jose, CA 95110 2316 USA 2318 Email: LMM@acm.org 2319 URI: http://larry.masinter.net/ 2321 Paul J. Leach 2322 Microsoft Corporation 2323 1 Microsoft Way 2324 Redmond, WA 98052 2326 Email: paulle@microsoft.com 2328 Tim Berners-Lee 2329 World Wide Web Consortium 2330 MIT Computer Science and Artificial Intelligence Laboratory 2331 The Stata Center, Building 32 2332 32 Vassar Street 2333 Cambridge, MA 02139 2334 USA 2336 Email: timbl@w3.org 2337 URI: http://www.w3.org/People/Berners-Lee/ 2338 Yves Lafon (editor) 2339 World Wide Web Consortium 2340 W3C / ERCIM 2341 2004, rte des Lucioles 2342 Sophia-Antipolis, AM 06902 2343 France 2345 Email: ylafon@w3.org 2346 URI: http://www.raubacapeu.net/people/yves/ 2348 Julian F. Reschke (editor) 2349 greenbytes GmbH 2350 Hafenweg 16 2351 Muenster, NW 48155 2352 Germany 2354 Phone: +49 251 2807760 2355 Fax: +49 251 2807761 2356 Email: julian.reschke@greenbytes.de 2357 URI: http://greenbytes.de/tech/webdav/ 2359 Full Copyright Statement 2361 Copyright (C) The IETF Trust (2008). 2363 This document is subject to the rights, licenses and restrictions 2364 contained in BCP 78, and except as set forth therein, the authors 2365 retain all their rights. 2367 This document and the information contained herein are provided on an 2368 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2369 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2370 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2371 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2372 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2373 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2375 Intellectual Property 2377 The IETF takes no position regarding the validity or scope of any 2378 Intellectual Property Rights or other rights that might be claimed to 2379 pertain to the implementation or use of the technology described in 2380 this document or the extent to which any license under such rights 2381 might or might not be available; nor does it represent that it has 2382 made any independent effort to identify any such rights. Information 2383 on the procedures with respect to rights in RFC documents can be 2384 found in BCP 78 and BCP 79. 2386 Copies of IPR disclosures made to the IETF Secretariat and any 2387 assurances of licenses to be made available, or the result of an 2388 attempt made to obtain a general license or permission for the use of 2389 such proprietary rights by implementers or users of this 2390 specification can be obtained from the IETF on-line IPR repository at 2391 http://www.ietf.org/ipr. 2393 The IETF invites any interested party to bring to its attention any 2394 copyrights, patents or patent applications, or other proprietary 2395 rights that may cover technology that may be required to implement 2396 this standard. Please address the information to the IETF at 2397 ietf-ipr@ietf.org.