idnits 2.17.1 draft-ietf-httpbis-p2-semantics-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2009) is 5399 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-07 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-07 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-07 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-07 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-07 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-07 -- 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 (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis 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: January 14, 2010 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 July 13, 2009 22 HTTP/1.1, part 2: Message Semantics 23 draft-ietf-httpbis-p2-semantics-07 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. This document may contain material 29 from IETF Documents or IETF Contributions published or made publicly 30 available before November 10, 2008. The person(s) controlling the 31 copyright in some of this material may not have granted the IETF 32 Trust the right to allow modifications of such material outside the 33 IETF Standards Process. Without obtaining an adequate license from 34 the person(s) controlling the copyright in such materials, this 35 document may not be modified outside the IETF Standards Process, and 36 derivative works of it may not be created outside the IETF Standards 37 Process, except to format it for publication as an RFC or to 38 translate it into languages other than English. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 This Internet-Draft will expire on January 14, 2010. 57 Copyright Notice 59 Copyright (c) 2009 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents in effect on the date of 64 publication of this document (http://trustee.ietf.org/license-info). 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. 68 Abstract 70 The Hypertext Transfer Protocol (HTTP) is an application-level 71 protocol for distributed, collaborative, hypermedia information 72 systems. HTTP has been in use by the World Wide Web global 73 information initiative since 1990. This document is Part 2 of the 74 seven-part specification that defines the protocol referred to as 75 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines 76 the semantics of HTTP messages as expressed by request methods, 77 request-header fields, response status codes, and response-header 78 fields. 80 Editorial Note (To be removed by RFC Editor) 82 Discussion of this draft should take place on the HTTPBIS working 83 group mailing list (ietf-http-wg@w3.org). The current issues list is 84 at and related 85 documents (including fancy diffs) can be found at 86 . 88 The changes in this draft are summarized in Appendix C.8. 90 Table of Contents 92 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 93 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 94 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 95 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 96 1.2.2. ABNF Rules defined in other Parts of the 97 Specification . . . . . . . . . . . . . . . . . . . . 7 98 2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 99 2.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 8 100 3. Request Header Fields . . . . . . . . . . . . . . . . . . . . 9 101 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 10 102 4.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 12 103 5. Response Header Fields . . . . . . . . . . . . . . . . . . . . 12 104 6. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 105 7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 13 106 7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 13 107 7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 13 108 7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 14 109 7.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 14 110 7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 111 7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 112 7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 113 7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 114 7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 18 115 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 18 116 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 19 117 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 19 118 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 19 119 8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 20 120 8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 20 121 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 20 122 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 20 123 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 21 124 8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 21 125 8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 21 126 8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 22 127 8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 22 128 8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 22 129 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 22 130 8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 23 131 8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 23 132 8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 24 133 8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 24 134 8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 25 135 8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 25 136 8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 25 137 8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 25 139 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 26 140 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 26 141 8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 26 142 8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 26 143 8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 26 144 8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 27 145 8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 27 146 8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 27 147 8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 27 148 8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 28 149 8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 28 150 8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 28 151 8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 29 152 8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 29 153 8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 29 154 8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 29 155 8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 29 156 8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 29 157 8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 30 158 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 30 159 8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 30 160 8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 30 161 8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 30 162 8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 30 163 8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 31 164 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 31 165 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 31 166 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 31 167 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 32 168 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 169 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 33 170 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 34 171 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 35 172 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 35 173 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 36 174 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 36 175 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 176 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 37 177 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 37 178 10.3. Message Header Registration . . . . . . . . . . . . . . . 39 179 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 180 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 39 181 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 40 182 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 41 183 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 184 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 185 13.1. Normative References . . . . . . . . . . . . . . . . . . . 41 186 13.2. Informative References . . . . . . . . . . . . . . . . . . 42 188 Appendix A. Compatibility with Previous Versions . . . . . . . . 42 189 A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 42 190 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 43 191 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 44 192 Appendix C. Change Log (to be removed by RFC Editor before 193 publication) . . . . . . . . . . . . . . . . . . . . 47 194 C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 47 195 C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 47 196 C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 48 197 C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 48 198 C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 49 199 C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 49 200 C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 50 201 C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 50 202 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 203 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 205 1. Introduction 207 This document defines HTTP/1.1 request and response semantics. Each 208 HTTP message, as defined in [Part1], is in the form of either a 209 request or a response. An HTTP server listens on a connection for 210 HTTP requests and responds to each request, in the order received on 211 that connection, with one or more HTTP response messages. This 212 document defines the commonly agreed upon semantics of the HTTP 213 uniform interface, the intentions defined by each request method, and 214 the various response messages that might be expected as a result of 215 applying that method for the requested resource. 217 This document is currently disorganized in order to minimize the 218 changes between drafts and enable reviewers to see the smaller errata 219 changes. The next draft will reorganize the sections to better 220 reflect the content. In particular, the sections will be ordered 221 according to the typical processing of an HTTP request message (after 222 message parsing): resource mapping, general header fields, methods, 223 request modifiers, response status, and resource metadata. The 224 current mess reflects how widely dispersed these topics and 225 associated requirements had become in [RFC2616]. 227 1.1. Requirements 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 231 document are to be interpreted as described in [RFC2119]. 233 An implementation is not compliant if it fails to satisfy one or more 234 of the MUST or REQUIRED level requirements for the protocols it 235 implements. An implementation that satisfies all the MUST or 236 REQUIRED level and all the SHOULD level requirements for its 237 protocols is said to be "unconditionally compliant"; one that 238 satisfies all the MUST level requirements but not all the SHOULD 239 level requirements for its protocols is said to be "conditionally 240 compliant." 242 1.2. Syntax Notation 244 This specification uses the ABNF syntax defined in Section 1.2 of 245 [Part1] (which extends the syntax defined in [RFC5234] with a list 246 rule). Appendix B shows the collected ABNF, with the list rule 247 expanded. 249 The following core rules are included by reference, as defined in 250 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 251 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 252 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 253 sequence of data), SP (space), VCHAR (any visible USASCII character), 254 and WSP (whitespace). 256 1.2.1. Core Rules 258 The core rules below are defined in Section 1.2.2 of [Part1]: 260 comment = 261 quoted-string = 262 token = 263 OWS = 264 RWS = 265 obs-text = 267 1.2.2. ABNF Rules defined in other Parts of the Specification 269 The ABNF rules below are defined in other parts: 271 absolute-URI = 272 fragment = 273 Host = 274 HTTP-date = 275 partial-URI = 276 product = 277 TE = 279 Accept = 280 Accept-Charset = 281 282 Accept-Encoding = 283 284 Accept-Language = 285 287 ETag = 288 If-Match = 289 If-Modified-Since = 290 291 If-None-Match = 292 If-Unmodified-Since = 293 295 Accept-Ranges = 296 If-Range = 297 Range = 298 Age = 299 Vary = 301 Authorization = 302 Proxy-Authenticate = 303 304 Proxy-Authorization = 305 306 WWW-Authenticate = 307 309 2. Method 311 The Method token indicates the method to be performed on the resource 312 identified by the request-target. The method is case-sensitive. 314 Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 7.2 315 / %x47.45.54 ; "GET", Section 7.3 316 / %x48.45.41.44 ; "HEAD", Section 7.4 317 / %x50.4F.53.54 ; "POST", Section 7.5 318 / %x50.55.54 ; "PUT", Section 7.6 319 / %x44.45.4C.45.54.45 ; "DELETE", Section 7.7 320 / %x54.52.41.43.45 ; "TRACE", Section 7.8 321 / %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 7.9 322 / extension-method 323 extension-method = token 325 The list of methods allowed by a resource can be specified in an 326 Allow header field (Section 9.1). The return code of the response 327 always notifies the client whether a method is currently allowed on a 328 resource, since the set of allowed methods can change dynamically. 329 An origin server SHOULD return the status code 405 (Method Not 330 Allowed) if the method is known by the origin server but not allowed 331 for the requested resource, and 501 (Not Implemented) if the method 332 is unrecognized or not implemented by the origin server. The methods 333 GET and HEAD MUST be supported by all general-purpose servers. All 334 other methods are OPTIONAL; however, if the above methods are 335 implemented, they MUST be implemented with the same semantics as 336 those specified in Section 7. 338 2.1. Method Registry 340 The HTTP Method Registry defines the name space for the Method token 341 in the Request line of an HTTP request. 343 Registrations MUST include the following fields: 345 o Method Name (see Section 2) 347 o Safe ("yes" or "no", see Section 7.1.1) 349 o Pointer to specification text 351 Values to be added to this name space are subject to IETF review 352 ([RFC5226], Section 4.1). 354 The registry itself is maintained at 355 . 357 3. Request Header Fields 359 The request-header fields allow the client to pass additional 360 information about the request, and about the client itself, to the 361 server. These fields act as request modifiers, with semantics 362 equivalent to the parameters on a programming language method 363 invocation. 365 request-header = Accept ; [Part3], Section 5.1 366 / Accept-Charset ; [Part3], Section 5.2 367 / Accept-Encoding ; [Part3], Section 5.3 368 / Accept-Language ; [Part3], Section 5.4 369 / Authorization ; [Part7], Section 3.1 370 / Expect ; Section 9.2 371 / From ; Section 9.3 372 / Host ; [Part1], Section 8.4 373 / If-Match ; [Part4], Section 6.2 374 / If-Modified-Since ; [Part4], Section 6.3 375 / If-None-Match ; [Part4], Section 6.4 376 / If-Range ; [Part5], Section 5.3 377 / If-Unmodified-Since ; [Part4], Section 6.5 378 / Max-Forwards ; Section 9.5 379 / Proxy-Authorization ; [Part7], Section 3.3 380 / Range ; [Part5], Section 5.4 381 / Referer ; Section 9.6 382 / TE ; [Part1], Section 8.8 383 / User-Agent ; Section 9.9 385 Request-header field names can be extended reliably only in 386 combination with a change in the protocol version. However, new or 387 experimental header fields MAY be given the semantics of request- 388 header fields if all parties in the communication recognize them to 389 be request-header fields. Unrecognized header fields are treated as 390 entity-header fields. 392 4. Status Code and Reason Phrase 394 The Status-Code element is a 3-digit integer result code of the 395 attempt to understand and satisfy the request. The status codes 396 listed below are defined in Section 8. The Reason-Phrase is intended 397 to give a short textual description of the Status-Code. The Status- 398 Code is intended for use by automata and the Reason-Phrase is 399 intended for the human user. The client is not required to examine 400 or display the Reason-Phrase. 402 The individual values of the numeric status codes defined for 403 HTTP/1.1, and an example set of corresponding Reason-Phrase's, are 404 presented below. The reason phrases listed here are only 405 recommendations -- they MAY be replaced by local equivalents without 406 affecting the protocol. 408 Status-Code = 409 "100" ; Section 8.1.1: Continue 410 / "101" ; Section 8.1.2: Switching Protocols 411 / "200" ; Section 8.2.1: OK 412 / "201" ; Section 8.2.2: Created 413 / "202" ; Section 8.2.3: Accepted 414 / "203" ; Section 8.2.4: Non-Authoritative Information 415 / "204" ; Section 8.2.5: No Content 416 / "205" ; Section 8.2.6: Reset Content 417 / "206" ; Section 8.2.7: Partial Content 418 / "300" ; Section 8.3.1: Multiple Choices 419 / "301" ; Section 8.3.2: Moved Permanently 420 / "302" ; Section 8.3.3: Found 421 / "303" ; Section 8.3.4: See Other 422 / "304" ; Section 8.3.5: Not Modified 423 / "305" ; Section 8.3.6: Use Proxy 424 / "307" ; Section 8.3.8: Temporary Redirect 425 / "400" ; Section 8.4.1: Bad Request 426 / "401" ; Section 8.4.2: Unauthorized 427 / "402" ; Section 8.4.3: Payment Required 428 / "403" ; Section 8.4.4: Forbidden 429 / "404" ; Section 8.4.5: Not Found 430 / "405" ; Section 8.4.6: Method Not Allowed 431 / "406" ; Section 8.4.7: Not Acceptable 432 / "407" ; Section 8.4.8: Proxy Authentication Required 433 / "408" ; Section 8.4.9: Request Time-out 434 / "409" ; Section 8.4.10: Conflict 435 / "410" ; Section 8.4.11: Gone 436 / "411" ; Section 8.4.12: Length Required 437 / "412" ; Section 8.4.13: Precondition Failed 438 / "413" ; Section 8.4.14: Request Entity Too Large 439 / "414" ; Section 8.4.15: URI Too Long 440 / "415" ; Section 8.4.16: Unsupported Media Type 441 / "416" ; Section 8.4.17: Requested range not satisfiable 442 / "417" ; Section 8.4.18: Expectation Failed 443 / "500" ; Section 8.5.1: Internal Server Error 444 / "501" ; Section 8.5.2: Not Implemented 445 / "502" ; Section 8.5.3: Bad Gateway 446 / "503" ; Section 8.5.4: Service Unavailable 447 / "504" ; Section 8.5.5: Gateway Time-out 448 / "505" ; Section 8.5.6: HTTP Version not supported 449 / extension-code 451 extension-code = 3DIGIT 452 Reason-Phrase = *( WSP / VCHAR / obs-text ) 454 HTTP status codes are extensible. HTTP applications are not required 455 to understand the meaning of all registered status codes, though such 456 understanding is obviously desirable. However, applications MUST 457 understand the class of any status code, as indicated by the first 458 digit, and treat any unrecognized response as being equivalent to the 459 x00 status code of that class, with the exception that an 460 unrecognized response MUST NOT be cached. For example, if an 461 unrecognized status code of 431 is received by the client, it can 462 safely assume that there was something wrong with its request and 463 treat the response as if it had received a 400 status code. In such 464 cases, user agents SHOULD present to the user the entity returned 465 with the response, since that entity is likely to include human- 466 readable information which will explain the unusual status. 468 4.1. Status Code Registry 470 The HTTP Status Code Registry defines the name space for the Status- 471 Code token in the Status line of an HTTP response. 473 Values to be added to this name space are subject to IETF review 474 ([RFC5226], Section 4.1). 476 The registry itself is maintained at 477 . 479 5. Response Header Fields 481 The response-header fields allow the server to pass additional 482 information about the response which cannot be placed in the Status- 483 Line. These header fields give information about the server and 484 about further access to the resource identified by the request- 485 target. 487 response-header = Accept-Ranges ; [Part5], Section 5.1 488 / Age ; [Part6], Section 3.1 489 / Allow ; Section 9.1 490 / ETag ; [Part4], Section 6.1 491 / Location ; Section 9.4 492 / Proxy-Authenticate ; [Part7], Section 3.2 493 / Retry-After ; Section 9.7 494 / Server ; Section 9.8 495 / Vary ; [Part6], Section 3.5 496 / WWW-Authenticate ; [Part7], Section 3.4 498 Response-header field names can be extended reliably only in 499 combination with a change in the protocol version. However, new or 500 experimental header fields MAY be given the semantics of response- 501 header fields if all parties in the communication recognize them to 502 be response-header fields. Unrecognized header fields are treated as 503 entity-header fields. 505 6. Entity 507 Request and Response messages MAY transfer an entity if not otherwise 508 restricted by the request method or response status code. An entity 509 consists of entity-header fields and an entity-body, although some 510 responses will only include the entity-headers. HTTP entity-body and 511 entity-header fields are defined in [Part3]. 513 An entity-body is only present in a message when a message-body is 514 present, as described in Section 4.3 of [Part1]. The entity-body is 515 obtained from the message-body by decoding any Transfer-Encoding that 516 might have been applied to ensure safe and proper transfer of the 517 message. 519 7. Method Definitions 521 The set of common methods for HTTP/1.1 is defined below. Although 522 this set can be expanded, additional methods cannot be assumed to 523 share the same semantics for separately extended clients and servers. 525 7.1. Safe and Idempotent Methods 527 7.1.1. Safe Methods 529 Implementors should be aware that the software represents the user in 530 their interactions over the Internet, and should be careful to allow 531 the user to be aware of any actions they might take which may have an 532 unexpected significance to themselves or others. 534 In particular, the convention has been established that the GET and 535 HEAD methods SHOULD NOT have the significance of taking an action 536 other than retrieval. These methods ought to be considered "safe". 537 This allows user agents to represent other methods, such as POST, PUT 538 and DELETE, in a special way, so that the user is made aware of the 539 fact that a possibly unsafe action is being requested. 541 Naturally, it is not possible to ensure that the server does not 542 generate side-effects as a result of performing a GET request; in 543 fact, some dynamic resources consider that a feature. The important 544 distinction here is that the user did not request the side-effects, 545 so therefore cannot be held accountable for them. 547 7.1.2. Idempotent Methods 549 Methods can also have the property of "idempotence" in that (aside 550 from error or expiration issues) the side-effects of N > 0 identical 551 requests is the same as for a single request. The methods GET, HEAD, 552 PUT and DELETE share this property. Also, the methods OPTIONS and 553 TRACE SHOULD NOT have side effects, and so are inherently idempotent. 555 However, it is possible that a sequence of several requests is non- 556 idempotent, even if all of the methods executed in that sequence are 557 idempotent. (A sequence is idempotent if a single execution of the 558 entire sequence always yields a result that is not changed by a 559 reexecution of all, or part, of that sequence.) For example, a 560 sequence is non-idempotent if its result depends on a value that is 561 later modified in the same sequence. 563 A sequence that never has side effects is idempotent, by definition 564 (provided that no concurrent operations are being executed on the 565 same set of resources). 567 7.2. OPTIONS 569 The OPTIONS method represents a request for information about the 570 communication options available on the request/response chain 571 identified by the request-target. This method allows the client to 572 determine the options and/or requirements associated with a resource, 573 or the capabilities of a server, without implying a resource action 574 or initiating a resource retrieval. 576 Responses to this method are not cacheable. 578 If the OPTIONS request includes an entity-body (as indicated by the 579 presence of Content-Length or Transfer-Encoding), then the media type 580 MUST be indicated by a Content-Type field. Although this 581 specification does not define any use for such a body, future 582 extensions to HTTP might use the OPTIONS body to make more detailed 583 queries on the server. 585 If the request-target is an asterisk ("*"), the OPTIONS request is 586 intended to apply to the server in general rather than to a specific 587 resource. Since a server's communication options typically depend on 588 the resource, the "*" request is only useful as a "ping" or "no-op" 589 type of method; it does nothing beyond allowing the client to test 590 the capabilities of the server. For example, this can be used to 591 test a proxy for HTTP/1.1 compliance (or lack thereof). 593 If the request-target is not an asterisk, the OPTIONS request applies 594 only to the options that are available when communicating with that 595 resource. 597 A 200 response SHOULD include any header fields that indicate 598 optional features implemented by the server and applicable to that 599 resource (e.g., Allow), possibly including extensions not defined by 600 this specification. The response body, if any, SHOULD also include 601 information about the communication options. The format for such a 602 body is not defined by this specification, but might be defined by 603 future extensions to HTTP. Content negotiation MAY be used to select 604 the appropriate response format. If no response body is included, 605 the response MUST include a Content-Length field with a field-value 606 of "0". 608 The Max-Forwards request-header field MAY be used to target a 609 specific proxy in the request chain. When a proxy receives an 610 OPTIONS request on an absolute-URI for which request forwarding is 611 permitted, the proxy MUST check for a Max-Forwards field. If the 612 Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward 613 the message; instead, the proxy SHOULD respond with its own 614 communication options. If the Max-Forwards field-value is an integer 615 greater than zero, the proxy MUST decrement the field-value when it 616 forwards the request. If no Max-Forwards field is present in the 617 request, then the forwarded request MUST NOT include a Max-Forwards 618 field. 620 7.3. GET 622 The GET method means retrieve whatever information (in the form of an 623 entity) is identified by the request-target. If the request-target 624 refers to a data-producing process, it is the produced data which 625 shall be returned as the entity in the response and not the source 626 text of the process, unless that text happens to be the output of the 627 process. 629 The semantics of the GET method change to a "conditional GET" if the 630 request message includes an If-Modified-Since, If-Unmodified-Since, 631 If-Match, If-None-Match, or If-Range header field. A conditional GET 632 method requests that the entity be transferred only under the 633 circumstances described by the conditional header field(s). The 634 conditional GET method is intended to reduce unnecessary network 635 usage by allowing cached entities to be refreshed without requiring 636 multiple requests or transferring data already held by the client. 638 The semantics of the GET method change to a "partial GET" if the 639 request message includes a Range header field. A partial GET 640 requests that only part of the entity be transferred, as described in 641 Section 5.4 of [Part5]. The partial GET method is intended to reduce 642 unnecessary network usage by allowing partially-retrieved entities to 643 be completed without transferring data already held by the client. 645 The response to a GET request is cacheable if and only if it meets 646 the requirements for HTTP caching described in [Part6]. 648 See Section 11.2 for security considerations when used for forms. 650 7.4. HEAD 652 The HEAD method is identical to GET except that the server MUST NOT 653 return a message-body in the response. The metainformation contained 654 in the HTTP headers in response to a HEAD request SHOULD be identical 655 to the information sent in response to a GET request. This method 656 can be used for obtaining metainformation about the entity implied by 657 the request without transferring the entity-body itself. This method 658 is often used for testing hypertext links for validity, 659 accessibility, and recent modification. 661 The response to a HEAD request MAY be cacheable in the sense that the 662 information contained in the response MAY be used to update a 663 previously cached entity from that resource. If the new field values 664 indicate that the cached entity differs from the current entity (as 665 would be indicated by a change in Content-Length, Content-MD5, ETag 666 or Last-Modified), then the cache MUST treat the cache entry as 667 stale. 669 7.5. POST 671 The POST method is used to request that the origin server accept the 672 entity enclosed in the request as data to be processed by the 673 resource identified by the request-target in the Request-Line. POST 674 is designed to allow a uniform method to cover the following 675 functions: 677 o Annotation of existing resources; 679 o Posting a message to a bulletin board, newsgroup, mailing list, or 680 similar group of articles; 682 o Providing a block of data, such as the result of submitting a 683 form, to a data-handling process; 685 o Extending a database through an append operation. 687 The actual function performed by the POST method is determined by the 688 server and is usually dependent on the request-target. 690 The action performed by the POST method might not result in a 691 resource that can be identified by a URI. In this case, either 200 692 (OK) or 204 (No Content) is the appropriate response status, 693 depending on whether or not the response includes an entity that 694 describes the result. 696 If a resource has been created on the origin server, the response 697 SHOULD be 201 (Created) and contain an entity which describes the 698 status of the request and refers to the new resource, and a Location 699 header (see Section 9.4). 701 Responses to this method are not cacheable, unless the response 702 includes appropriate Cache-Control or Expires header fields. 703 However, the 303 (See Other) response can be used to direct the user 704 agent to retrieve a cacheable resource. 706 7.6. PUT 708 The PUT method requests that the enclosed entity be stored at the 709 supplied request-target. If the request-target refers to an already 710 existing resource, the enclosed entity SHOULD be considered as a 711 modified version of the one residing on the origin server. If the 712 request-target does not point to an existing resource, and that URI 713 is capable of being defined as a new resource by the requesting user 714 agent, the origin server can create the resource with that URI. If a 715 new resource is created at the request-target, the origin server MUST 716 inform the user agent via the 201 (Created) response. If an existing 717 resource is modified, either the 200 (OK) or 204 (No Content) 718 response codes SHOULD be sent to indicate successful completion of 719 the request. If the resource could not be created or modified with 720 the request-target, an appropriate error response SHOULD be given 721 that reflects the nature of the problem. The recipient of the entity 722 MUST NOT ignore any Content-* headers (headers starting with the 723 prefix 'Content-') that it does not understand or implement and MUST 724 return a 501 (Not Implemented) response in such cases. 726 If the request passes through a cache and the request-target 727 identifies one or more currently cached entities, those entries 728 SHOULD be treated as stale. Responses to this method are not 729 cacheable. 731 The fundamental difference between the POST and PUT requests is 732 reflected in the different meaning of the request-target. The URI in 733 a POST request identifies the resource that will handle the enclosed 734 entity. That resource might be a data-accepting process, a gateway 735 to some other protocol, or a separate entity that accepts 736 annotations. In contrast, the URI in a PUT request identifies the 737 entity enclosed with the request -- the user agent knows what URI is 738 intended and the server MUST NOT attempt to apply the request to some 739 other resource. If the server desires that the request be applied to 740 a different URI, it MUST send a 301 (Moved Permanently) response; the 741 user agent MAY then make its own decision regarding whether or not to 742 redirect the request. 744 A single resource MAY be identified by many different URIs. For 745 example, an article might have a URI for identifying "the current 746 version" which is separate from the URI identifying each particular 747 version. In this case, a PUT request on a general URI might result 748 in several other URIs being defined by the origin server. 750 HTTP/1.1 does not define how a PUT method affects the state of an 751 origin server. 753 Unless otherwise specified for a particular entity-header, the 754 entity-headers in the PUT request SHOULD be applied to the resource 755 created or modified by the PUT. 757 7.7. DELETE 759 The DELETE method requests that the origin server delete the resource 760 identified by the request-target. This method MAY be overridden by 761 human intervention (or other means) on the origin server. The client 762 cannot be guaranteed that the operation has been carried out, even if 763 the status code returned from the origin server indicates that the 764 action has been completed successfully. However, the server SHOULD 765 NOT indicate success unless, at the time the response is given, it 766 intends to delete the resource or move it to an inaccessible 767 location. 769 A successful response SHOULD be 200 (OK) if the response includes an 770 entity describing the status, 202 (Accepted) if the action has not 771 yet been enacted, or 204 (No Content) if the action has been enacted 772 but the response does not include an entity. 774 If the request passes through a cache and the request-target 775 identifies one or more currently cached entities, those entries 776 SHOULD be treated as stale. Responses to this method are not 777 cacheable. 779 7.8. TRACE 781 The TRACE method is used to invoke a remote, application-layer loop- 782 back of the request message. The final recipient of the request 783 SHOULD reflect the message received back to the client as the entity- 784 body of a 200 (OK) response. The final recipient is either the 785 origin server or the first proxy or gateway to receive a Max-Forwards 786 value of zero (0) in the request (see Section 9.5). A TRACE request 787 MUST NOT include an entity. 789 TRACE allows the client to see what is being received at the other 790 end of the request chain and use that data for testing or diagnostic 791 information. The value of the Via header field (Section 8.9 of 792 [Part1]) is of particular interest, since it acts as a trace of the 793 request chain. Use of the Max-Forwards header field allows the 794 client to limit the length of the request chain, which is useful for 795 testing a chain of proxies forwarding messages in an infinite loop. 797 If the request is valid, the response SHOULD contain the entire 798 request message in the entity-body, with a Content-Type of "message/ 799 http" (see Section 9.3.1 of [Part1]). Responses to this method MUST 800 NOT be cached. 802 7.9. CONNECT 804 This specification reserves the method name CONNECT for use with a 805 proxy that can dynamically switch to being a tunnel (e.g. SSL 806 tunneling [RFC2817]). 808 8. Status Code Definitions 810 Each Status-Code is described below, including any metainformation 811 required in the response. 813 8.1. Informational 1xx 815 This class of status code indicates a provisional response, 816 consisting only of the Status-Line and optional headers, and is 817 terminated by an empty line. There are no required headers for this 818 class of status code. Since HTTP/1.0 did not define any 1xx status 819 codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client 820 except under experimental conditions. 822 A client MUST be prepared to accept one or more 1xx status responses 823 prior to a regular response, even if the client does not expect a 100 824 (Continue) status message. Unexpected 1xx status responses MAY be 825 ignored by a user agent. 827 Proxies MUST forward 1xx responses, unless the connection between the 828 proxy and its client has been closed, or unless the proxy itself 829 requested the generation of the 1xx response. (For example, if a 830 proxy adds a "Expect: 100-continue" field when it forwards a request, 831 then it need not forward the corresponding 100 (Continue) 832 response(s).) 834 8.1.1. 100 Continue 836 The client SHOULD continue with its request. This interim response 837 is used to inform the client that the initial part of the request has 838 been received and has not yet been rejected by the server. The 839 client SHOULD continue by sending the remainder of the request or, if 840 the request has already been completed, ignore this response. The 841 server MUST send a final response after the request has been 842 completed. See Section 7.2.3 of [Part1] for detailed discussion of 843 the use and handling of this status code. 845 8.1.2. 101 Switching Protocols 847 The server understands and is willing to comply with the client's 848 request, via the Upgrade message header field (Section 5.4 of 849 [Part5]), for a change in the application protocol being used on this 850 connection. The server will switch protocols to those defined by the 851 response's Upgrade header field immediately after the empty line 852 which terminates the 101 response. 854 The protocol SHOULD be switched only when it is advantageous to do 855 so. For example, switching to a newer version of HTTP is 856 advantageous over older versions, and switching to a real-time, 857 synchronous protocol might be advantageous when delivering resources 858 that use such features. 860 8.2. Successful 2xx 862 This class of status code indicates that the client's request was 863 successfully received, understood, and accepted. 865 8.2.1. 200 OK 867 The request has succeeded. The information returned with the 868 response is dependent on the method used in the request, for example: 870 GET an entity corresponding to the requested resource is sent in the 871 response; 873 HEAD the entity-header fields corresponding to the requested 874 resource are sent in the response without any message-body; 876 POST an entity describing or containing the result of the action; 878 TRACE an entity containing the request message as received by the 879 end server. 881 8.2.2. 201 Created 883 The request has been fulfilled and resulted in a new resource being 884 created. The newly created resource can be referenced by the URI(s) 885 returned in the entity of the response, with the most specific URI 886 for the resource given by a Location header field. The response 887 SHOULD include an entity containing a list of resource 888 characteristics and location(s) from which the user or user agent can 889 choose the one most appropriate. The entity format is specified by 890 the media type given in the Content-Type header field. The origin 891 server MUST create the resource before returning the 201 status code. 892 If the action cannot be carried out immediately, the server SHOULD 893 respond with 202 (Accepted) response instead. 895 A 201 response MAY contain an ETag response header field indicating 896 the current value of the entity tag for the requested variant just 897 created, see Section 6.1 of [Part4]. 899 8.2.3. 202 Accepted 901 The request has been accepted for processing, but the processing has 902 not been completed. The request might or might not eventually be 903 acted upon, as it might be disallowed when processing actually takes 904 place. There is no facility for re-sending a status code from an 905 asynchronous operation such as this. 907 The 202 response is intentionally non-committal. Its purpose is to 908 allow a server to accept a request for some other process (perhaps a 909 batch-oriented process that is only run once per day) without 910 requiring that the user agent's connection to the server persist 911 until the process is completed. The entity returned with this 912 response SHOULD include an indication of the request's current status 913 and either a pointer to a status monitor or some estimate of when the 914 user can expect the request to be fulfilled. 916 8.2.4. 203 Non-Authoritative Information 918 The returned metainformation in the entity-header is not the 919 definitive set as available from the origin server, but is gathered 920 from a local or a third-party copy. The set presented MAY be a 921 subset or superset of the original version. For example, including 922 local annotation information about the resource might result in a 923 superset of the metainformation known by the origin server. Use of 924 this response code is not required and is only appropriate when the 925 response would otherwise be 200 (OK). 927 8.2.5. 204 No Content 929 The server has fulfilled the request but does not need to return an 930 entity-body, and might want to return updated metainformation. The 931 response MAY include new or updated metainformation in the form of 932 entity-headers, which if present SHOULD be associated with the 933 requested variant. 935 If the client is a user agent, it SHOULD NOT change its document view 936 from that which caused the request to be sent. This response is 937 primarily intended to allow input for actions to take place without 938 causing a change to the user agent's active document view, although 939 any new or updated metainformation SHOULD be applied to the document 940 currently in the user agent's active view. 942 The 204 response MUST NOT include a message-body, and thus is always 943 terminated by the first empty line after the header fields. 945 8.2.6. 205 Reset Content 947 The server has fulfilled the request and the user agent SHOULD reset 948 the document view which caused the request to be sent. This response 949 is primarily intended to allow input for actions to take place via 950 user input, followed by a clearing of the form in which the input is 951 given so that the user can easily initiate another input action. The 952 response MUST NOT include an entity. 954 8.2.7. 206 Partial Content 956 The server has fulfilled the partial GET request for the resource and 957 the enclosed entity is a partial representation as defined in 958 [Part5]. 960 8.3. Redirection 3xx 962 This class of status code indicates that further action needs to be 963 taken by the user agent in order to fulfill the request. The action 964 required MAY be carried out by the user agent without interaction 965 with the user if and only if the method used in the second request is 966 GET or HEAD. A client SHOULD detect infinite redirection loops, 967 since such loops generate network traffic for each redirection. 969 Note: previous versions of this specification recommended a 970 maximum of five redirections. Content developers should be aware 971 that there might be clients that implement such a fixed 972 limitation. 974 8.3.1. 300 Multiple Choices 976 The requested resource corresponds to any one of a set of 977 representations, each with its own specific location, and agent- 978 driven negotiation information (Section 4 of [Part3]) is being 979 provided so that the user (or user agent) can select a preferred 980 representation and redirect its request to that location. 982 Unless it was a HEAD request, the response SHOULD include an entity 983 containing a list of resource characteristics and location(s) from 984 which the user or user agent can choose the one most appropriate. 985 The entity format is specified by the media type given in the 986 Content-Type header field. Depending upon the format and the 987 capabilities of the user agent, selection of the most appropriate 988 choice MAY be performed automatically. However, this specification 989 does not define any standard for such automatic selection. 991 If the server has a preferred choice of representation, it SHOULD 992 include the specific URI for that representation in the Location 993 field; user agents MAY use the Location field value for automatic 994 redirection. This response is cacheable unless indicated otherwise. 996 8.3.2. 301 Moved Permanently 998 The requested resource has been assigned a new permanent URI and any 999 future references to this resource SHOULD use one of the returned 1000 URIs. Clients with link editing capabilities ought to automatically 1001 re-link references to the request-target to one or more of the new 1002 references returned by the server, where possible. This response is 1003 cacheable unless indicated otherwise. 1005 The new permanent URI SHOULD be given by the Location field in the 1006 response. Unless the request method was HEAD, the entity of the 1007 response SHOULD contain a short hypertext note with a hyperlink to 1008 the new URI(s). 1010 If the 301 status code is received in response to a request method 1011 that is known to be "safe", as defined in Section 7.1.1, then the 1012 request MAY be automatically redirected by the user agent without 1013 confirmation. Otherwise, the user agent MUST NOT automatically 1014 redirect the request unless it can be confirmed by the user, since 1015 this might change the conditions under which the request was issued. 1017 Note: When automatically redirecting a POST request after 1018 receiving a 301 status code, some existing HTTP/1.0 user agents 1019 will erroneously change it into a GET request. 1021 8.3.3. 302 Found 1023 The requested resource resides temporarily under a different URI. 1024 Since the redirection might be altered on occasion, the client SHOULD 1025 continue to use the request-target for future requests. This 1026 response is only cacheable if indicated by a Cache-Control or Expires 1027 header field. 1029 The temporary URI SHOULD be given by the Location field in the 1030 response. Unless the request method was HEAD, the entity of the 1031 response SHOULD contain a short hypertext note with a hyperlink to 1032 the new URI(s). 1034 If the 302 status code is received in response to a request method 1035 that is known to be "safe", as defined in Section 7.1.1, then the 1036 request MAY be automatically redirected by the user agent without 1037 confirmation. Otherwise, the user agent MUST NOT automatically 1038 redirect the request unless it can be confirmed by the user, since 1039 this might change the conditions under which the request was issued. 1041 Note: [RFC1945] and [RFC2068] specify that the client is not 1042 allowed to change the method on the redirected request. However, 1043 most existing user agent implementations treat 302 as if it were a 1044 303 response, performing a GET on the Location field-value 1045 regardless of the original request method. The status codes 303 1046 and 307 have been added for servers that wish to make 1047 unambiguously clear which kind of reaction is expected of the 1048 client. 1050 8.3.4. 303 See Other 1052 The server directs the user agent to a different resource, indicated 1053 by a URI in the Location header field, that provides an indirect 1054 response to the original request. The user agent MAY perform a GET 1055 request on the URI in the Location field in order to obtain a 1056 representation corresponding to the response, be redirected again, or 1057 end with an error status. The Location URI is not a substitute 1058 reference for the originally requested resource. 1060 The 303 status is generally applicable to any HTTP method. It is 1061 primarily used to allow the output of a POST action to redirect the 1062 user agent to a selected resource, since doing so provides the 1063 information corresponding to the POST response in a form that can be 1064 separately identified, bookmarked, and cached independent of the 1065 original request. 1067 A 303 response to a GET request indicates that the requested resource 1068 does not have a representation of its own that can be transferred by 1069 the server over HTTP. The Location URI indicates a resource that is 1070 descriptive of the requested resource such that the follow-on 1071 representation may be useful without implying that it adequately 1072 represents the previously requested resource. Note that answers to 1073 the questions of what can be represented, what representations are 1074 adequate, and what might be a useful description are outside the 1075 scope of HTTP and thus entirely determined by the URI owner(s). 1077 A 303 response SHOULD NOT be cached unless it is indicated as 1078 cacheable by Cache-Control or Expires header fields. Except for 1079 responses to a HEAD request, the entity of a 303 response SHOULD 1080 contain a short hypertext note with a hyperlink to the Location URI. 1082 8.3.5. 304 Not Modified 1084 The response to the request has not been modified since the 1085 conditions indicated by the client's conditional GET request, as 1086 defined in [Part4]. 1088 8.3.6. 305 Use Proxy 1090 The 305 status was defined in a previous version of this 1091 specification (see Appendix A.2), and is now deprecated. 1093 8.3.7. 306 (Unused) 1095 The 306 status code was used in a previous version of the 1096 specification, is no longer used, and the code is reserved. 1098 8.3.8. 307 Temporary Redirect 1100 The requested resource resides temporarily under a different URI. 1101 Since the redirection MAY be altered on occasion, the client SHOULD 1102 continue to use the request-target for future requests. This 1103 response is only cacheable if indicated by a Cache-Control or Expires 1104 header field. 1106 The temporary URI SHOULD be given by the Location field in the 1107 response. Unless the request method was HEAD, the entity of the 1108 response SHOULD contain a short hypertext note with a hyperlink to 1109 the new URI(s) , since many pre-HTTP/1.1 user agents do not 1110 understand the 307 status. Therefore, the note SHOULD contain the 1111 information necessary for a user to repeat the original request on 1112 the new URI. 1114 If the 307 status code is received in response to a request method 1115 that is known to be "safe", as defined in Section 7.1.1, then the 1116 request MAY be automatically redirected by the user agent without 1117 confirmation. Otherwise, the user agent MUST NOT automatically 1118 redirect the request unless it can be confirmed by the user, since 1119 this might change the conditions under which the request was issued. 1121 8.4. Client Error 4xx 1123 The 4xx class of status code is intended for cases in which the 1124 client seems to have erred. Except when responding to a HEAD 1125 request, the server SHOULD include an entity containing an 1126 explanation of the error situation, and whether it is a temporary or 1127 permanent condition. These status codes are applicable to any 1128 request method. User agents SHOULD display any included entity to 1129 the user. 1131 If the client is sending data, a server implementation using TCP 1132 SHOULD be careful to ensure that the client acknowledges receipt of 1133 the packet(s) containing the response, before the server closes the 1134 input connection. If the client continues sending data to the server 1135 after the close, the server's TCP stack will send a reset packet to 1136 the client, which may erase the client's unacknowledged input buffers 1137 before they can be read and interpreted by the HTTP application. 1139 8.4.1. 400 Bad Request 1141 The request could not be understood by the server due to malformed 1142 syntax. The client SHOULD NOT repeat the request without 1143 modifications. 1145 8.4.2. 401 Unauthorized 1147 The request requires user authentication (see [Part7]). 1149 8.4.3. 402 Payment Required 1151 This code is reserved for future use. 1153 8.4.4. 403 Forbidden 1155 The server understood the request, but is refusing to fulfill it. 1156 Authorization will not help and the request SHOULD NOT be repeated. 1157 If the request method was not HEAD and the server wishes to make 1158 public why the request has not been fulfilled, it SHOULD describe the 1159 reason for the refusal in the entity. If the server does not wish to 1160 make this information available to the client, the status code 404 1161 (Not Found) can be used instead. 1163 8.4.5. 404 Not Found 1165 The server has not found anything matching the request-target. No 1166 indication is given of whether the condition is temporary or 1167 permanent. The 410 (Gone) status code SHOULD be used if the server 1168 knows, through some internally configurable mechanism, that an old 1169 resource is permanently unavailable and has no forwarding address. 1170 This status code is commonly used when the server does not wish to 1171 reveal exactly why the request has been refused, or when no other 1172 response is applicable. 1174 8.4.6. 405 Method Not Allowed 1176 The method specified in the Request-Line is not allowed for the 1177 resource identified by the request-target. The response MUST include 1178 an Allow header containing a list of valid methods for the requested 1179 resource. 1181 8.4.7. 406 Not Acceptable 1183 The resource identified by the request is only capable of generating 1184 response entities which have content characteristics not acceptable 1185 according to the accept headers sent in the request. 1187 Unless it was a HEAD request, the response SHOULD include an entity 1188 containing a list of available entity characteristics and location(s) 1189 from which the user or user agent can choose the one most 1190 appropriate. The entity format is specified by the media type given 1191 in the Content-Type header field. Depending upon the format and the 1192 capabilities of the user agent, selection of the most appropriate 1193 choice MAY be performed automatically. However, this specification 1194 does not define any standard for such automatic selection. 1196 Note: HTTP/1.1 servers are allowed to return responses which are 1197 not acceptable according to the accept headers sent in the 1198 request. In some cases, this may even be preferable to sending a 1199 406 response. User agents are encouraged to inspect the headers 1200 of an incoming response to determine if it is acceptable. 1202 If the response could be unacceptable, a user agent SHOULD 1203 temporarily stop receipt of more data and query the user for a 1204 decision on further actions. 1206 8.4.8. 407 Proxy Authentication Required 1208 This code is similar to 401 (Unauthorized), but indicates that the 1209 client must first authenticate itself with the proxy (see [Part7]). 1211 8.4.9. 408 Request Timeout 1213 The client did not produce a request within the time that the server 1214 was prepared to wait. The client MAY repeat the request without 1215 modifications at any later time. 1217 8.4.10. 409 Conflict 1219 The request could not be completed due to a conflict with the current 1220 state of the resource. This code is only allowed in situations where 1221 it is expected that the user might be able to resolve the conflict 1222 and resubmit the request. The response body SHOULD include enough 1223 information for the user to recognize the source of the conflict. 1224 Ideally, the response entity would include enough information for the 1225 user or user agent to fix the problem; however, that might not be 1226 possible and is not required. 1228 Conflicts are most likely to occur in response to a PUT request. For 1229 example, if versioning were being used and the entity being PUT 1230 included changes to a resource which conflict with those made by an 1231 earlier (third-party) request, the server might use the 409 response 1232 to indicate that it can't complete the request. In this case, the 1233 response entity would likely contain a list of the differences 1234 between the two versions in a format defined by the response Content- 1235 Type. 1237 8.4.11. 410 Gone 1239 The requested resource is no longer available at the server and no 1240 forwarding address is known. This condition is expected to be 1241 considered permanent. Clients with link editing capabilities SHOULD 1242 delete references to the request-target after user approval. If the 1243 server does not know, or has no facility to determine, whether or not 1244 the condition is permanent, the status code 404 (Not Found) SHOULD be 1245 used instead. This response is cacheable unless indicated otherwise. 1247 The 410 response is primarily intended to assist the task of web 1248 maintenance by notifying the recipient that the resource is 1249 intentionally unavailable and that the server owners desire that 1250 remote links to that resource be removed. Such an event is common 1251 for limited-time, promotional services and for resources belonging to 1252 individuals no longer working at the server's site. It is not 1253 necessary to mark all permanently unavailable resources as "gone" or 1254 to keep the mark for any length of time -- that is left to the 1255 discretion of the server owner. 1257 8.4.12. 411 Length Required 1259 The server refuses to accept the request without a defined Content- 1260 Length. The client MAY repeat the request if it adds a valid 1261 Content-Length header field containing the length of the message-body 1262 in the request message. 1264 8.4.13. 412 Precondition Failed 1266 The precondition given in one or more of the request-header fields 1267 evaluated to false when it was tested on the server, as defined in 1268 [Part4]. 1270 8.4.14. 413 Request Entity Too Large 1272 The server is refusing to process a request because the request 1273 entity is larger than the server is willing or able to process. The 1274 server MAY close the connection to prevent the client from continuing 1275 the request. 1277 If the condition is temporary, the server SHOULD include a Retry- 1278 After header field to indicate that it is temporary and after what 1279 time the client MAY try again. 1281 8.4.15. 414 URI Too Long 1283 The server is refusing to service the request because the request- 1284 target is longer than the server is willing to interpret. This rare 1285 condition is only likely to occur when a client has improperly 1286 converted a POST request to a GET request with long query 1287 information, when the client has descended into a URI "black hole" of 1288 redirection (e.g., a redirected URI prefix that points to a suffix of 1289 itself), or when the server is under attack by a client attempting to 1290 exploit security holes present in some servers using fixed-length 1291 buffers for reading or manipulating the request-target. 1293 8.4.16. 415 Unsupported Media Type 1295 The server is refusing to service the request because the entity of 1296 the request is in a format not supported by the requested resource 1297 for the requested method. 1299 8.4.17. 416 Requested Range Not Satisfiable 1301 The request included a Range request-header field (Section 5.4 of 1302 [Part5]) and none of the range-specifier values in this field overlap 1303 the current extent of the selected resource. 1305 8.4.18. 417 Expectation Failed 1307 The expectation given in an Expect request-header field (see 1308 Section 9.2) could not be met by this server, or, if the server is a 1309 proxy, the server has unambiguous evidence that the request could not 1310 be met by the next-hop server. 1312 8.5. Server Error 5xx 1314 Response status codes beginning with the digit "5" indicate cases in 1315 which the server is aware that it has erred or is incapable of 1316 performing the request. Except when responding to a HEAD request, 1317 the server SHOULD include an entity containing an explanation of the 1318 error situation, and whether it is a temporary or permanent 1319 condition. User agents SHOULD display any included entity to the 1320 user. These response codes are applicable to any request method. 1322 8.5.1. 500 Internal Server Error 1324 The server encountered an unexpected condition which prevented it 1325 from fulfilling the request. 1327 8.5.2. 501 Not Implemented 1329 The server does not support the functionality required to fulfill the 1330 request. This is the appropriate response when the server does not 1331 recognize the request method and is not capable of supporting it for 1332 any resource. 1334 8.5.3. 502 Bad Gateway 1336 The server, while acting as a gateway or proxy, received an invalid 1337 response from the upstream server it accessed in attempting to 1338 fulfill the request. 1340 8.5.4. 503 Service Unavailable 1342 The server is currently unable to handle the request due to a 1343 temporary overloading or maintenance of the server. The implication 1344 is that this is a temporary condition which will be alleviated after 1345 some delay. If known, the length of the delay MAY be indicated in a 1346 Retry-After header. If no Retry-After is given, the client SHOULD 1347 handle the response as it would for a 500 response. 1349 Note: The existence of the 503 status code does not imply that a 1350 server must use it when becoming overloaded. Some servers may 1351 wish to simply refuse the connection. 1353 8.5.5. 504 Gateway Timeout 1355 The server, while acting as a gateway or proxy, did not receive a 1356 timely response from the upstream server specified by the URI (e.g. 1357 HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed 1358 to access in attempting to complete the request. 1360 Note: Note to implementors: some deployed proxies are known to 1361 return 400 or 500 when DNS lookups time out. 1363 8.5.6. 505 HTTP Version Not Supported 1365 The server does not support, or refuses to support, the protocol 1366 version that was used in the request message. The server is 1367 indicating that it is unable or unwilling to complete the request 1368 using the same major version as the client, as described in Section 1369 3.1 of [Part1], other than with this error message. The response 1370 SHOULD contain an entity describing why that version is not supported 1371 and what other protocols are supported by that server. 1373 9. Header Field Definitions 1375 This section defines the syntax and semantics of HTTP/1.1 header 1376 fields related to request and response semantics. 1378 For entity-header fields, both sender and recipient refer to either 1379 the client or the server, depending on who sends and who receives the 1380 entity. 1382 9.1. Allow 1384 The response-header field "Allow" lists the set of methods advertised 1385 as supported by the resource identified by the request-target. The 1386 purpose of this field is strictly to inform the recipient of valid 1387 methods associated with the resource. An Allow header field MUST be 1388 present in a 405 (Method Not Allowed) response. 1390 Allow = "Allow" ":" OWS Allow-v 1391 Allow-v = #Method 1393 Example of use: 1395 Allow: GET, HEAD, PUT 1397 The actual set of allowed methods is defined by the origin server at 1398 the time of each request. 1400 A proxy MUST NOT modify the Allow header field even if it does not 1401 understand all the methods specified, since the user agent might have 1402 other means of communicating with the origin server. 1404 9.2. Expect 1406 The request-header field "Expect" is used to indicate that particular 1407 server behaviors are required by the client. 1409 Expect = "Expect" ":" OWS Expect-v 1410 Expect-v = 1#expectation 1412 expectation = "100-continue" / expectation-extension 1413 expectation-extension = token [ "=" ( token / quoted-string ) 1414 *expect-params ] 1415 expect-params = ";" token [ "=" ( token / quoted-string ) ] 1417 A server that does not understand or is unable to comply with any of 1418 the expectation values in the Expect field of a request MUST respond 1419 with appropriate error status. The server MUST respond with a 417 1420 (Expectation Failed) status if any of the expectations cannot be met 1421 or, if there are other problems with the request, some other 4xx 1422 status. 1424 This header field is defined with extensible syntax to allow for 1425 future extensions. If a server receives a request containing an 1426 Expect field that includes an expectation-extension that it does not 1427 support, it MUST respond with a 417 (Expectation Failed) status. 1429 Comparison of expectation values is case-insensitive for unquoted 1430 tokens (including the 100-continue token), and is case-sensitive for 1431 quoted-string expectation-extensions. 1433 The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST 1434 return a 417 (Expectation Failed) status if it receives a request 1435 with an expectation that it cannot meet. However, the Expect 1436 request-header itself is end-to-end; it MUST be forwarded if the 1437 request is forwarded. 1439 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the 1440 Expect header. 1442 See Section 7.2.3 of [Part1] for the use of the 100 (Continue) 1443 status. 1445 9.3. From 1447 The request-header field "From", if given, SHOULD contain an Internet 1448 e-mail address for the human user who controls the requesting user 1449 agent. The address SHOULD be machine-usable, as defined by "mailbox" 1450 in Section 3.4 of [RFC5322]: 1452 From = "From" ":" OWS From-v 1453 From-v = mailbox 1455 mailbox = 1457 An example is: 1459 From: webmaster@example.org 1461 This header field MAY be used for logging purposes and as a means for 1462 identifying the source of invalid or unwanted requests. It SHOULD 1463 NOT be used as an insecure form of access protection. The 1464 interpretation of this field is that the request is being performed 1465 on behalf of the person given, who accepts responsibility for the 1466 method performed. In particular, robot agents SHOULD include this 1467 header so that the person responsible for running the robot can be 1468 contacted if problems occur on the receiving end. 1470 The Internet e-mail address in this field MAY be separate from the 1471 Internet host which issued the request. For example, when a request 1472 is passed through a proxy the original issuer's address SHOULD be 1473 used. 1475 The client SHOULD NOT send the From header field without the user's 1476 approval, as it might conflict with the user's privacy interests or 1477 their site's security policy. It is strongly recommended that the 1478 user be able to disable, enable, and modify the value of this field 1479 at any time prior to a request. 1481 9.4. Location 1483 The response-header field "Location" is used for the identification 1484 of a new resource or to redirect the recipient to a location other 1485 than the request-target for completion of the request. For 201 1486 (Created) responses, the Location is that of the new resource which 1487 was created by the request. For 3xx responses, the location SHOULD 1488 indicate the server's preferred URI for automatic redirection to the 1489 resource. The field value consists of a single absolute URI. 1491 Location = "Location" ":" OWS Location-v 1492 Location-v = absolute-URI [ "#" fragment ] 1494 An example is: 1496 Location: http://www.example.org/pub/WWW/People.html 1498 Note: The Content-Location header field (Section 5.7 of [Part3]) 1499 differs from Location in that the Content-Location identifies the 1500 original location of the entity enclosed in the response. It is 1501 therefore possible for a response to contain header fields for 1502 both Location and Content-Location. 1504 There are circumstances in which a fragment identifier in a Location 1505 URL would not be appropriate: 1507 o With a 201 Created response, because in this usage the Location 1508 header specifies the URL for the entire created resource. 1510 o With a 300 Multiple Choices, since the choice decision is intended 1511 to be made on resource characteristics and not fragment 1512 characteristics. 1514 o With 305 Use Proxy. 1516 9.5. Max-Forwards 1518 The request-header "Max-Forwards" field provides a mechanism with the 1519 TRACE (Section 7.8) and OPTIONS (Section 7.2) methods to limit the 1520 number of proxies or gateways that can forward the request to the 1521 next inbound server. This can be useful when the client is 1522 attempting to trace a request chain which appears to be failing or 1523 looping in mid-chain. 1525 Max-Forwards = "Max-Forwards" ":" OWS Max-Forwards-v 1526 Max-Forwards-v = 1*DIGIT 1528 The Max-Forwards value is a decimal integer indicating the remaining 1529 number of times this request message may be forwarded. 1531 Each proxy or gateway recipient of a TRACE or OPTIONS request 1532 containing a Max-Forwards header field MUST check and update its 1533 value prior to forwarding the request. If the received value is zero 1534 (0), the recipient MUST NOT forward the request; instead, it MUST 1535 respond as the final recipient. If the received Max-Forwards value 1536 is greater than zero, then the forwarded message MUST contain an 1537 updated Max-Forwards field with a value decremented by one (1). 1539 The Max-Forwards header field MAY be ignored for all other methods 1540 defined by this specification and for any extension methods for which 1541 it is not explicitly referred to as part of that method definition. 1543 9.6. Referer 1545 The request-header field "Referer" [sic] allows the client to 1546 specify, for the server's benefit, the address (URI) of the resource 1547 from which the request-target was obtained (the "referrer", although 1548 the header field is misspelled.). 1550 The Referer header allows servers to generate lists of back-links to 1551 resources for interest, logging, optimized caching, etc. It also 1552 allows obsolete or mistyped links to be traced for maintenance. Some 1553 servers use Referer as a means of controlling where they allow links 1554 from (so-called "deep linking"), but it should be noted that 1555 legitimate requests are not required to contain a Referer header 1556 field. 1558 If the request-target was obtained from a source that does not have 1559 its own URI (e.g., input from the user keyboard), the Referer field 1560 MUST either be sent with the value "about:blank", or not be sent at 1561 all. Note that this requirement does not apply to sources with non- 1562 HTTP URIs (e.g., FTP). 1564 Referer = "Referer" ":" OWS Referer-v 1565 Referer-v = absolute-URI / partial-URI 1567 Example: 1569 Referer: http://www.example.org/hypertext/Overview.html 1571 If the field value is a relative URI, it SHOULD be interpreted 1572 relative to the request-target. The URI MUST NOT include a fragment. 1573 See Section 11.2 for security considerations. 1575 9.7. Retry-After 1577 The response-header "Retry-After" field can be used with a 503 1578 (Service Unavailable) response to indicate how long the service is 1579 expected to be unavailable to the requesting client. This field MAY 1580 also be used with any 3xx (Redirection) response to indicate the 1581 minimum time the user-agent is asked wait before issuing the 1582 redirected request. The value of this field can be either an HTTP- 1583 date or an integer number of seconds (in decimal) after the time of 1584 the response. 1586 Retry-After = "Retry-After" ":" OWS Retry-After-v 1587 Retry-After-v = HTTP-date / delta-seconds 1589 Time spans are non-negative decimal integers, representing time in 1590 seconds. 1592 delta-seconds = 1*DIGIT 1594 Two examples of its use are 1596 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 1597 Retry-After: 120 1599 In the latter example, the delay is 2 minutes. 1601 9.8. Server 1603 The response-header field "Server" contains information about the 1604 software used by the origin server to handle the request. The field 1605 can contain multiple product tokens (Section 3.4 of [Part1]) and 1606 comments identifying the server and any significant subproducts. The 1607 product tokens are listed in order of their significance for 1608 identifying the application. 1610 Server = "Server" ":" OWS Server-v 1611 Server-v = product 1612 *( RWS ( product / comment ) ) 1614 Example: 1616 Server: CERN/3.0 libwww/2.17 1618 If the response is being forwarded through a proxy, the proxy 1619 application MUST NOT modify the Server response-header. Instead, it 1620 MUST include a Via field (as described in Section 8.9 of [Part1]). 1622 Note: Revealing the specific software version of the server might 1623 allow the server machine to become more vulnerable to attacks 1624 against software that is known to contain security holes. Server 1625 implementors are encouraged to make this field a configurable 1626 option. 1628 9.9. User-Agent 1630 The request-header field "User-Agent" contains information about the 1631 user agent originating the request. This is for statistical 1632 purposes, the tracing of protocol violations, and automated 1633 recognition of user agents for the sake of tailoring responses to 1634 avoid particular user agent limitations. User agents SHOULD include 1635 this field with requests. The field can contain multiple product 1636 tokens (Section 3.4 of [Part1]) and comments identifying the agent 1637 and any subproducts which form a significant part of the user agent. 1638 By convention, the product tokens are listed in order of their 1639 significance for identifying the application. 1641 User-Agent = "User-Agent" ":" OWS User-Agent-v 1642 User-Agent-v = product 1643 *( RWS ( product / comment ) ) 1645 Example: 1647 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1649 10. IANA Considerations 1651 10.1. Method Registry 1653 The registration procedure for HTTP Methods is defined by Section 2.1 1654 of this document. 1656 The HTTP Method Registry located at 1657 should be populated 1658 with the registrations below: 1660 +---------+------+-------------+ 1661 | Method | Safe | Reference | 1662 +---------+------+-------------+ 1663 | CONNECT | no | Section 7.9 | 1664 | DELETE | no | Section 7.7 | 1665 | GET | yes | Section 7.3 | 1666 | HEAD | yes | Section 7.4 | 1667 | OPTIONS | yes | Section 7.2 | 1668 | POST | no | Section 7.5 | 1669 | PUT | no | Section 7.6 | 1670 | TRACE | yes | Section 7.8 | 1671 +---------+------+-------------+ 1673 10.2. Status Code Registry 1675 The registration procedure for HTTP Status Codes -- previously 1676 defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.1 1677 of this document. 1679 The HTTP Status Code Registry located at 1680 should be updated 1681 with the registrations below: 1683 +-------+---------------------------------+----------------+ 1684 | Value | Description | Reference | 1685 +-------+---------------------------------+----------------+ 1686 | 100 | Continue | Section 8.1.1 | 1687 | 101 | Switching Protocols | Section 8.1.2 | 1688 | 200 | OK | Section 8.2.1 | 1689 | 201 | Created | Section 8.2.2 | 1690 | 202 | Accepted | Section 8.2.3 | 1691 | 203 | Non-Authoritative Information | Section 8.2.4 | 1692 | 204 | No Content | Section 8.2.5 | 1693 | 205 | Reset Content | Section 8.2.6 | 1694 | 206 | Partial Content | Section 8.2.7 | 1695 | 300 | Multiple Choices | Section 8.3.1 | 1696 | 301 | Moved Permanently | Section 8.3.2 | 1697 | 302 | Found | Section 8.3.3 | 1698 | 303 | See Other | Section 8.3.4 | 1699 | 304 | Not Modified | Section 8.3.5 | 1700 | 305 | Use Proxy | Section 8.3.6 | 1701 | 306 | (Unused) | Section 8.3.7 | 1702 | 307 | Temporary Redirect | Section 8.3.8 | 1703 | 400 | Bad Request | Section 8.4.1 | 1704 | 401 | Unauthorized | Section 8.4.2 | 1705 | 402 | Payment Required | Section 8.4.3 | 1706 | 403 | Forbidden | Section 8.4.4 | 1707 | 404 | Not Found | Section 8.4.5 | 1708 | 405 | Method Not Allowed | Section 8.4.6 | 1709 | 406 | Not Acceptable | Section 8.4.7 | 1710 | 407 | Proxy Authentication Required | Section 8.4.8 | 1711 | 408 | Request Timeout | Section 8.4.9 | 1712 | 409 | Conflict | Section 8.4.10 | 1713 | 410 | Gone | Section 8.4.11 | 1714 | 411 | Length Required | Section 8.4.12 | 1715 | 412 | Precondition Failed | Section 8.4.13 | 1716 | 413 | Request Entity Too Large | Section 8.4.14 | 1717 | 414 | URI Too Long | Section 8.4.15 | 1718 | 415 | Unsupported Media Type | Section 8.4.16 | 1719 | 416 | Requested Range Not Satisfiable | Section 8.4.17 | 1720 | 417 | Expectation Failed | Section 8.4.18 | 1721 | 500 | Internal Server Error | Section 8.5.1 | 1722 | 501 | Not Implemented | Section 8.5.2 | 1723 | 502 | Bad Gateway | Section 8.5.3 | 1724 | 503 | Service Unavailable | Section 8.5.4 | 1725 | 504 | Gateway Timeout | Section 8.5.5 | 1726 | 505 | HTTP Version Not Supported | Section 8.5.6 | 1727 +-------+---------------------------------+----------------+ 1729 10.3. Message Header Registration 1731 The Message Header Registry located at should be 1733 updated with the permanent registrations below (see [RFC3864]): 1735 +-------------------+----------+----------+-------------+ 1736 | Header Field Name | Protocol | Status | Reference | 1737 +-------------------+----------+----------+-------------+ 1738 | Allow | http | standard | Section 9.1 | 1739 | Expect | http | standard | Section 9.2 | 1740 | From | http | standard | Section 9.3 | 1741 | Location | http | standard | Section 9.4 | 1742 | Max-Forwards | http | standard | Section 9.5 | 1743 | Referer | http | standard | Section 9.6 | 1744 | Retry-After | http | standard | Section 9.7 | 1745 | Server | http | standard | Section 9.8 | 1746 | User-Agent | http | standard | Section 9.9 | 1747 +-------------------+----------+----------+-------------+ 1749 The change controller is: "IETF (iesg@ietf.org) - Internet 1750 Engineering Task Force". 1752 11. Security Considerations 1754 This section is meant to inform application developers, information 1755 providers, and users of the security limitations in HTTP/1.1 as 1756 described by this document. The discussion does not include 1757 definitive solutions to the problems revealed, though it does make 1758 some suggestions for reducing security risks. 1760 11.1. Transfer of Sensitive Information 1762 Like any generic data transfer protocol, HTTP cannot regulate the 1763 content of the data that is transferred, nor is there any a priori 1764 method of determining the sensitivity of any particular piece of 1765 information within the context of any given request. Therefore, 1766 applications SHOULD supply as much control over this information as 1767 possible to the provider of that information. Four header fields are 1768 worth special mention in this context: Server, Via, Referer and From. 1770 Revealing the specific software version of the server might allow the 1771 server machine to become more vulnerable to attacks against software 1772 that is known to contain security holes. Implementors SHOULD make 1773 the Server header field a configurable option. 1775 Proxies which serve as a portal through a network firewall SHOULD 1776 take special precautions regarding the transfer of header information 1777 that identifies the hosts behind the firewall. In particular, they 1778 SHOULD remove, or replace with sanitized versions, any Via fields 1779 generated behind the firewall. 1781 The Referer header allows reading patterns to be studied and reverse 1782 links drawn. Although it can be very useful, its power can be abused 1783 if user details are not separated from the information contained in 1784 the Referer. Even when the personal information has been removed, 1785 the Referer header might indicate a private document's URI whose 1786 publication would be inappropriate. 1788 The information sent in the From field might conflict with the user's 1789 privacy interests or their site's security policy, and hence it 1790 SHOULD NOT be transmitted without the user being able to disable, 1791 enable, and modify the contents of the field. The user MUST be able 1792 to set the contents of this field within a user preference or 1793 application defaults configuration. 1795 We suggest, though do not require, that a convenient toggle interface 1796 be provided for the user to enable or disable the sending of From and 1797 Referer information. 1799 The User-Agent (Section 9.9) or Server (Section 9.8) header fields 1800 can sometimes be used to determine that a specific client or server 1801 have a particular security hole which might be exploited. 1802 Unfortunately, this same information is often used for other valuable 1803 purposes for which HTTP currently has no better mechanism. 1805 11.2. Encoding Sensitive Information in URIs 1807 Because the source of a link might be private information or might 1808 reveal an otherwise private information source, it is strongly 1809 recommended that the user be able to select whether or not the 1810 Referer field is sent. For example, a browser client could have a 1811 toggle switch for browsing openly/anonymously, which would 1812 respectively enable/disable the sending of Referer and From 1813 information. 1815 Clients SHOULD NOT include a Referer header field in a (non-secure) 1816 HTTP request if the referring page was transferred with a secure 1817 protocol. 1819 Authors of services should not use GET-based forms for the submission 1820 of sensitive data because that data will be encoded in the Request- 1821 target. Many existing servers, proxies, and user agents log or 1822 display the Request-target in places where it might be visible to 1823 third parties. Such services can use POST-based form submission 1824 instead. 1826 11.3. Location Headers and Spoofing 1828 If a single server supports multiple organizations that do not trust 1829 one another, then it MUST check the values of Location and Content- 1830 Location headers in responses that are generated under control of 1831 said organizations to make sure that they do not attempt to 1832 invalidate resources over which they have no authority. 1834 12. Acknowledgments 1836 13. References 1838 13.1. Normative References 1840 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1841 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1842 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 1843 and Message Parsing", draft-ietf-httpbis-p1-messaging-07 1844 (work in progress), July 2009. 1846 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1847 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1848 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 1849 and Content Negotiation", draft-ietf-httpbis-p3-payload-07 1850 (work in progress), July 2009. 1852 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1853 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1854 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 1855 Requests", draft-ietf-httpbis-p4-conditional-07 (work in 1856 progress), July 2009. 1858 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1859 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1860 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 1861 Partial Responses", draft-ietf-httpbis-p5-range-07 (work 1862 in progress), July 2009. 1864 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1865 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1866 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part 1867 6: Caching", draft-ietf-httpbis-p6-cache-07 (work in 1868 progress), July 2009. 1870 [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1871 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1872 and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", 1873 draft-ietf-httpbis-p7-auth-07 (work in progress), 1874 July 2009. 1876 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1877 Requirement Levels", BCP 14, RFC 2119, March 1997. 1879 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1880 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1882 13.2. Informative References 1884 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1885 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1887 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 1888 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 1889 RFC 2068, January 1997. 1891 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1892 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1893 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1895 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 1896 HTTP/1.1", RFC 2817, May 2000. 1898 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1899 Procedures for Message Header Fields", BCP 90, RFC 3864, 1900 September 2004. 1902 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1903 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1904 May 2008. 1906 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 1907 October 2008. 1909 Appendix A. Compatibility with Previous Versions 1911 A.1. Changes from RFC 2068 1913 Clarified which error code should be used for inbound server failures 1914 (e.g. DNS failures). (Section 8.5.5). 1916 201 (Created) had a race that required an Etag be sent when a 1917 resource is first created. (Section 8.2.2). 1919 Rewrite of message transmission requirements to make it much harder 1920 for implementors to get it wrong, as the consequences of errors here 1921 can have significant impact on the Internet, and to deal with the 1922 following problems: 1924 1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where 1925 this was incorrectly placing a requirement on the behavior of an 1926 implementation of a future version of HTTP/1.x 1928 2. Made it clear that user-agents should retry requests, not 1929 "clients" in general. 1931 3. Converted requirements for clients to ignore unexpected 100 1932 (Continue) responses, and for proxies to forward 100 responses, 1933 into a general requirement for 1xx responses. 1935 4. Modified some TCP-specific language, to make it clearer that non- 1936 TCP transports are possible for HTTP. 1938 5. Require that the origin server MUST NOT wait for the request body 1939 before it sends a required 100 (Continue) response. 1941 6. Allow, rather than require, a server to omit 100 (Continue) if it 1942 has already seen some of the request body. 1944 7. Allow servers to defend against denial-of-service attacks and 1945 broken clients. 1947 This change adds the Expect header and 417 status code. 1949 Clean up confusion between 403 and 404 responses. (Section 8.4.4, 1950 8.4.5, and 8.4.11) 1952 The PATCH, LINK, UNLINK methods were defined but not commonly 1953 implemented in previous versions of this specification. See Section 1954 19.6.1 of [RFC2068]. 1956 A.2. Changes from RFC 2616 1958 This document takes over the Status Code Registry, previously defined 1959 in Section 7.1 of [RFC2817]. (Section 4.1) 1961 Clarify definition of POST. (Section 7.5) 1963 Failed to consider that there are many other request methods that are 1964 safe to automatically redirect, and further that the user agent is 1965 able to make that determination based on the request method 1966 semantics. (Sections 8.3.2, 8.3.3 and 8.3.8) 1968 Deprecate 305 Use Proxy status code, because user agents did not 1969 implement it. It used to indicate that the requested resource must 1970 be accessed through the proxy given by the Location field. The 1971 Location field gave the URI of the proxy. The recipient was expected 1972 to repeat this single request via the proxy. (Section 8.3.6) 1974 Reclassify Allow header as response header, removing the option to 1975 specify it in a PUT request. Relax the server requirement on the 1976 contents of the Allow header and remove requirement on clients to 1977 always trust the header value. (Section 9.1) 1979 Correct syntax of Location header to allow fragment, as referred 1980 symbol wasn't what was expected, and add some clarifications as to 1981 when it would not be appropriate. (Section 9.4) 1983 Allow Referer value of "about:blank" as alternative to not specifying 1984 it. (Section 9.6) 1986 In the description of the Server header, the Via field was described 1987 as a SHOULD. The requirement was and is stated correctly in the 1988 description of the Via header in Section 8.9 of [Part1]. 1989 (Section 9.8) 1991 Appendix B. Collected ABNF 1993 Accept = 1994 Accept-Charset = 1995 Accept-Encoding = 1996 Accept-Language = 1997 Accept-Ranges = 1998 Age = 1999 Allow = "Allow:" OWS Allow-v 2000 Allow-v = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] 2001 Authorization = 2003 ETag = 2004 Expect = "Expect:" OWS Expect-v 2005 Expect-v = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) 2007 From = "From:" OWS From-v 2008 From-v = mailbox 2010 HTTP-date = 2011 Host = 2012 If-Match = 2013 If-Modified-Since = 2014 2015 If-None-Match = 2016 If-Range = 2017 If-Unmodified-Since = 2018 2020 Location = "Location:" OWS Location-v 2021 Location-v = absolute-URI [ "#" fragment ] 2023 Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v 2024 Max-Forwards-v = 1*DIGIT 2025 Method = %x4F.50.54.49.4F.4E.53 ; OPTIONS 2026 / %x47.45.54 ; GET 2027 / %x48.45.41.44 ; HEAD 2028 / %x50.4F.53.54 ; POST 2029 / %x50.55.54 ; PUT 2030 / %x44.45.4C.45.54.45 ; DELETE 2031 / %x54.52.41.43.45 ; TRACE 2032 / %x43.4F.4E.4E.45.43.54 ; CONNECT 2033 / extension-method 2035 OWS = 2037 Proxy-Authenticate = 2038 2039 Proxy-Authorization = 2040 2042 RWS = 2043 Range = 2044 Reason-Phrase = *( WSP / VCHAR / obs-text ) 2045 Referer = "Referer:" OWS Referer-v 2046 Referer-v = absolute-URI / partial-URI 2047 Retry-After = "Retry-After:" OWS Retry-After-v 2048 Retry-After-v = HTTP-date / delta-seconds 2050 Server = "Server:" OWS Server-v 2051 Server-v = product *( RWS ( product / comment ) ) 2052 Status-Code = "100" / "101" / "200" / "201" / "202" / "203" / "204" / 2053 "205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" / 2054 "307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" / 2055 "407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" / 2056 "415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" / 2057 "505" / extension-code 2059 TE = 2060 User-Agent = "User-Agent:" OWS User-Agent-v 2061 User-Agent-v = product *( RWS ( product / comment ) ) 2063 Vary = 2065 WWW-Authenticate = 2066 2068 absolute-URI = 2070 comment = 2072 delta-seconds = 1*DIGIT 2074 expect-params = ";" token [ "=" ( token / quoted-string ) ] 2075 expectation = "100-continue" / expectation-extension 2076 expectation-extension = token [ "=" ( token / quoted-string ) 2077 *expect-params ] 2078 extension-code = 3DIGIT 2079 extension-method = token 2081 fragment = 2083 mailbox = 2085 obs-text = 2087 partial-URI = 2088 product = 2090 quoted-string = 2092 request-header = Accept / Accept-Charset / Accept-Encoding / 2093 Accept-Language / Authorization / Expect / From / Host / If-Match / 2094 If-Modified-Since / If-None-Match / If-Range / If-Unmodified-Since / 2095 Max-Forwards / Proxy-Authorization / Range / Referer / TE / 2096 User-Agent 2097 response-header = Accept-Ranges / Age / Allow / ETag / Location / 2098 Proxy-Authenticate / Retry-After / Server / Vary / WWW-Authenticate 2100 token = 2101 ABNF diagnostics: 2103 ; Reason-Phrase defined but not used 2104 ; Status-Code defined but not used 2105 ; request-header defined but not used 2106 ; response-header defined but not used 2108 Appendix C. Change Log (to be removed by RFC Editor before publication) 2110 C.1. Since RFC2616 2112 Extracted relevant partitions from [RFC2616]. 2114 C.2. Since draft-ietf-httpbis-p2-semantics-00 2116 Closed issues: 2118 o : "Via is a MUST" 2119 () 2121 o : "Fragments 2122 allowed in Location" 2123 () 2125 o : "Safe Methods 2126 vs Redirection" () 2128 o : "Revise 2129 description of the POST method" 2130 () 2132 o : "Normative and 2133 Informative references" 2135 o : "RFC2606 2136 Compliance" 2138 o : "Informative 2139 references" 2141 o : "Redundant 2142 cross-references" 2144 Other changes: 2146 o Move definitions of 304 and 412 condition codes to [Part4] 2148 C.3. Since draft-ietf-httpbis-p2-semantics-01 2150 Closed issues: 2152 o : "PUT side 2153 effects" 2155 o : "Duplicate Host 2156 header requirements" 2158 Ongoing work on ABNF conversion 2159 (): 2161 o Move "Product Tokens" section (back) into Part 1, as "token" is 2162 used in the definition of the Upgrade header. 2164 o Add explicit references to BNF syntax and rules imported from 2165 other parts of the specification. 2167 o Copy definition of delta-seconds from Part6 instead of referencing 2168 it. 2170 C.4. Since draft-ietf-httpbis-p2-semantics-02 2172 Closed issues: 2174 o : "Requiring 2175 Allow in 405 responses" 2177 o : "Status Code 2178 Registry" 2180 o : "Redirection 2181 vs. Location" 2183 o : "Cacheability 2184 of 303 response" 2186 o : "305 Use Proxy" 2188 o : 2189 "Classification for Allow header" 2191 o : "PUT - 'store 2192 under' vs 'store at'" 2194 Ongoing work on IANA Message Header Registration 2195 (): 2197 o Reference RFC 3984, and update header registrations for headers 2198 defined in this document. 2200 Ongoing work on ABNF conversion 2201 (): 2203 o Replace string literals when the string really is case-sensitive 2204 (method). 2206 C.5. Since draft-ietf-httpbis-p2-semantics-03 2208 Closed issues: 2210 o : "OPTIONS 2211 request bodies" 2213 o : "Description 2214 of CONNECT should refer to RFC2817" 2216 o : "Location 2217 Content-Location reference request/response mixup" 2219 Ongoing work on Method Registry 2220 (): 2222 o Added initial proposal for registration process, plus initial 2223 content (non-HTTP/1.1 methods to be added by a separate 2224 specification). 2226 C.6. Since draft-ietf-httpbis-p2-semantics-04 2228 Closed issues: 2230 o : "Content-*" 2232 o : "RFC 2822 is 2233 updated by RFC 5322" 2235 Ongoing work on ABNF conversion 2236 (): 2238 o Use "/" instead of "|" for alternatives. 2240 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 2241 whitespace ("OWS") and required whitespace ("RWS"). 2243 o Rewrite ABNFs to spell out whitespace rules, factor out header 2244 value format definitions. 2246 C.7. Since draft-ietf-httpbis-p2-semantics-05 2248 Closed issues: 2250 o : "Reason-Phrase 2251 BNF" 2253 Final work on ABNF conversion 2254 (): 2256 o Add appendix containing collected and expanded ABNF, reorganize 2257 ABNF introduction. 2259 C.8. Since draft-ietf-httpbis-p2-semantics-06 2261 Closed issues: 2263 o : "Clarify when 2264 Referer is sent" 2266 o : "status codes 2267 vs methods" 2269 o : "Do not 2270 require "updates" relation for specs that register status codes or 2271 method names" 2273 Index 2275 1 2276 100 Continue (status code) 20 2277 101 Switching Protocols (status code) 20 2279 2 2280 200 OK (status code) 20 2281 201 Created (status code) 21 2282 202 Accepted (status code) 21 2283 203 Non-Authoritative Information (status code) 21 2284 204 No Content (status code) 22 2285 205 Reset Content (status code) 22 2286 206 Partial Content (status code) 22 2288 3 2289 300 Multiple Choices (status code) 23 2290 301 Moved Permanently (status code) 23 2291 302 Found (status code) 24 2292 303 See Other (status code) 24 2293 304 Not Modified (status code) 25 2294 305 Use Proxy (status code) 25 2295 306 (Unused) (status code) 25 2296 307 Temporary Redirect (status code) 25 2298 4 2299 400 Bad Request (status code) 26 2300 401 Unauthorized (status code) 26 2301 402 Payment Required (status code) 26 2302 403 Forbidden (status code) 26 2303 404 Not Found (status code) 27 2304 405 Method Not Allowed (status code) 27 2305 406 Not Acceptable (status code) 27 2306 407 Proxy Authentication Required (status code) 27 2307 408 Request Timeout (status code) 28 2308 409 Conflict (status code) 28 2309 410 Gone (status code) 28 2310 411 Length Required (status code) 29 2311 412 Precondition Failed (status code) 29 2312 413 Request Entity Too Large (status code) 29 2313 414 URI Too Long (status code) 29 2314 415 Unsupported Media Type (status code) 29 2315 416 Requested Range Not Satisfiable (status code) 29 2316 417 Expectation Failed (status code) 30 2318 5 2319 500 Internal Server Error (status code) 30 2320 501 Not Implemented (status code) 30 2321 502 Bad Gateway (status code) 30 2322 503 Service Unavailable (status code) 30 2323 504 Gateway Timeout (status code) 31 2324 505 HTTP Version Not Supported (status code) 31 2326 A 2327 Allow header 31 2329 C 2330 CONNECT method 19 2332 D 2333 DELETE method 18 2335 E 2336 Expect header 32 2338 F 2339 From header 33 2341 G 2342 GET method 15 2343 Grammar 2344 Allow 31 2345 Allow-v 31 2346 delta-seconds 36 2347 Expect 32 2348 expect-params 32 2349 Expect-v 32 2350 expectation 32 2351 expectation-extension 32 2352 extension-code 11 2353 extension-method 8 2354 From 33 2355 From-v 33 2356 Location 33 2357 Location-v 33 2358 Max-Forwards 34 2359 Max-Forwards-v 34 2360 Method 8 2361 Reason-Phrase 11 2362 Referer 35 2363 Referer-v 35 2364 request-header 9 2365 response-header 12 2366 Retry-After 35 2367 Retry-After-v 35 2368 Server 36 2369 Server-v 36 2370 Status-Code 11 2371 User-Agent 37 2372 User-Agent-v 37 2374 H 2375 HEAD method 16 2376 Headers 2377 Allow 31 2378 Expect 32 2379 From 33 2380 Location 33 2381 Max-Forwards 34 2382 Referer 35 2383 Retry-After 35 2384 Server 36 2385 User-Agent 36 2387 I 2388 Idempotent Methods 14 2390 L 2391 LINK method 43 2392 Location header 33 2394 M 2395 Max-Forwards header 34 2396 Methods 2397 CONNECT 19 2398 DELETE 18 2399 GET 15 2400 HEAD 16 2401 LINK 43 2402 OPTIONS 14 2403 PATCH 43 2404 POST 16 2405 PUT 17 2406 TRACE 18 2407 UNLINK 43 2409 O 2410 OPTIONS method 14 2412 P 2413 PATCH method 43 2414 POST method 16 2415 PUT method 17 2417 R 2418 Referer header 35 2419 Retry-After header 35 2421 S 2422 Safe Methods 13 2423 Server header 36 2424 Status Codes 2425 100 Continue 20 2426 101 Switching Protocols 20 2427 200 OK 20 2428 201 Created 21 2429 202 Accepted 21 2430 203 Non-Authoritative Information 21 2431 204 No Content 22 2432 205 Reset Content 22 2433 206 Partial Content 22 2434 300 Multiple Choices 23 2435 301 Moved Permanently 23 2436 302 Found 24 2437 303 See Other 24 2438 304 Not Modified 25 2439 305 Use Proxy 25 2440 306 (Unused) 25 2441 307 Temporary Redirect 25 2442 400 Bad Request 26 2443 401 Unauthorized 26 2444 402 Payment Required 26 2445 403 Forbidden 26 2446 404 Not Found 27 2447 405 Method Not Allowed 27 2448 406 Not Acceptable 27 2449 407 Proxy Authentication Required 27 2450 408 Request Timeout 28 2451 409 Conflict 28 2452 410 Gone 28 2453 411 Length Required 29 2454 412 Precondition Failed 29 2455 413 Request Entity Too Large 29 2456 414 URI Too Long 29 2457 415 Unsupported Media Type 29 2458 416 Requested Range Not Satisfiable 29 2459 417 Expectation Failed 30 2460 500 Internal Server Error 30 2461 501 Not Implemented 30 2462 502 Bad Gateway 30 2463 503 Service Unavailable 30 2464 504 Gateway Timeout 31 2465 505 HTTP Version Not Supported 31 2467 T 2468 TRACE method 18 2470 U 2471 UNLINK method 43 2472 User-Agent header 36 2474 Authors' Addresses 2476 Roy T. Fielding (editor) 2477 Day Software 2478 23 Corporate Plaza DR, Suite 280 2479 Newport Beach, CA 92660 2480 USA 2482 Phone: +1-949-706-5300 2483 Fax: +1-949-706-5305 2484 Email: fielding@gbiv.com 2485 URI: http://roy.gbiv.com/ 2487 Jim Gettys 2488 One Laptop per Child 2489 21 Oak Knoll Road 2490 Carlisle, MA 01741 2491 USA 2493 Email: jg@laptop.org 2494 URI: http://www.laptop.org/ 2496 Jeffrey C. Mogul 2497 Hewlett-Packard Company 2498 HP Labs, Large Scale Systems Group 2499 1501 Page Mill Road, MS 1177 2500 Palo Alto, CA 94304 2501 USA 2503 Email: JeffMogul@acm.org 2505 Henrik Frystyk Nielsen 2506 Microsoft Corporation 2507 1 Microsoft Way 2508 Redmond, WA 98052 2509 USA 2511 Email: henrikn@microsoft.com 2512 Larry Masinter 2513 Adobe Systems, Incorporated 2514 345 Park Ave 2515 San Jose, CA 95110 2516 USA 2518 Email: LMM@acm.org 2519 URI: http://larry.masinter.net/ 2521 Paul J. Leach 2522 Microsoft Corporation 2523 1 Microsoft Way 2524 Redmond, WA 98052 2526 Email: paulle@microsoft.com 2528 Tim Berners-Lee 2529 World Wide Web Consortium 2530 MIT Computer Science and Artificial Intelligence Laboratory 2531 The Stata Center, Building 32 2532 32 Vassar Street 2533 Cambridge, MA 02139 2534 USA 2536 Email: timbl@w3.org 2537 URI: http://www.w3.org/People/Berners-Lee/ 2539 Yves Lafon (editor) 2540 World Wide Web Consortium 2541 W3C / ERCIM 2542 2004, rte des Lucioles 2543 Sophia-Antipolis, AM 06902 2544 France 2546 Email: ylafon@w3.org 2547 URI: http://www.raubacapeu.net/people/yves/ 2548 Julian F. Reschke (editor) 2549 greenbytes GmbH 2550 Hafenweg 16 2551 Muenster, NW 48155 2552 Germany 2554 Phone: +49 251 2807760 2555 Fax: +49 251 2807761 2556 Email: julian.reschke@greenbytes.de 2557 URI: http://greenbytes.de/tech/webdav/