| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | Network Working Group T. Berners-Lee |
| 8 | Request for Comments: 1945 MIT/LCS |
| 9 | Category: Informational R. Fielding |
| 10 | UC Irvine |
| 11 | H. Frystyk |
| 12 | MIT/LCS |
| 13 | May 1996 |
| 14 | |
| 15 | |
| 16 | Hypertext Transfer Protocol -- HTTP/1.0 |
| 17 | |
| 18 | Status of This Memo |
| 19 | |
| 20 | This memo provides information for the Internet community. This memo |
| 21 | does not specify an Internet standard of any kind. Distribution of |
| 22 | this memo is unlimited. |
| 23 | |
| 24 | IESG Note: |
| 25 | |
| 26 | The IESG has concerns about this protocol, and expects this document |
| 27 | to be replaced relatively soon by a standards track document. |
| 28 | |
| 29 | Abstract |
| 30 | |
| 31 | The Hypertext Transfer Protocol (HTTP) is an application-level |
| 32 | protocol with the lightness and speed necessary for distributed, |
| 33 | collaborative, hypermedia information systems. It is a generic, |
| 34 | stateless, object-oriented protocol which can be used for many tasks, |
| 35 | such as name servers and distributed object management systems, |
| 36 | through extension of its request methods (commands). A feature of |
| 37 | HTTP is the typing of data representation, allowing systems to be |
| 38 | built independently of the data being transferred. |
| 39 | |
| 40 | HTTP has been in use by the World-Wide Web global information |
| 41 | initiative since 1990. This specification reflects common usage of |
| 42 | the protocol referred to as "HTTP/1.0". |
| 43 | |
| 44 | Table of Contents |
| 45 | |
| 46 | 1. Introduction .............................................. 4 |
| 47 | 1.1 Purpose .............................................. 4 |
| 48 | 1.2 Terminology .......................................... 4 |
| 49 | 1.3 Overall Operation .................................... 6 |
| 50 | 1.4 HTTP and MIME ........................................ 8 |
| 51 | 2. Notational Conventions and Generic Grammar ................ 8 |
| 52 | 2.1 Augmented BNF ........................................ 8 |
| 53 | 2.2 Basic Rules .......................................... 10 |
| 54 | 3. Protocol Parameters ....................................... 12 |
| 55 | |
| 56 | |
| 57 | |
| 58 | Berners-Lee, et al Informational [Page 1] |
| 59 | \f |
| 60 | RFC 1945 HTTP/1.0 May 1996 |
| 61 | |
| 62 | |
| 63 | 3.1 HTTP Version ......................................... 12 |
| 64 | 3.2 Uniform Resource Identifiers ......................... 14 |
| 65 | 3.2.1 General Syntax ................................ 14 |
| 66 | 3.2.2 http URL ...................................... 15 |
| 67 | 3.3 Date/Time Formats .................................... 15 |
| 68 | 3.4 Character Sets ....................................... 17 |
| 69 | 3.5 Content Codings ...................................... 18 |
| 70 | 3.6 Media Types .......................................... 19 |
| 71 | 3.6.1 Canonicalization and Text Defaults ............ 19 |
| 72 | 3.6.2 Multipart Types ............................... 20 |
| 73 | 3.7 Product Tokens ....................................... 20 |
| 74 | 4. HTTP Message .............................................. 21 |
| 75 | 4.1 Message Types ........................................ 21 |
| 76 | 4.2 Message Headers ...................................... 22 |
| 77 | 4.3 General Header Fields ................................ 23 |
| 78 | 5. Request ................................................... 23 |
| 79 | 5.1 Request-Line ......................................... 23 |
| 80 | 5.1.1 Method ........................................ 24 |
| 81 | 5.1.2 Request-URI ................................... 24 |
| 82 | 5.2 Request Header Fields ................................ 25 |
| 83 | 6. Response .................................................. 25 |
| 84 | 6.1 Status-Line .......................................... 26 |
| 85 | 6.1.1 Status Code and Reason Phrase ................. 26 |
| 86 | 6.2 Response Header Fields ............................... 28 |
| 87 | 7. Entity .................................................... 28 |
| 88 | 7.1 Entity Header Fields ................................. 29 |
| 89 | 7.2 Entity Body .......................................... 29 |
| 90 | 7.2.1 Type .......................................... 29 |
| 91 | 7.2.2 Length ........................................ 30 |
| 92 | 8. Method Definitions ........................................ 30 |
| 93 | 8.1 GET .................................................. 31 |
| 94 | 8.2 HEAD ................................................. 31 |
| 95 | 8.3 POST ................................................. 31 |
| 96 | 9. Status Code Definitions ................................... 32 |
| 97 | 9.1 Informational 1xx .................................... 32 |
| 98 | 9.2 Successful 2xx ....................................... 32 |
| 99 | 9.3 Redirection 3xx ...................................... 34 |
| 100 | 9.4 Client Error 4xx ..................................... 35 |
| 101 | 9.5 Server Error 5xx ..................................... 37 |
| 102 | 10. Header Field Definitions .................................. 37 |
| 103 | 10.1 Allow ............................................... 38 |
| 104 | 10.2 Authorization ....................................... 38 |
| 105 | 10.3 Content-Encoding .................................... 39 |
| 106 | 10.4 Content-Length ...................................... 39 |
| 107 | 10.5 Content-Type ........................................ 40 |
| 108 | 10.6 Date ................................................ 40 |
| 109 | 10.7 Expires ............................................. 41 |
| 110 | 10.8 From ................................................ 42 |
| 111 | |
| 112 | |
| 113 | |
| 114 | Berners-Lee, et al Informational [Page 2] |
| 115 | \f |
| 116 | RFC 1945 HTTP/1.0 May 1996 |
| 117 | |
| 118 | |
| 119 | 10.9 If-Modified-Since ................................... 42 |
| 120 | 10.10 Last-Modified ....................................... 43 |
| 121 | 10.11 Location ............................................ 44 |
| 122 | 10.12 Pragma .............................................. 44 |
| 123 | 10.13 Referer ............................................. 44 |
| 124 | 10.14 Server .............................................. 45 |
| 125 | 10.15 User-Agent .......................................... 46 |
| 126 | 10.16 WWW-Authenticate .................................... 46 |
| 127 | 11. Access Authentication ..................................... 47 |
| 128 | 11.1 Basic Authentication Scheme ......................... 48 |
| 129 | 12. Security Considerations ................................... 49 |
| 130 | 12.1 Authentication of Clients ........................... 49 |
| 131 | 12.2 Safe Methods ........................................ 49 |
| 132 | 12.3 Abuse of Server Log Information ..................... 50 |
| 133 | 12.4 Transfer of Sensitive Information ................... 50 |
| 134 | 12.5 Attacks Based On File and Path Names ................ 51 |
| 135 | 13. Acknowledgments ........................................... 51 |
| 136 | 14. References ................................................ 52 |
| 137 | 15. Authors' Addresses ........................................ 54 |
| 138 | Appendix A. Internet Media Type message/http ................ 55 |
| 139 | Appendix B. Tolerant Applications ........................... 55 |
| 140 | Appendix C. Relationship to MIME ............................ 56 |
| 141 | C.1 Conversion to Canonical Form ......................... 56 |
| 142 | C.2 Conversion of Date Formats ........................... 57 |
| 143 | C.3 Introduction of Content-Encoding ..................... 57 |
| 144 | C.4 No Content-Transfer-Encoding ......................... 57 |
| 145 | C.5 HTTP Header Fields in Multipart Body-Parts ........... 57 |
| 146 | Appendix D. Additional Features ............................. 57 |
| 147 | D.1 Additional Request Methods ........................... 58 |
| 148 | D.1.1 PUT ........................................... 58 |
| 149 | D.1.2 DELETE ........................................ 58 |
| 150 | D.1.3 LINK .......................................... 58 |
| 151 | D.1.4 UNLINK ........................................ 58 |
| 152 | D.2 Additional Header Field Definitions .................. 58 |
| 153 | D.2.1 Accept ........................................ 58 |
| 154 | D.2.2 Accept-Charset ................................ 59 |
| 155 | D.2.3 Accept-Encoding ............................... 59 |
| 156 | D.2.4 Accept-Language ............................... 59 |
| 157 | D.2.5 Content-Language .............................. 59 |
| 158 | D.2.6 Link .......................................... 59 |
| 159 | D.2.7 MIME-Version .................................. 59 |
| 160 | D.2.8 Retry-After ................................... 60 |
| 161 | D.2.9 Title ......................................... 60 |
| 162 | D.2.10 URI ........................................... 60 |
| 163 | |
| 164 | |
| 165 | |
| 166 | |
| 167 | |
| 168 | |
| 169 | |
| 170 | Berners-Lee, et al Informational [Page 3] |
| 171 | \f |
| 172 | RFC 1945 HTTP/1.0 May 1996 |
| 173 | |
| 174 | |
| 175 | 1. Introduction |
| 176 | |
| 177 | 1.1 Purpose |
| 178 | |
| 179 | The Hypertext Transfer Protocol (HTTP) is an application-level |
| 180 | protocol with the lightness and speed necessary for distributed, |
| 181 | collaborative, hypermedia information systems. HTTP has been in use |
| 182 | by the World-Wide Web global information initiative since 1990. This |
| 183 | specification reflects common usage of the protocol referred too as |
| 184 | "HTTP/1.0". This specification describes the features that seem to be |
| 185 | consistently implemented in most HTTP/1.0 clients and servers. The |
| 186 | specification is split into two sections. Those features of HTTP for |
| 187 | which implementations are usually consistent are described in the |
| 188 | main body of this document. Those features which have few or |
| 189 | inconsistent implementations are listed in Appendix D. |
| 190 | |
| 191 | Practical information systems require more functionality than simple |
| 192 | retrieval, including search, front-end update, and annotation. HTTP |
| 193 | allows an open-ended set of methods to be used to indicate the |
| 194 | purpose of a request. It builds on the discipline of reference |
| 195 | provided by the Uniform Resource Identifier (URI) [2], as a location |
| 196 | (URL) [4] or name (URN) [16], for indicating the resource on which a |
| 197 | method is to be applied. Messages are passed in a format similar to |
| 198 | that used by Internet Mail [7] and the Multipurpose Internet Mail |
| 199 | Extensions (MIME) [5]. |
| 200 | |
| 201 | HTTP is also used as a generic protocol for communication between |
| 202 | user agents and proxies/gateways to other Internet protocols, such as |
| 203 | SMTP [12], NNTP [11], FTP [14], Gopher [1], and WAIS [8], allowing |
| 204 | basic hypermedia access to resources available from diverse |
| 205 | applications and simplifying the implementation of user agents. |
| 206 | |
| 207 | 1.2 Terminology |
| 208 | |
| 209 | This specification uses a number of terms to refer to the roles |
| 210 | played by participants in, and objects of, the HTTP communication. |
| 211 | |
| 212 | connection |
| 213 | |
| 214 | A transport layer virtual circuit established between two |
| 215 | application programs for the purpose of communication. |
| 216 | |
| 217 | message |
| 218 | |
| 219 | The basic unit of HTTP communication, consisting of a structured |
| 220 | sequence of octets matching the syntax defined in Section 4 and |
| 221 | transmitted via the connection. |
| 222 | |
| 223 | |
| 224 | |
| 225 | |
| 226 | Berners-Lee, et al Informational [Page 4] |
| 227 | \f |
| 228 | RFC 1945 HTTP/1.0 May 1996 |
| 229 | |
| 230 | |
| 231 | request |
| 232 | |
| 233 | An HTTP request message (as defined in Section 5). |
| 234 | |
| 235 | response |
| 236 | |
| 237 | An HTTP response message (as defined in Section 6). |
| 238 | |
| 239 | resource |
| 240 | |
| 241 | A network data object or service which can be identified by a |
| 242 | URI (Section 3.2). |
| 243 | |
| 244 | entity |
| 245 | |
| 246 | A particular representation or rendition of a data resource, or |
| 247 | reply from a service resource, that may be enclosed within a |
| 248 | request or response message. An entity consists of |
| 249 | metainformation in the form of entity headers and content in the |
| 250 | form of an entity body. |
| 251 | |
| 252 | client |
| 253 | |
| 254 | An application program that establishes connections for the |
| 255 | purpose of sending requests. |
| 256 | |
| 257 | user agent |
| 258 | |
| 259 | The client which initiates a request. These are often browsers, |
| 260 | editors, spiders (web-traversing robots), or other end user |
| 261 | tools. |
| 262 | |
| 263 | server |
| 264 | |
| 265 | An application program that accepts connections in order to |
| 266 | service requests by sending back responses. |
| 267 | |
| 268 | origin server |
| 269 | |
| 270 | The server on which a given resource resides or is to be created. |
| 271 | |
| 272 | proxy |
| 273 | |
| 274 | An intermediary program which acts as both a server and a client |
| 275 | for the purpose of making requests on behalf of other clients. |
| 276 | Requests are serviced internally or by passing them, with |
| 277 | possible translation, on to other servers. A proxy must |
| 278 | interpret and, if necessary, rewrite a request message before |
| 279 | |
| 280 | |
| 281 | |
| 282 | Berners-Lee, et al Informational [Page 5] |
| 283 | \f |
| 284 | RFC 1945 HTTP/1.0 May 1996 |
| 285 | |
| 286 | |
| 287 | forwarding it. Proxies are often used as client-side portals |
| 288 | through network firewalls and as helper applications for |
| 289 | handling requests via protocols not implemented by the user |
| 290 | agent. |
| 291 | |
| 292 | gateway |
| 293 | |
| 294 | A server which acts as an intermediary for some other server. |
| 295 | Unlike a proxy, a gateway receives requests as if it were the |
| 296 | origin server for the requested resource; the requesting client |
| 297 | may not be aware that it is communicating with a gateway. |
| 298 | Gateways are often used as server-side portals through network |
| 299 | firewalls and as protocol translators for access to resources |
| 300 | stored on non-HTTP systems. |
| 301 | |
| 302 | tunnel |
| 303 | |
| 304 | A tunnel is an intermediary program which is acting as a blind |
| 305 | relay between two connections. Once active, a tunnel is not |
| 306 | considered a party to the HTTP communication, though the tunnel |
| 307 | may have been initiated by an HTTP request. The tunnel ceases to |
| 308 | exist when both ends of the relayed connections are closed. |
| 309 | Tunnels are used when a portal is necessary and the intermediary |
| 310 | cannot, or should not, interpret the relayed communication. |
| 311 | |
| 312 | cache |
| 313 | |
| 314 | A program's local store of response messages and the subsystem |
| 315 | that controls its message storage, retrieval, and deletion. A |
| 316 | cache stores cachable responses in order to reduce the response |
| 317 | time and network bandwidth consumption on future, equivalent |
| 318 | requests. Any client or server may include a cache, though a |
| 319 | cache cannot be used by a server while it is acting as a tunnel. |
| 320 | |
| 321 | Any given program may be capable of being both a client and a server; |
| 322 | our use of these terms refers only to the role being performed by the |
| 323 | program for a particular connection, rather than to the program's |
| 324 | capabilities in general. Likewise, any server may act as an origin |
| 325 | server, proxy, gateway, or tunnel, switching behavior based on the |
| 326 | nature of each request. |
| 327 | |
| 328 | 1.3 Overall Operation |
| 329 | |
| 330 | The HTTP protocol is based on a request/response paradigm. A client |
| 331 | establishes a connection with a server and sends a request to the |
| 332 | server in the form of a request method, URI, and protocol version, |
| 333 | followed by a MIME-like message containing request modifiers, client |
| 334 | information, and possible body content. The server responds with a |
| 335 | |
| 336 | |
| 337 | |
| 338 | Berners-Lee, et al Informational [Page 6] |
| 339 | \f |
| 340 | RFC 1945 HTTP/1.0 May 1996 |
| 341 | |
| 342 | |
| 343 | status line, including the message's protocol version and a success |
| 344 | or error code, followed by a MIME-like message containing server |
| 345 | information, entity metainformation, and possible body content. |
| 346 | |
| 347 | Most HTTP communication is initiated by a user agent and consists of |
| 348 | a request to be applied to a resource on some origin server. In the |
| 349 | simplest case, this may be accomplished via a single connection (v) |
| 350 | between the user agent (UA) and the origin server (O). |
| 351 | |
| 352 | request chain ------------------------> |
| 353 | UA -------------------v------------------- O |
| 354 | <----------------------- response chain |
| 355 | |
| 356 | A more complicated situation occurs when one or more intermediaries |
| 357 | are present in the request/response chain. There are three common |
| 358 | forms of intermediary: proxy, gateway, and tunnel. A proxy is a |
| 359 | forwarding agent, receiving requests for a URI in its absolute form, |
| 360 | rewriting all or parts of the message, and forwarding the reformatted |
| 361 | request toward the server identified by the URI. A gateway is a |
| 362 | receiving agent, acting as a layer above some other server(s) and, if |
| 363 | necessary, translating the requests to the underlying server's |
| 364 | protocol. A tunnel acts as a relay point between two connections |
| 365 | without changing the messages; tunnels are used when the |
| 366 | communication needs to pass through an intermediary (such as a |
| 367 | firewall) even when the intermediary cannot understand the contents |
| 368 | of the messages. |
| 369 | |
| 370 | request chain --------------------------------------> |
| 371 | UA -----v----- A -----v----- B -----v----- C -----v----- O |
| 372 | <------------------------------------- response chain |
| 373 | |
| 374 | The figure above shows three intermediaries (A, B, and C) between the |
| 375 | user agent and origin server. A request or response message that |
| 376 | travels the whole chain must pass through four separate connections. |
| 377 | This distinction is important because some HTTP communication options |
| 378 | may apply only to the connection with the nearest, non-tunnel |
| 379 | neighbor, only to the end-points of the chain, or to all connections |
| 380 | along the chain. Although the diagram is linear, each participant may |
| 381 | be engaged in multiple, simultaneous communications. For example, B |
| 382 | may be receiving requests from many clients other than A, and/or |
| 383 | forwarding requests to servers other than C, at the same time that it |
| 384 | is handling A's request. |
| 385 | |
| 386 | Any party to the communication which is not acting as a tunnel may |
| 387 | employ an internal cache for handling requests. The effect of a cache |
| 388 | is that the request/response chain is shortened if one of the |
| 389 | participants along the chain has a cached response applicable to that |
| 390 | request. The following illustrates the resulting chain if B has a |
| 391 | |
| 392 | |
| 393 | |
| 394 | Berners-Lee, et al Informational [Page 7] |
| 395 | \f |
| 396 | RFC 1945 HTTP/1.0 May 1996 |
| 397 | |
| 398 | |
| 399 | cached copy of an earlier response from O (via C) for a request which |
| 400 | has not been cached by UA or A. |
| 401 | |
| 402 | request chain ----------> |
| 403 | UA -----v----- A -----v----- B - - - - - - C - - - - - - O |
| 404 | <--------- response chain |
| 405 | |
| 406 | Not all responses are cachable, and some requests may contain |
| 407 | modifiers which place special requirements on cache behavior. Some |
| 408 | HTTP/1.0 applications use heuristics to describe what is or is not a |
| 409 | "cachable" response, but these rules are not standardized. |
| 410 | |
| 411 | On the Internet, HTTP communication generally takes place over TCP/IP |
| 412 | connections. The default port is TCP 80 [15], but other ports can be |
| 413 | used. This does not preclude HTTP from being implemented on top of |
| 414 | any other protocol on the Internet, or on other networks. HTTP only |
| 415 | presumes a reliable transport; any protocol that provides such |
| 416 | guarantees can be used, and the mapping of the HTTP/1.0 request and |
| 417 | response structures onto the transport data units of the protocol in |
| 418 | question is outside the scope of this specification. |
| 419 | |
| 420 | Except for experimental applications, current practice requires that |
| 421 | the connection be established by the client prior to each request and |
| 422 | closed by the server after sending the response. Both clients and |
| 423 | servers should be aware that either party may close the connection |
| 424 | prematurely, due to user action, automated time-out, or program |
| 425 | failure, and should handle such closing in a predictable fashion. In |
| 426 | any case, the closing of the connection by either or both parties |
| 427 | always terminates the current request, regardless of its status. |
| 428 | |
| 429 | 1.4 HTTP and MIME |
| 430 | |
| 431 | HTTP/1.0 uses many of the constructs defined for MIME, as defined in |
| 432 | RFC 1521 [5]. Appendix C describes the ways in which the context of |
| 433 | HTTP allows for different use of Internet Media Types than is |
| 434 | typically found in Internet mail, and gives the rationale for those |
| 435 | differences. |
| 436 | |
| 437 | 2. Notational Conventions and Generic Grammar |
| 438 | |
| 439 | 2.1 Augmented BNF |
| 440 | |
| 441 | All of the mechanisms specified in this document are described in |
| 442 | both prose and an augmented Backus-Naur Form (BNF) similar to that |
| 443 | used by RFC 822 [7]. Implementors will need to be familiar with the |
| 444 | notation in order to understand this specification. The augmented BNF |
| 445 | includes the following constructs: |
| 446 | |
| 447 | |
| 448 | |
| 449 | |
| 450 | Berners-Lee, et al Informational [Page 8] |
| 451 | \f |
| 452 | RFC 1945 HTTP/1.0 May 1996 |
| 453 | |
| 454 | |
| 455 | name = definition |
| 456 | |
| 457 | The name of a rule is simply the name itself (without any |
| 458 | enclosing "<" and ">") and is separated from its definition by |
| 459 | the equal character "=". Whitespace is only significant in that |
| 460 | indentation of continuation lines is used to indicate a rule |
| 461 | definition that spans more than one line. Certain basic rules |
| 462 | are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. |
| 463 | Angle brackets are used within definitions whenever their |
| 464 | presence will facilitate discerning the use of rule names. |
| 465 | |
| 466 | "literal" |
| 467 | |
| 468 | Quotation marks surround literal text. Unless stated otherwise, |
| 469 | the text is case-insensitive. |
| 470 | |
| 471 | rule1 | rule2 |
| 472 | |
| 473 | Elements separated by a bar ("I") are alternatives, |
| 474 | e.g., "yes | no" will accept yes or no. |
| 475 | |
| 476 | (rule1 rule2) |
| 477 | |
| 478 | Elements enclosed in parentheses are treated as a single |
| 479 | element. Thus, "(elem (foo | bar) elem)" allows the token |
| 480 | sequences "elem foo elem" and "elem bar elem". |
| 481 | |
| 482 | *rule |
| 483 | |
| 484 | The character "*" preceding an element indicates repetition. The |
| 485 | full form is "<n>*<m>element" indicating at least <n> and at |
| 486 | most <m> occurrences of element. Default values are 0 and |
| 487 | infinity so that "*(element)" allows any number, including zero; |
| 488 | "1*element" requires at least one; and "1*2element" allows one |
| 489 | or two. |
| 490 | |
| 491 | [rule] |
| 492 | |
| 493 | Square brackets enclose optional elements; "[foo bar]" is |
| 494 | equivalent to "*1(foo bar)". |
| 495 | |
| 496 | N rule |
| 497 | |
| 498 | Specific repetition: "<n>(element)" is equivalent to |
| 499 | "<n>*<n>(element)"; that is, exactly <n> occurrences of |
| 500 | (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a |
| 501 | string of three alphabetic characters. |
| 502 | |
| 503 | |
| 504 | |
| 505 | |
| 506 | Berners-Lee, et al Informational [Page 9] |
| 507 | \f |
| 508 | RFC 1945 HTTP/1.0 May 1996 |
| 509 | |
| 510 | |
| 511 | #rule |
| 512 | |
| 513 | A construct "#" is defined, similar to "*", for defining lists |
| 514 | of elements. The full form is "<n>#<m>element" indicating at |
| 515 | least <n> and at most <m> elements, each separated by one or |
| 516 | more commas (",") and optional linear whitespace (LWS). This |
| 517 | makes the usual form of lists very easy; a rule such as |
| 518 | "( *LWS element *( *LWS "," *LWS element ))" can be shown as |
| 519 | "1#element". Wherever this construct is used, null elements are |
| 520 | allowed, but do not contribute to the count of elements present. |
| 521 | That is, "(element), , (element)" is permitted, but counts as |
| 522 | only two elements. Therefore, where at least one element is |
| 523 | required, at least one non-null element must be present. Default |
| 524 | values are 0 and infinity so that "#(element)" allows any |
| 525 | number, including zero; "1#element" requires at least one; and |
| 526 | "1#2element" allows one or two. |
| 527 | |
| 528 | ; comment |
| 529 | |
| 530 | A semi-colon, set off some distance to the right of rule text, |
| 531 | starts a comment that continues to the end of line. This is a |
| 532 | simple way of including useful notes in parallel with the |
| 533 | specifications. |
| 534 | |
| 535 | implied *LWS |
| 536 | |
| 537 | The grammar described by this specification is word-based. |
| 538 | Except where noted otherwise, linear whitespace (LWS) can be |
| 539 | included between any two adjacent words (token or |
| 540 | quoted-string), and between adjacent tokens and delimiters |
| 541 | (tspecials), without changing the interpretation of a field. At |
| 542 | least one delimiter (tspecials) must exist between any two |
| 543 | tokens, since they would otherwise be interpreted as a single |
| 544 | token. However, applications should attempt to follow "common |
| 545 | form" when generating HTTP constructs, since there exist some |
| 546 | implementations that fail to accept anything beyond the common |
| 547 | forms. |
| 548 | |
| 549 | 2.2 Basic Rules |
| 550 | |
| 551 | The following rules are used throughout this specification to |
| 552 | describe basic parsing constructs. The US-ASCII coded character set |
| 553 | is defined by [17]. |
| 554 | |
| 555 | OCTET = <any 8-bit sequence of data> |
| 556 | CHAR = <any US-ASCII character (octets 0 - 127)> |
| 557 | UPALPHA = <any US-ASCII uppercase letter "A".."Z"> |
| 558 | LOALPHA = <any US-ASCII lowercase letter "a".."z"> |
| 559 | |
| 560 | |
| 561 | |
| 562 | Berners-Lee, et al Informational [Page 10] |
| 563 | \f |
| 564 | RFC 1945 HTTP/1.0 May 1996 |
| 565 | |
| 566 | |
| 567 | ALPHA = UPALPHA | LOALPHA |
| 568 | DIGIT = <any US-ASCII digit "0".."9"> |
| 569 | CTL = <any US-ASCII control character |
| 570 | (octets 0 - 31) and DEL (127)> |
| 571 | CR = <US-ASCII CR, carriage return (13)> |
| 572 | LF = <US-ASCII LF, linefeed (10)> |
| 573 | SP = <US-ASCII SP, space (32)> |
| 574 | HT = <US-ASCII HT, horizontal-tab (9)> |
| 575 | <"> = <US-ASCII double-quote mark (34)> |
| 576 | |
| 577 | HTTP/1.0 defines the octet sequence CR LF as the end-of-line marker |
| 578 | for all protocol elements except the Entity-Body (see Appendix B for |
| 579 | tolerant applications). The end-of-line marker within an Entity-Body |
| 580 | is defined by its associated media type, as described in Section 3.6. |
| 581 | |
| 582 | CRLF = CR LF |
| 583 | |
| 584 | HTTP/1.0 headers may be folded onto multiple lines if each |
| 585 | continuation line begins with a space or horizontal tab. All linear |
| 586 | whitespace, including folding, has the same semantics as SP. |
| 587 | |
| 588 | LWS = [CRLF] 1*( SP | HT ) |
| 589 | |
| 590 | However, folding of header lines is not expected by some |
| 591 | applications, and should not be generated by HTTP/1.0 applications. |
| 592 | |
| 593 | The TEXT rule is only used for descriptive field contents and values |
| 594 | that are not intended to be interpreted by the message parser. Words |
| 595 | of *TEXT may contain octets from character sets other than US-ASCII. |
| 596 | |
| 597 | TEXT = <any OCTET except CTLs, |
| 598 | but including LWS> |
| 599 | |
| 600 | Recipients of header field TEXT containing octets outside the US- |
| 601 | ASCII character set may assume that they represent ISO-8859-1 |
| 602 | characters. |
| 603 | |
| 604 | Hexadecimal numeric characters are used in several protocol elements. |
| 605 | |
| 606 | HEX = "A" | "B" | "C" | "D" | "E" | "F" |
| 607 | | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT |
| 608 | |
| 609 | Many HTTP/1.0 header field values consist of words separated by LWS |
| 610 | or special characters. These special characters must be in a quoted |
| 611 | string to be used within a parameter value. |
| 612 | |
| 613 | word = token | quoted-string |
| 614 | |
| 615 | |
| 616 | |
| 617 | |
| 618 | Berners-Lee, et al Informational [Page 11] |
| 619 | \f |
| 620 | RFC 1945 HTTP/1.0 May 1996 |
| 621 | |
| 622 | |
| 623 | token = 1*<any CHAR except CTLs or tspecials> |
| 624 | |
| 625 | tspecials = "(" | ")" | "<" | ">" | "@" |
| 626 | | "," | ";" | ":" | "\" | <"> |
| 627 | | "/" | "[" | "]" | "?" | "=" |
| 628 | | "{" | "}" | SP | HT |
| 629 | |
| 630 | Comments may be included in some HTTP header fields by surrounding |
| 631 | the comment text with parentheses. Comments are only allowed in |
| 632 | fields containing "comment" as part of their field value definition. |
| 633 | In all other fields, parentheses are considered part of the field |
| 634 | value. |
| 635 | |
| 636 | comment = "(" *( ctext | comment ) ")" |
| 637 | ctext = <any TEXT excluding "(" and ")"> |
| 638 | |
| 639 | A string of text is parsed as a single word if it is quoted using |
| 640 | double-quote marks. |
| 641 | |
| 642 | quoted-string = ( <"> *(qdtext) <"> ) |
| 643 | |
| 644 | qdtext = <any CHAR except <"> and CTLs, |
| 645 | but including LWS> |
| 646 | |
| 647 | Single-character quoting using the backslash ("\") character is not |
| 648 | permitted in HTTP/1.0. |
| 649 | |
| 650 | 3. Protocol Parameters |
| 651 | |
| 652 | 3.1 HTTP Version |
| 653 | |
| 654 | HTTP uses a "<major>.<minor>" numbering scheme to indicate versions |
| 655 | of the protocol. The protocol versioning policy is intended to allow |
| 656 | the sender to indicate the format of a message and its capacity for |
| 657 | understanding further HTTP communication, rather than the features |
| 658 | obtained via that communication. No change is made to the version |
| 659 | number for the addition of message components which do not affect |
| 660 | communication behavior or which only add to extensible field values. |
| 661 | The <minor> number is incremented when the changes made to the |
| 662 | protocol add features which do not change the general message parsing |
| 663 | algorithm, but which may add to the message semantics and imply |
| 664 | additional capabilities of the sender. The <major> number is |
| 665 | incremented when the format of a message within the protocol is |
| 666 | changed. |
| 667 | |
| 668 | The version of an HTTP message is indicated by an HTTP-Version field |
| 669 | in the first line of the message. If the protocol version is not |
| 670 | specified, the recipient must assume that the message is in the |
| 671 | |
| 672 | |
| 673 | |
| 674 | Berners-Lee, et al Informational [Page 12] |
| 675 | \f |
| 676 | RFC 1945 HTTP/1.0 May 1996 |
| 677 | |
| 678 | |
| 679 | simple HTTP/0.9 format. |
| 680 | |
| 681 | HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT |
| 682 | |
| 683 | Note that the major and minor numbers should be treated as separate |
| 684 | integers and that each may be incremented higher than a single digit. |
| 685 | Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is |
| 686 | lower than HTTP/12.3. Leading zeros should be ignored by recipients |
| 687 | and never generated by senders. |
| 688 | |
| 689 | This document defines both the 0.9 and 1.0 versions of the HTTP |
| 690 | protocol. Applications sending Full-Request or Full-Response |
| 691 | messages, as defined by this specification, must include an HTTP- |
| 692 | Version of "HTTP/1.0". |
| 693 | |
| 694 | HTTP/1.0 servers must: |
| 695 | |
| 696 | o recognize the format of the Request-Line for HTTP/0.9 and |
| 697 | HTTP/1.0 requests; |
| 698 | |
| 699 | o understand any valid request in the format of HTTP/0.9 or |
| 700 | HTTP/1.0; |
| 701 | |
| 702 | o respond appropriately with a message in the same protocol |
| 703 | version used by the client. |
| 704 | |
| 705 | HTTP/1.0 clients must: |
| 706 | |
| 707 | o recognize the format of the Status-Line for HTTP/1.0 responses; |
| 708 | |
| 709 | o understand any valid response in the format of HTTP/0.9 or |
| 710 | HTTP/1.0. |
| 711 | |
| 712 | Proxy and gateway applications must be careful in forwarding requests |
| 713 | that are received in a format different than that of the |
| 714 | application's native HTTP version. Since the protocol version |
| 715 | indicates the protocol capability of the sender, a proxy/gateway must |
| 716 | never send a message with a version indicator which is greater than |
| 717 | its native version; if a higher version request is received, the |
| 718 | proxy/gateway must either downgrade the request version or respond |
| 719 | with an error. Requests with a version lower than that of the |
| 720 | application's native format may be upgraded before being forwarded; |
| 721 | the proxy/gateway's response to that request must follow the server |
| 722 | requirements listed above. |
| 723 | |
| 724 | |
| 725 | |
| 726 | |
| 727 | |
| 728 | |
| 729 | |
| 730 | Berners-Lee, et al Informational [Page 13] |
| 731 | \f |
| 732 | RFC 1945 HTTP/1.0 May 1996 |
| 733 | |
| 734 | |
| 735 | 3.2 Uniform Resource Identifiers |
| 736 | |
| 737 | URIs have been known by many names: WWW addresses, Universal Document |
| 738 | Identifiers, Universal Resource Identifiers [2], and finally the |
| 739 | combination of Uniform Resource Locators (URL) [4] and Names (URN) |
| 740 | [16]. As far as HTTP is concerned, Uniform Resource Identifiers are |
| 741 | simply formatted strings which identify--via name, location, or any |
| 742 | other characteristic--a network resource. |
| 743 | |
| 744 | 3.2.1 General Syntax |
| 745 | |
| 746 | URIs in HTTP can be represented in absolute form or relative to some |
| 747 | known base URI [9], depending upon the context of their use. The two |
| 748 | forms are differentiated by the fact that absolute URIs always begin |
| 749 | with a scheme name followed by a colon. |
| 750 | |
| 751 | URI = ( absoluteURI | relativeURI ) [ "#" fragment ] |
| 752 | |
| 753 | absoluteURI = scheme ":" *( uchar | reserved ) |
| 754 | |
| 755 | relativeURI = net_path | abs_path | rel_path |
| 756 | |
| 757 | net_path = "//" net_loc [ abs_path ] |
| 758 | abs_path = "/" rel_path |
| 759 | rel_path = [ path ] [ ";" params ] [ "?" query ] |
| 760 | |
| 761 | path = fsegment *( "/" segment ) |
| 762 | fsegment = 1*pchar |
| 763 | segment = *pchar |
| 764 | |
| 765 | params = param *( ";" param ) |
| 766 | param = *( pchar | "/" ) |
| 767 | |
| 768 | scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." ) |
| 769 | net_loc = *( pchar | ";" | "?" ) |
| 770 | query = *( uchar | reserved ) |
| 771 | fragment = *( uchar | reserved ) |
| 772 | |
| 773 | pchar = uchar | ":" | "@" | "&" | "=" | "+" |
| 774 | uchar = unreserved | escape |
| 775 | unreserved = ALPHA | DIGIT | safe | extra | national |
| 776 | |
| 777 | escape = "%" HEX HEX |
| 778 | reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
| 779 | extra = "!" | "*" | "'" | "(" | ")" | "," |
| 780 | safe = "$" | "-" | "_" | "." |
| 781 | unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">" |
| 782 | national = <any OCTET excluding ALPHA, DIGIT, |
| 783 | |
| 784 | |
| 785 | |
| 786 | Berners-Lee, et al Informational [Page 14] |
| 787 | \f |
| 788 | RFC 1945 HTTP/1.0 May 1996 |
| 789 | |
| 790 | |
| 791 | reserved, extra, safe, and unsafe> |
| 792 | |
| 793 | For definitive information on URL syntax and semantics, see RFC 1738 |
| 794 | [4] and RFC 1808 [9]. The BNF above includes national characters not |
| 795 | allowed in valid URLs as specified by RFC 1738, since HTTP servers |
| 796 | are not restricted in the set of unreserved characters allowed to |
| 797 | represent the rel_path part of addresses, and HTTP proxies may |
| 798 | receive requests for URIs not defined by RFC 1738. |
| 799 | |
| 800 | 3.2.2 http URL |
| 801 | |
| 802 | The "http" scheme is used to locate network resources via the HTTP |
| 803 | protocol. This section defines the scheme-specific syntax and |
| 804 | semantics for http URLs. |
| 805 | |
| 806 | http_URL = "http:" "//" host [ ":" port ] [ abs_path ] |
| 807 | |
| 808 | host = <A legal Internet host domain name |
| 809 | or IP address (in dotted-decimal form), |
| 810 | as defined by Section 2.1 of RFC 1123> |
| 811 | |
| 812 | port = *DIGIT |
| 813 | |
| 814 | If the port is empty or not given, port 80 is assumed. The semantics |
| 815 | are that the identified resource is located at the server listening |
| 816 | for TCP connections on that port of that host, and the Request-URI |
| 817 | for the resource is abs_path. If the abs_path is not present in the |
| 818 | URL, it must be given as "/" when used as a Request-URI (Section |
| 819 | 5.1.2). |
| 820 | |
| 821 | Note: Although the HTTP protocol is independent of the transport |
| 822 | layer protocol, the http URL only identifies resources by their |
| 823 | TCP location, and thus non-TCP resources must be identified by |
| 824 | some other URI scheme. |
| 825 | |
| 826 | The canonical form for "http" URLs is obtained by converting any |
| 827 | UPALPHA characters in host to their LOALPHA equivalent (hostnames are |
| 828 | case-insensitive), eliding the [ ":" port ] if the port is 80, and |
| 829 | replacing an empty abs_path with "/". |
| 830 | |
| 831 | 3.3 Date/Time Formats |
| 832 | |
| 833 | HTTP/1.0 applications have historically allowed three different |
| 834 | formats for the representation of date/time stamps: |
| 835 | |
| 836 | Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 |
| 837 | Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 |
| 838 | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |
| 839 | |
| 840 | |
| 841 | |
| 842 | Berners-Lee, et al Informational [Page 15] |
| 843 | \f |
| 844 | RFC 1945 HTTP/1.0 May 1996 |
| 845 | |
| 846 | |
| 847 | The first format is preferred as an Internet standard and represents |
| 848 | a fixed-length subset of that defined by RFC 1123 [6] (an update to |
| 849 | RFC 822 [7]). The second format is in common use, but is based on the |
| 850 | obsolete RFC 850 [10] date format and lacks a four-digit year. |
| 851 | HTTP/1.0 clients and servers that parse the date value should accept |
| 852 | all three formats, though they must never generate the third |
| 853 | (asctime) format. |
| 854 | |
| 855 | Note: Recipients of date values are encouraged to be robust in |
| 856 | accepting date values that may have been generated by non-HTTP |
| 857 | applications, as is sometimes the case when retrieving or posting |
| 858 | messages via proxies/gateways to SMTP or NNTP. |
| 859 | |
| 860 | All HTTP/1.0 date/time stamps must be represented in Universal Time |
| 861 | (UT), also known as Greenwich Mean Time (GMT), without exception. |
| 862 | This is indicated in the first two formats by the inclusion of "GMT" |
| 863 | as the three-letter abbreviation for time zone, and should be assumed |
| 864 | when reading the asctime format. |
| 865 | |
| 866 | HTTP-date = rfc1123-date | rfc850-date | asctime-date |
| 867 | |
| 868 | rfc1123-date = wkday "," SP date1 SP time SP "GMT" |
| 869 | rfc850-date = weekday "," SP date2 SP time SP "GMT" |
| 870 | asctime-date = wkday SP date3 SP time SP 4DIGIT |
| 871 | |
| 872 | date1 = 2DIGIT SP month SP 4DIGIT |
| 873 | ; day month year (e.g., 02 Jun 1982) |
| 874 | date2 = 2DIGIT "-" month "-" 2DIGIT |
| 875 | ; day-month-year (e.g., 02-Jun-82) |
| 876 | date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) |
| 877 | ; month day (e.g., Jun 2) |
| 878 | |
| 879 | time = 2DIGIT ":" 2DIGIT ":" 2DIGIT |
| 880 | ; 00:00:00 - 23:59:59 |
| 881 | |
| 882 | wkday = "Mon" | "Tue" | "Wed" |
| 883 | | "Thu" | "Fri" | "Sat" | "Sun" |
| 884 | |
| 885 | weekday = "Monday" | "Tuesday" | "Wednesday" |
| 886 | | "Thursday" | "Friday" | "Saturday" | "Sunday" |
| 887 | |
| 888 | month = "Jan" | "Feb" | "Mar" | "Apr" |
| 889 | | "May" | "Jun" | "Jul" | "Aug" |
| 890 | | "Sep" | "Oct" | "Nov" | "Dec" |
| 891 | |
| 892 | Note: HTTP requirements for the date/time stamp format apply |
| 893 | only to their usage within the protocol stream. Clients and |
| 894 | servers are not required to use these formats for user |
| 895 | |
| 896 | |
| 897 | |
| 898 | Berners-Lee, et al Informational [Page 16] |
| 899 | \f |
| 900 | RFC 1945 HTTP/1.0 May 1996 |
| 901 | |
| 902 | |
| 903 | presentation, request logging, etc. |
| 904 | |
| 905 | 3.4 Character Sets |
| 906 | |
| 907 | HTTP uses the same definition of the term "character set" as that |
| 908 | described for MIME: |
| 909 | |
| 910 | The term "character set" is used in this document to refer to a |
| 911 | method used with one or more tables to convert a sequence of |
| 912 | octets into a sequence of characters. Note that unconditional |
| 913 | conversion in the other direction is not required, in that not all |
| 914 | characters may be available in a given character set and a |
| 915 | character set may provide more than one sequence of octets to |
| 916 | represent a particular character. This definition is intended to |
| 917 | allow various kinds of character encodings, from simple single- |
| 918 | table mappings such as US-ASCII to complex table switching methods |
| 919 | such as those that use ISO 2022's techniques. However, the |
| 920 | definition associated with a MIME character set name must fully |
| 921 | specify the mapping to be performed from octets to characters. In |
| 922 | particular, use of external profiling information to determine the |
| 923 | exact mapping is not permitted. |
| 924 | |
| 925 | Note: This use of the term "character set" is more commonly |
| 926 | referred to as a "character encoding." However, since HTTP and |
| 927 | MIME share the same registry, it is important that the terminology |
| 928 | also be shared. |
| 929 | |
| 930 | HTTP character sets are identified by case-insensitive tokens. The |
| 931 | complete set of tokens are defined by the IANA Character Set registry |
| 932 | [15]. However, because that registry does not define a single, |
| 933 | consistent token for each character set, we define here the preferred |
| 934 | names for those character sets most likely to be used with HTTP |
| 935 | entities. These character sets include those registered by RFC 1521 |
| 936 | [5] -- the US-ASCII [17] and ISO-8859 [18] character sets -- and |
| 937 | other names specifically recommended for use within MIME charset |
| 938 | parameters. |
| 939 | |
| 940 | charset = "US-ASCII" |
| 941 | | "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3" |
| 942 | | "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6" |
| 943 | | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9" |
| 944 | | "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR" |
| 945 | | "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8" |
| 946 | | token |
| 947 | |
| 948 | Although HTTP allows an arbitrary token to be used as a charset |
| 949 | value, any token that has a predefined value within the IANA |
| 950 | Character Set registry [15] must represent the character set defined |
| 951 | |
| 952 | |
| 953 | |
| 954 | Berners-Lee, et al Informational [Page 17] |
| 955 | \f |
| 956 | RFC 1945 HTTP/1.0 May 1996 |
| 957 | |
| 958 | |
| 959 | by that registry. Applications should limit their use of character |
| 960 | sets to those defined by the IANA registry. |
| 961 | |
| 962 | The character set of an entity body should be labelled as the lowest |
| 963 | common denominator of the character codes used within that body, with |
| 964 | the exception that no label is preferred over the labels US-ASCII or |
| 965 | ISO-8859-1. |
| 966 | |
| 967 | 3.5 Content Codings |
| 968 | |
| 969 | Content coding values are used to indicate an encoding transformation |
| 970 | that has been applied to a resource. Content codings are primarily |
| 971 | used to allow a document to be compressed or encrypted without losing |
| 972 | the identity of its underlying media type. Typically, the resource is |
| 973 | stored in this encoding and only decoded before rendering or |
| 974 | analogous usage. |
| 975 | |
| 976 | content-coding = "x-gzip" | "x-compress" | token |
| 977 | |
| 978 | Note: For future compatibility, HTTP/1.0 applications should |
| 979 | consider "gzip" and "compress" to be equivalent to "x-gzip" |
| 980 | and "x-compress", respectively. |
| 981 | |
| 982 | All content-coding values are case-insensitive. HTTP/1.0 uses |
| 983 | content-coding values in the Content-Encoding (Section 10.3) header |
| 984 | field. Although the value describes the content-coding, what is more |
| 985 | important is that it indicates what decoding mechanism will be |
| 986 | required to remove the encoding. Note that a single program may be |
| 987 | capable of decoding multiple content-coding formats. Two values are |
| 988 | defined by this specification: |
| 989 | |
| 990 | x-gzip |
| 991 | An encoding format produced by the file compression program |
| 992 | "gzip" (GNU zip) developed by Jean-loup Gailly. This format is |
| 993 | typically a Lempel-Ziv coding (LZ77) with a 32 bit CRC. |
| 994 | |
| 995 | x-compress |
| 996 | The encoding format produced by the file compression program |
| 997 | "compress". This format is an adaptive Lempel-Ziv-Welch coding |
| 998 | (LZW). |
| 999 | |
| 1000 | Note: Use of program names for the identification of |
| 1001 | encoding formats is not desirable and should be discouraged |
| 1002 | for future encodings. Their use here is representative of |
| 1003 | historical practice, not good design. |
| 1004 | |
| 1005 | |
| 1006 | |
| 1007 | |
| 1008 | |
| 1009 | |
| 1010 | Berners-Lee, et al Informational [Page 18] |
| 1011 | \f |
| 1012 | RFC 1945 HTTP/1.0 May 1996 |
| 1013 | |
| 1014 | |
| 1015 | 3.6 Media Types |
| 1016 | |
| 1017 | HTTP uses Internet Media Types [13] in the Content-Type header field |
| 1018 | (Section 10.5) in order to provide open and extensible data typing. |
| 1019 | |
| 1020 | media-type = type "/" subtype *( ";" parameter ) |
| 1021 | type = token |
| 1022 | subtype = token |
| 1023 | |
| 1024 | Parameters may follow the type/subtype in the form of attribute/value |
| 1025 | pairs. |
| 1026 | |
| 1027 | parameter = attribute "=" value |
| 1028 | attribute = token |
| 1029 | value = token | quoted-string |
| 1030 | |
| 1031 | The type, subtype, and parameter attribute names are case- |
| 1032 | insensitive. Parameter values may or may not be case-sensitive, |
| 1033 | depending on the semantics of the parameter name. LWS must not be |
| 1034 | generated between the type and subtype, nor between an attribute and |
| 1035 | its value. Upon receipt of a media type with an unrecognized |
| 1036 | parameter, a user agent should treat the media type as if the |
| 1037 | unrecognized parameter and its value were not present. |
| 1038 | |
| 1039 | Some older HTTP applications do not recognize media type parameters. |
| 1040 | HTTP/1.0 applications should only use media type parameters when they |
| 1041 | are necessary to define the content of a message. |
| 1042 | |
| 1043 | Media-type values are registered with the Internet Assigned Number |
| 1044 | Authority (IANA [15]). The media type registration process is |
| 1045 | outlined in RFC 1590 [13]. Use of non-registered media types is |
| 1046 | discouraged. |
| 1047 | |
| 1048 | 3.6.1 Canonicalization and Text Defaults |
| 1049 | |
| 1050 | Internet media types are registered with a canonical form. In |
| 1051 | general, an Entity-Body transferred via HTTP must be represented in |
| 1052 | the appropriate canonical form prior to its transmission. If the body |
| 1053 | has been encoded with a Content-Encoding, the underlying data should |
| 1054 | be in canonical form prior to being encoded. |
| 1055 | |
| 1056 | Media subtypes of the "text" type use CRLF as the text line break |
| 1057 | when in canonical form. However, HTTP allows the transport of text |
| 1058 | media with plain CR or LF alone representing a line break when used |
| 1059 | consistently within the Entity-Body. HTTP applications must accept |
| 1060 | CRLF, bare CR, and bare LF as being representative of a line break in |
| 1061 | text media received via HTTP. |
| 1062 | |
| 1063 | |
| 1064 | |
| 1065 | |
| 1066 | Berners-Lee, et al Informational [Page 19] |
| 1067 | \f |
| 1068 | RFC 1945 HTTP/1.0 May 1996 |
| 1069 | |
| 1070 | |
| 1071 | In addition, if the text media is represented in a character set that |
| 1072 | does not use octets 13 and 10 for CR and LF respectively, as is the |
| 1073 | case for some multi-byte character sets, HTTP allows the use of |
| 1074 | whatever octet sequences are defined by that character set to |
| 1075 | represent the equivalent of CR and LF for line breaks. This |
| 1076 | flexibility regarding line breaks applies only to text media in the |
| 1077 | Entity-Body; a bare CR or LF should not be substituted for CRLF |
| 1078 | within any of the HTTP control structures (such as header fields and |
| 1079 | multipart boundaries). |
| 1080 | |
| 1081 | The "charset" parameter is used with some media types to define the |
| 1082 | character set (Section 3.4) of the data. When no explicit charset |
| 1083 | parameter is provided by the sender, media subtypes of the "text" |
| 1084 | type are defined to have a default charset value of "ISO-8859-1" when |
| 1085 | received via HTTP. Data in character sets other than "ISO-8859-1" or |
| 1086 | its subsets must be labelled with an appropriate charset value in |
| 1087 | order to be consistently interpreted by the recipient. |
| 1088 | |
| 1089 | Note: Many current HTTP servers provide data using charsets other |
| 1090 | than "ISO-8859-1" without proper labelling. This situation reduces |
| 1091 | interoperability and is not recommended. To compensate for this, |
| 1092 | some HTTP user agents provide a configuration option to allow the |
| 1093 | user to change the default interpretation of the media type |
| 1094 | character set when no charset parameter is given. |
| 1095 | |
| 1096 | 3.6.2 Multipart Types |
| 1097 | |
| 1098 | MIME provides for a number of "multipart" types -- encapsulations of |
| 1099 | several entities within a single message's Entity-Body. The multipart |
| 1100 | types registered by IANA [15] do not have any special meaning for |
| 1101 | HTTP/1.0, though user agents may need to understand each type in |
| 1102 | order to correctly interpret the purpose of each body-part. An HTTP |
| 1103 | user agent should follow the same or similar behavior as a MIME user |
| 1104 | agent does upon receipt of a multipart type. HTTP servers should not |
| 1105 | assume that all HTTP clients are prepared to handle multipart types. |
| 1106 | |
| 1107 | All multipart types share a common syntax and must include a boundary |
| 1108 | parameter as part of the media type value. The message body is itself |
| 1109 | a protocol element and must therefore use only CRLF to represent line |
| 1110 | breaks between body-parts. Multipart body-parts may contain HTTP |
| 1111 | header fields which are significant to the meaning of that part. |
| 1112 | |
| 1113 | 3.7 Product Tokens |
| 1114 | |
| 1115 | Product tokens are used to allow communicating applications to |
| 1116 | identify themselves via a simple product token, with an optional |
| 1117 | slash and version designator. Most fields using product tokens also |
| 1118 | allow subproducts which form a significant part of the application to |
| 1119 | |
| 1120 | |
| 1121 | |
| 1122 | Berners-Lee, et al Informational [Page 20] |
| 1123 | \f |
| 1124 | RFC 1945 HTTP/1.0 May 1996 |
| 1125 | |
| 1126 | |
| 1127 | be listed, separated by whitespace. By convention, the products are |
| 1128 | listed in order of their significance for identifying the |
| 1129 | application. |
| 1130 | |
| 1131 | product = token ["/" product-version] |
| 1132 | product-version = token |
| 1133 | |
| 1134 | Examples: |
| 1135 | |
| 1136 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
| 1137 | |
| 1138 | Server: Apache/0.8.4 |
| 1139 | |
| 1140 | Product tokens should be short and to the point -- use of them for |
| 1141 | advertizing or other non-essential information is explicitly |
| 1142 | forbidden. Although any token character may appear in a product- |
| 1143 | version, this token should only be used for a version identifier |
| 1144 | (i.e., successive versions of the same product should only differ in |
| 1145 | the product-version portion of the product value). |
| 1146 | |
| 1147 | 4. HTTP Message |
| 1148 | |
| 1149 | 4.1 Message Types |
| 1150 | |
| 1151 | HTTP messages consist of requests from client to server and responses |
| 1152 | from server to client. |
| 1153 | |
| 1154 | HTTP-message = Simple-Request ; HTTP/0.9 messages |
| 1155 | | Simple-Response |
| 1156 | | Full-Request ; HTTP/1.0 messages |
| 1157 | | Full-Response |
| 1158 | |
| 1159 | Full-Request and Full-Response use the generic message format of RFC |
| 1160 | 822 [7] for transferring entities. Both messages may include optional |
| 1161 | header fields (also known as "headers") and an entity body. The |
| 1162 | entity body is separated from the headers by a null line (i.e., a |
| 1163 | line with nothing preceding the CRLF). |
| 1164 | |
| 1165 | Full-Request = Request-Line ; Section 5.1 |
| 1166 | *( General-Header ; Section 4.3 |
| 1167 | | Request-Header ; Section 5.2 |
| 1168 | | Entity-Header ) ; Section 7.1 |
| 1169 | CRLF |
| 1170 | [ Entity-Body ] ; Section 7.2 |
| 1171 | |
| 1172 | Full-Response = Status-Line ; Section 6.1 |
| 1173 | *( General-Header ; Section 4.3 |
| 1174 | | Response-Header ; Section 6.2 |
| 1175 | |
| 1176 | |
| 1177 | |
| 1178 | Berners-Lee, et al Informational [Page 21] |
| 1179 | \f |
| 1180 | RFC 1945 HTTP/1.0 May 1996 |
| 1181 | |
| 1182 | |
| 1183 | | Entity-Header ) ; Section 7.1 |
| 1184 | CRLF |
| 1185 | [ Entity-Body ] ; Section 7.2 |
| 1186 | |
| 1187 | Simple-Request and Simple-Response do not allow the use of any header |
| 1188 | information and are limited to a single request method (GET). |
| 1189 | |
| 1190 | Simple-Request = "GET" SP Request-URI CRLF |
| 1191 | |
| 1192 | Simple-Response = [ Entity-Body ] |
| 1193 | |
| 1194 | Use of the Simple-Request format is discouraged because it prevents |
| 1195 | the server from identifying the media type of the returned entity. |
| 1196 | |
| 1197 | 4.2 Message Headers |
| 1198 | |
| 1199 | HTTP header fields, which include General-Header (Section 4.3), |
| 1200 | Request-Header (Section 5.2), Response-Header (Section 6.2), and |
| 1201 | Entity-Header (Section 7.1) fields, follow the same generic format as |
| 1202 | that given in Section 3.1 of RFC 822 [7]. Each header field consists |
| 1203 | of a name followed immediately by a colon (":"), a single space (SP) |
| 1204 | character, and the field value. Field names are case-insensitive. |
| 1205 | Header fields can be extended over multiple lines by preceding each |
| 1206 | extra line with at least one SP or HT, though this is not |
| 1207 | recommended. |
| 1208 | |
| 1209 | HTTP-header = field-name ":" [ field-value ] CRLF |
| 1210 | |
| 1211 | field-name = token |
| 1212 | field-value = *( field-content | LWS ) |
| 1213 | |
| 1214 | field-content = <the OCTETs making up the field-value |
| 1215 | and consisting of either *TEXT or combinations |
| 1216 | of token, tspecials, and quoted-string> |
| 1217 | |
| 1218 | The order in which header fields are received is not significant. |
| 1219 | However, it is "good practice" to send General-Header fields first, |
| 1220 | followed by Request-Header or Response-Header fields prior to the |
| 1221 | Entity-Header fields. |
| 1222 | |
| 1223 | Multiple HTTP-header fields with the same field-name may be present |
| 1224 | in a message if and only if the entire field-value for that header |
| 1225 | field is defined as a comma-separated list [i.e., #(values)]. It must |
| 1226 | be possible to combine the multiple header fields into one "field- |
| 1227 | name: field-value" pair, without changing the semantics of the |
| 1228 | message, by appending each subsequent field-value to the first, each |
| 1229 | separated by a comma. |
| 1230 | |
| 1231 | |
| 1232 | |
| 1233 | |
| 1234 | Berners-Lee, et al Informational [Page 22] |
| 1235 | \f |
| 1236 | RFC 1945 HTTP/1.0 May 1996 |
| 1237 | |
| 1238 | |
| 1239 | 4.3 General Header Fields |
| 1240 | |
| 1241 | There are a few header fields which have general applicability for |
| 1242 | both request and response messages, but which do not apply to the |
| 1243 | entity being transferred. These headers apply only to the message |
| 1244 | being transmitted. |
| 1245 | |
| 1246 | General-Header = Date ; Section 10.6 |
| 1247 | | Pragma ; Section 10.12 |
| 1248 | |
| 1249 | General header field names can be extended reliably only in |
| 1250 | combination with a change in the protocol version. However, new or |
| 1251 | experimental header fields may be given the semantics of general |
| 1252 | header fields if all parties in the communication recognize them to |
| 1253 | be general header fields. Unrecognized header fields are treated as |
| 1254 | Entity-Header fields. |
| 1255 | |
| 1256 | 5. Request |
| 1257 | |
| 1258 | A request message from a client to a server includes, within the |
| 1259 | first line of that message, the method to be applied to the resource, |
| 1260 | the identifier of the resource, and the protocol version in use. For |
| 1261 | backwards compatibility with the more limited HTTP/0.9 protocol, |
| 1262 | there are two valid formats for an HTTP request: |
| 1263 | |
| 1264 | Request = Simple-Request | Full-Request |
| 1265 | |
| 1266 | Simple-Request = "GET" SP Request-URI CRLF |
| 1267 | |
| 1268 | Full-Request = Request-Line ; Section 5.1 |
| 1269 | *( General-Header ; Section 4.3 |
| 1270 | | Request-Header ; Section 5.2 |
| 1271 | | Entity-Header ) ; Section 7.1 |
| 1272 | CRLF |
| 1273 | [ Entity-Body ] ; Section 7.2 |
| 1274 | |
| 1275 | If an HTTP/1.0 server receives a Simple-Request, it must respond with |
| 1276 | an HTTP/0.9 Simple-Response. An HTTP/1.0 client capable of receiving |
| 1277 | a Full-Response should never generate a Simple-Request. |
| 1278 | |
| 1279 | 5.1 Request-Line |
| 1280 | |
| 1281 | The Request-Line begins with a method token, followed by the |
| 1282 | Request-URI and the protocol version, and ending with CRLF. The |
| 1283 | elements are separated by SP characters. No CR or LF are allowed |
| 1284 | except in the final CRLF sequence. |
| 1285 | |
| 1286 | Request-Line = Method SP Request-URI SP HTTP-Version CRLF |
| 1287 | |
| 1288 | |
| 1289 | |
| 1290 | Berners-Lee, et al Informational [Page 23] |
| 1291 | \f |
| 1292 | RFC 1945 HTTP/1.0 May 1996 |
| 1293 | |
| 1294 | |
| 1295 | Note that the difference between a Simple-Request and the Request- |
| 1296 | Line of a Full-Request is the presence of the HTTP-Version field and |
| 1297 | the availability of methods other than GET. |
| 1298 | |
| 1299 | 5.1.1 Method |
| 1300 | |
| 1301 | The Method token indicates the method to be performed on the resource |
| 1302 | identified by the Request-URI. The method is case-sensitive. |
| 1303 | |
| 1304 | Method = "GET" ; Section 8.1 |
| 1305 | | "HEAD" ; Section 8.2 |
| 1306 | | "POST" ; Section 8.3 |
| 1307 | | extension-method |
| 1308 | |
| 1309 | extension-method = token |
| 1310 | |
| 1311 | The list of methods acceptable by a specific resource can change |
| 1312 | dynamically; the client is notified through the return code of the |
| 1313 | response if a method is not allowed on a resource. Servers should |
| 1314 | return the status code 501 (not implemented) if the method is |
| 1315 | unrecognized or not implemented. |
| 1316 | |
| 1317 | The methods commonly used by HTTP/1.0 applications are fully defined |
| 1318 | in Section 8. |
| 1319 | |
| 1320 | 5.1.2 Request-URI |
| 1321 | |
| 1322 | The Request-URI is a Uniform Resource Identifier (Section 3.2) and |
| 1323 | identifies the resource upon which to apply the request. |
| 1324 | |
| 1325 | Request-URI = absoluteURI | abs_path |
| 1326 | |
| 1327 | The two options for Request-URI are dependent on the nature of the |
| 1328 | request. |
| 1329 | |
| 1330 | The absoluteURI form is only allowed when the request is being made |
| 1331 | to a proxy. The proxy is requested to forward the request and return |
| 1332 | the response. If the request is GET or HEAD and a prior response is |
| 1333 | cached, the proxy may use the cached message if it passes any |
| 1334 | restrictions in the Expires header field. Note that the proxy may |
| 1335 | forward the request on to another proxy or directly to the server |
| 1336 | specified by the absoluteURI. In order to avoid request loops, a |
| 1337 | proxy must be able to recognize all of its server names, including |
| 1338 | any aliases, local variations, and the numeric IP address. An example |
| 1339 | Request-Line would be: |
| 1340 | |
| 1341 | GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0 |
| 1342 | |
| 1343 | |
| 1344 | |
| 1345 | |
| 1346 | Berners-Lee, et al Informational [Page 24] |
| 1347 | \f |
| 1348 | RFC 1945 HTTP/1.0 May 1996 |
| 1349 | |
| 1350 | |
| 1351 | The most common form of Request-URI is that used to identify a |
| 1352 | resource on an origin server or gateway. In this case, only the |
| 1353 | absolute path of the URI is transmitted (see Section 3.2.1, |
| 1354 | abs_path). For example, a client wishing to retrieve the resource |
| 1355 | above directly from the origin server would create a TCP connection |
| 1356 | to port 80 of the host "www.w3.org" and send the line: |
| 1357 | |
| 1358 | GET /pub/WWW/TheProject.html HTTP/1.0 |
| 1359 | |
| 1360 | followed by the remainder of the Full-Request. Note that the absolute |
| 1361 | path cannot be empty; if none is present in the original URI, it must |
| 1362 | be given as "/" (the server root). |
| 1363 | |
| 1364 | The Request-URI is transmitted as an encoded string, where some |
| 1365 | characters may be escaped using the "% HEX HEX" encoding defined by |
| 1366 | RFC 1738 [4]. The origin server must decode the Request-URI in order |
| 1367 | to properly interpret the request. |
| 1368 | |
| 1369 | 5.2 Request Header Fields |
| 1370 | |
| 1371 | The request header fields allow the client to pass additional |
| 1372 | information about the request, and about the client itself, to the |
| 1373 | server. These fields act as request modifiers, with semantics |
| 1374 | equivalent to the parameters on a programming language method |
| 1375 | (procedure) invocation. |
| 1376 | |
| 1377 | Request-Header = Authorization ; Section 10.2 |
| 1378 | | From ; Section 10.8 |
| 1379 | | If-Modified-Since ; Section 10.9 |
| 1380 | | Referer ; Section 10.13 |
| 1381 | | User-Agent ; Section 10.15 |
| 1382 | |
| 1383 | Request-Header field names can be extended reliably only in |
| 1384 | combination with a change in the protocol version. However, new or |
| 1385 | experimental header fields may be given the semantics of request |
| 1386 | header fields if all parties in the communication recognize them to |
| 1387 | be request header fields. Unrecognized header fields are treated as |
| 1388 | Entity-Header fields. |
| 1389 | |
| 1390 | 6. Response |
| 1391 | |
| 1392 | After receiving and interpreting a request message, a server responds |
| 1393 | in the form of an HTTP response message. |
| 1394 | |
| 1395 | Response = Simple-Response | Full-Response |
| 1396 | |
| 1397 | Simple-Response = [ Entity-Body ] |
| 1398 | |
| 1399 | |
| 1400 | |
| 1401 | |
| 1402 | Berners-Lee, et al Informational [Page 25] |
| 1403 | \f |
| 1404 | RFC 1945 HTTP/1.0 May 1996 |
| 1405 | |
| 1406 | |
| 1407 | Full-Response = Status-Line ; Section 6.1 |
| 1408 | *( General-Header ; Section 4.3 |
| 1409 | | Response-Header ; Section 6.2 |
| 1410 | | Entity-Header ) ; Section 7.1 |
| 1411 | CRLF |
| 1412 | [ Entity-Body ] ; Section 7.2 |
| 1413 | |
| 1414 | A Simple-Response should only be sent in response to an HTTP/0.9 |
| 1415 | Simple-Request or if the server only supports the more limited |
| 1416 | HTTP/0.9 protocol. If a client sends an HTTP/1.0 Full-Request and |
| 1417 | receives a response that does not begin with a Status-Line, it should |
| 1418 | assume that the response is a Simple-Response and parse it |
| 1419 | accordingly. Note that the Simple-Response consists only of the |
| 1420 | entity body and is terminated by the server closing the connection. |
| 1421 | |
| 1422 | 6.1 Status-Line |
| 1423 | |
| 1424 | The first line of a Full-Response message is the Status-Line, |
| 1425 | consisting of the protocol version followed by a numeric status code |
| 1426 | and its associated textual phrase, with each element separated by SP |
| 1427 | characters. No CR or LF is allowed except in the final CRLF sequence. |
| 1428 | |
| 1429 | Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |
| 1430 | |
| 1431 | Since a status line always begins with the protocol version and |
| 1432 | status code |
| 1433 | |
| 1434 | "HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP |
| 1435 | |
| 1436 | (e.g., "HTTP/1.0 200 "), the presence of that expression is |
| 1437 | sufficient to differentiate a Full-Response from a Simple-Response. |
| 1438 | Although the Simple-Response format may allow such an expression to |
| 1439 | occur at the beginning of an entity body, and thus cause a |
| 1440 | misinterpretation of the message if it was given in response to a |
| 1441 | Full-Request, most HTTP/0.9 servers are limited to responses of type |
| 1442 | "text/html" and therefore would never generate such a response. |
| 1443 | |
| 1444 | 6.1.1 Status Code and Reason Phrase |
| 1445 | |
| 1446 | The Status-Code element is a 3-digit integer result code of the |
| 1447 | attempt to understand and satisfy the request. The Reason-Phrase is |
| 1448 | intended to give a short textual description of the Status-Code. The |
| 1449 | Status-Code is intended for use by automata and the Reason-Phrase is |
| 1450 | intended for the human user. The client is not required to examine or |
| 1451 | display the Reason-Phrase. |
| 1452 | |
| 1453 | |
| 1454 | |
| 1455 | |
| 1456 | |
| 1457 | |
| 1458 | Berners-Lee, et al Informational [Page 26] |
| 1459 | \f |
| 1460 | RFC 1945 HTTP/1.0 May 1996 |
| 1461 | |
| 1462 | |
| 1463 | The first digit of the Status-Code defines the class of response. The |
| 1464 | last two digits do not have any categorization role. There are 5 |
| 1465 | values for the first digit: |
| 1466 | |
| 1467 | o 1xx: Informational - Not used, but reserved for future use |
| 1468 | |
| 1469 | o 2xx: Success - The action was successfully received, |
| 1470 | understood, and accepted. |
| 1471 | |
| 1472 | o 3xx: Redirection - Further action must be taken in order to |
| 1473 | complete the request |
| 1474 | |
| 1475 | o 4xx: Client Error - The request contains bad syntax or cannot |
| 1476 | be fulfilled |
| 1477 | |
| 1478 | o 5xx: Server Error - The server failed to fulfill an apparently |
| 1479 | valid request |
| 1480 | |
| 1481 | The individual values of the numeric status codes defined for |
| 1482 | HTTP/1.0, and an example set of corresponding Reason-Phrase's, are |
| 1483 | presented below. The reason phrases listed here are only recommended |
| 1484 | -- they may be replaced by local equivalents without affecting the |
| 1485 | protocol. These codes are fully defined in Section 9. |
| 1486 | |
| 1487 | Status-Code = "200" ; OK |
| 1488 | | "201" ; Created |
| 1489 | | "202" ; Accepted |
| 1490 | | "204" ; No Content |
| 1491 | | "301" ; Moved Permanently |
| 1492 | | "302" ; Moved Temporarily |
| 1493 | | "304" ; Not Modified |
| 1494 | | "400" ; Bad Request |
| 1495 | | "401" ; Unauthorized |
| 1496 | | "403" ; Forbidden |
| 1497 | | "404" ; Not Found |
| 1498 | | "500" ; Internal Server Error |
| 1499 | | "501" ; Not Implemented |
| 1500 | | "502" ; Bad Gateway |
| 1501 | | "503" ; Service Unavailable |
| 1502 | | extension-code |
| 1503 | |
| 1504 | extension-code = 3DIGIT |
| 1505 | |
| 1506 | Reason-Phrase = *<TEXT, excluding CR, LF> |
| 1507 | |
| 1508 | HTTP status codes are extensible, but the above codes are the only |
| 1509 | ones generally recognized in current practice. HTTP applications are |
| 1510 | not required to understand the meaning of all registered status |
| 1511 | |
| 1512 | |
| 1513 | |
| 1514 | Berners-Lee, et al Informational [Page 27] |
| 1515 | \f |
| 1516 | RFC 1945 HTTP/1.0 May 1996 |
| 1517 | |
| 1518 | |
| 1519 | codes, though such understanding is obviously desirable. However, |
| 1520 | applications must understand the class of any status code, as |
| 1521 | indicated by the first digit, and treat any unrecognized response as |
| 1522 | being equivalent to the x00 status code of that class, with the |
| 1523 | exception that an unrecognized response must not be cached. For |
| 1524 | example, if an unrecognized status code of 431 is received by the |
| 1525 | client, it can safely assume that there was something wrong with its |
| 1526 | request and treat the response as if it had received a 400 status |
| 1527 | code. In such cases, user agents should present to the user the |
| 1528 | entity returned with the response, since that entity is likely to |
| 1529 | include human-readable information which will explain the unusual |
| 1530 | status. |
| 1531 | |
| 1532 | 6.2 Response Header Fields |
| 1533 | |
| 1534 | The response header fields allow the server to pass additional |
| 1535 | information about the response which cannot be placed in the Status- |
| 1536 | Line. These header fields give information about the server and about |
| 1537 | further access to the resource identified by the Request-URI. |
| 1538 | |
| 1539 | Response-Header = Location ; Section 10.11 |
| 1540 | | Server ; Section 10.14 |
| 1541 | | WWW-Authenticate ; Section 10.16 |
| 1542 | |
| 1543 | Response-Header field names can be extended reliably only in |
| 1544 | combination with a change in the protocol version. However, new or |
| 1545 | experimental header fields may be given the semantics of response |
| 1546 | header fields if all parties in the communication recognize them to |
| 1547 | be response header fields. Unrecognized header fields are treated as |
| 1548 | Entity-Header fields. |
| 1549 | |
| 1550 | 7. Entity |
| 1551 | |
| 1552 | Full-Request and Full-Response messages may transfer an entity within |
| 1553 | some requests and responses. An entity consists of Entity-Header |
| 1554 | fields and (usually) an Entity-Body. In this section, both sender and |
| 1555 | recipient refer to either the client or the server, depending on who |
| 1556 | sends and who receives the entity. |
| 1557 | |
| 1558 | |
| 1559 | |
| 1560 | |
| 1561 | |
| 1562 | |
| 1563 | |
| 1564 | |
| 1565 | |
| 1566 | |
| 1567 | |
| 1568 | |
| 1569 | |
| 1570 | Berners-Lee, et al Informational [Page 28] |
| 1571 | \f |
| 1572 | RFC 1945 HTTP/1.0 May 1996 |
| 1573 | |
| 1574 | |
| 1575 | 7.1 Entity Header Fields |
| 1576 | |
| 1577 | Entity-Header fields define optional metainformation about the |
| 1578 | Entity-Body or, if no body is present, about the resource identified |
| 1579 | by the request. |
| 1580 | |
| 1581 | Entity-Header = Allow ; Section 10.1 |
| 1582 | | Content-Encoding ; Section 10.3 |
| 1583 | | Content-Length ; Section 10.4 |
| 1584 | | Content-Type ; Section 10.5 |
| 1585 | | Expires ; Section 10.7 |
| 1586 | | Last-Modified ; Section 10.10 |
| 1587 | | extension-header |
| 1588 | |
| 1589 | extension-header = HTTP-header |
| 1590 | |
| 1591 | The extension-header mechanism allows additional Entity-Header fields |
| 1592 | to be defined without changing the protocol, but these fields cannot |
| 1593 | be assumed to be recognizable by the recipient. Unrecognized header |
| 1594 | fields should be ignored by the recipient and forwarded by proxies. |
| 1595 | |
| 1596 | 7.2 Entity Body |
| 1597 | |
| 1598 | The entity body (if any) sent with an HTTP request or response is in |
| 1599 | a format and encoding defined by the Entity-Header fields. |
| 1600 | |
| 1601 | Entity-Body = *OCTET |
| 1602 | |
| 1603 | An entity body is included with a request message only when the |
| 1604 | request method calls for one. The presence of an entity body in a |
| 1605 | request is signaled by the inclusion of a Content-Length header field |
| 1606 | in the request message headers. HTTP/1.0 requests containing an |
| 1607 | entity body must include a valid Content-Length header field. |
| 1608 | |
| 1609 | For response messages, whether or not an entity body is included with |
| 1610 | a message is dependent on both the request method and the response |
| 1611 | code. All responses to the HEAD request method must not include a |
| 1612 | body, even though the presence of entity header fields may lead one |
| 1613 | to believe they do. All 1xx (informational), 204 (no content), and |
| 1614 | 304 (not modified) responses must not include a body. All other |
| 1615 | responses must include an entity body or a Content-Length header |
| 1616 | field defined with a value of zero (0). |
| 1617 | |
| 1618 | 7.2.1 Type |
| 1619 | |
| 1620 | When an Entity-Body is included with a message, the data type of that |
| 1621 | body is determined via the header fields Content-Type and Content- |
| 1622 | Encoding. These define a two-layer, ordered encoding model: |
| 1623 | |
| 1624 | |
| 1625 | |
| 1626 | Berners-Lee, et al Informational [Page 29] |
| 1627 | \f |
| 1628 | RFC 1945 HTTP/1.0 May 1996 |
| 1629 | |
| 1630 | |
| 1631 | entity-body := Content-Encoding( Content-Type( data ) ) |
| 1632 | |
| 1633 | A Content-Type specifies the media type of the underlying data. A |
| 1634 | Content-Encoding may be used to indicate any additional content |
| 1635 | coding applied to the type, usually for the purpose of data |
| 1636 | compression, that is a property of the resource requested. The |
| 1637 | default for the content encoding is none (i.e., the identity |
| 1638 | function). |
| 1639 | |
| 1640 | Any HTTP/1.0 message containing an entity body should include a |
| 1641 | Content-Type header field defining the media type of that body. If |
| 1642 | and only if the media type is not given by a Content-Type header, as |
| 1643 | is the case for Simple-Response messages, the recipient may attempt |
| 1644 | to guess the media type via inspection of its content and/or the name |
| 1645 | extension(s) of the URL used to identify the resource. If the media |
| 1646 | type remains unknown, the recipient should treat it as type |
| 1647 | "application/octet-stream". |
| 1648 | |
| 1649 | 7.2.2 Length |
| 1650 | |
| 1651 | When an Entity-Body is included with a message, the length of that |
| 1652 | body may be determined in one of two ways. If a Content-Length header |
| 1653 | field is present, its value in bytes represents the length of the |
| 1654 | Entity-Body. Otherwise, the body length is determined by the closing |
| 1655 | of the connection by the server. |
| 1656 | |
| 1657 | Closing the connection cannot be used to indicate the end of a |
| 1658 | request body, since it leaves no possibility for the server to send |
| 1659 | back a response. Therefore, HTTP/1.0 requests containing an entity |
| 1660 | body must include a valid Content-Length header field. If a request |
| 1661 | contains an entity body and Content-Length is not specified, and the |
| 1662 | server does not recognize or cannot calculate the length from other |
| 1663 | fields, then the server should send a 400 (bad request) response. |
| 1664 | |
| 1665 | Note: Some older servers supply an invalid Content-Length when |
| 1666 | sending a document that contains server-side includes dynamically |
| 1667 | inserted into the data stream. It must be emphasized that this |
| 1668 | will not be tolerated by future versions of HTTP. Unless the |
| 1669 | client knows that it is receiving a response from a compliant |
| 1670 | server, it should not depend on the Content-Length value being |
| 1671 | correct. |
| 1672 | |
| 1673 | 8. Method Definitions |
| 1674 | |
| 1675 | The set of common methods for HTTP/1.0 is defined below. Although |
| 1676 | this set can be expanded, additional methods cannot be assumed to |
| 1677 | share the same semantics for separately extended clients and servers. |
| 1678 | |
| 1679 | |
| 1680 | |
| 1681 | |
| 1682 | Berners-Lee, et al Informational [Page 30] |
| 1683 | \f |
| 1684 | RFC 1945 HTTP/1.0 May 1996 |
| 1685 | |
| 1686 | |
| 1687 | 8.1 GET |
| 1688 | |
| 1689 | The GET method means retrieve whatever information (in the form of an |
| 1690 | entity) is identified by the Request-URI. If the Request-URI refers |
| 1691 | to a data-producing process, it is the produced data which shall be |
| 1692 | returned as the entity in the response and not the source text of the |
| 1693 | process, unless that text happens to be the output of the process. |
| 1694 | |
| 1695 | The semantics of the GET method changes to a "conditional GET" if the |
| 1696 | request message includes an If-Modified-Since header field. A |
| 1697 | conditional GET method requests that the identified resource be |
| 1698 | transferred only if it has been modified since the date given by the |
| 1699 | If-Modified-Since header, as described in Section 10.9. The |
| 1700 | conditional GET method is intended to reduce network usage by |
| 1701 | allowing cached entities to be refreshed without requiring multiple |
| 1702 | requests or transferring unnecessary data. |
| 1703 | |
| 1704 | 8.2 HEAD |
| 1705 | |
| 1706 | The HEAD method is identical to GET except that the server must not |
| 1707 | return any Entity-Body in the response. The metainformation contained |
| 1708 | in the HTTP headers in response to a HEAD request should be identical |
| 1709 | to the information sent in response to a GET request. This method can |
| 1710 | be used for obtaining metainformation about the resource identified |
| 1711 | by the Request-URI without transferring the Entity-Body itself. This |
| 1712 | method is often used for testing hypertext links for validity, |
| 1713 | accessibility, and recent modification. |
| 1714 | |
| 1715 | There is no "conditional HEAD" request analogous to the conditional |
| 1716 | GET. If an If-Modified-Since header field is included with a HEAD |
| 1717 | request, it should be ignored. |
| 1718 | |
| 1719 | 8.3 POST |
| 1720 | |
| 1721 | The POST method is used to request that the destination server accept |
| 1722 | the entity enclosed in the request as a new subordinate of the |
| 1723 | resource identified by the Request-URI in the Request-Line. POST is |
| 1724 | designed to allow a uniform method to cover the following functions: |
| 1725 | |
| 1726 | o Annotation of existing resources; |
| 1727 | |
| 1728 | o Posting a message to a bulletin board, newsgroup, mailing list, |
| 1729 | or similar group of articles; |
| 1730 | |
| 1731 | o Providing a block of data, such as the result of submitting a |
| 1732 | form [3], to a data-handling process; |
| 1733 | |
| 1734 | o Extending a database through an append operation. |
| 1735 | |
| 1736 | |
| 1737 | |
| 1738 | Berners-Lee, et al Informational [Page 31] |
| 1739 | \f |
| 1740 | RFC 1945 HTTP/1.0 May 1996 |
| 1741 | |
| 1742 | |
| 1743 | The actual function performed by the POST method is determined by the |
| 1744 | server and is usually dependent on the Request-URI. The posted entity |
| 1745 | is subordinate to that URI in the same way that a file is subordinate |
| 1746 | to a directory containing it, a news article is subordinate to a |
| 1747 | newsgroup to which it is posted, or a record is subordinate to a |
| 1748 | database. |
| 1749 | |
| 1750 | A successful POST does not require that the entity be created as a |
| 1751 | resource on the origin server or made accessible for future |
| 1752 | reference. That is, the action performed by the POST method might not |
| 1753 | result in a resource that can be identified by a URI. In this case, |
| 1754 | either 200 (ok) or 204 (no content) is the appropriate response |
| 1755 | status, depending on whether or not the response includes an entity |
| 1756 | that describes the result. |
| 1757 | |
| 1758 | If a resource has been created on the origin server, the response |
| 1759 | should be 201 (created) and contain an entity (preferably of type |
| 1760 | "text/html") which describes the status of the request and refers to |
| 1761 | the new resource. |
| 1762 | |
| 1763 | A valid Content-Length is required on all HTTP/1.0 POST requests. An |
| 1764 | HTTP/1.0 server should respond with a 400 (bad request) message if it |
| 1765 | cannot determine the length of the request message's content. |
| 1766 | |
| 1767 | Applications must not cache responses to a POST request because the |
| 1768 | application has no way of knowing that the server would return an |
| 1769 | equivalent response on some future request. |
| 1770 | |
| 1771 | 9. Status Code Definitions |
| 1772 | |
| 1773 | Each Status-Code is described below, including a description of which |
| 1774 | method(s) it can follow and any metainformation required in the |
| 1775 | response. |
| 1776 | |
| 1777 | 9.1 Informational 1xx |
| 1778 | |
| 1779 | This class of status code indicates a provisional response, |
| 1780 | consisting only of the Status-Line and optional headers, and is |
| 1781 | terminated by an empty line. HTTP/1.0 does not define any 1xx status |
| 1782 | codes and they are not a valid response to a HTTP/1.0 request. |
| 1783 | However, they may be useful for experimental applications which are |
| 1784 | outside the scope of this specification. |
| 1785 | |
| 1786 | 9.2 Successful 2xx |
| 1787 | |
| 1788 | This class of status code indicates that the client's request was |
| 1789 | successfully received, understood, and accepted. |
| 1790 | |
| 1791 | |
| 1792 | |
| 1793 | |
| 1794 | Berners-Lee, et al Informational [Page 32] |
| 1795 | \f |
| 1796 | RFC 1945 HTTP/1.0 May 1996 |
| 1797 | |
| 1798 | |
| 1799 | 200 OK |
| 1800 | |
| 1801 | The request has succeeded. The information returned with the |
| 1802 | response is dependent on the method used in the request, as follows: |
| 1803 | |
| 1804 | GET an entity corresponding to the requested resource is sent |
| 1805 | in the response; |
| 1806 | |
| 1807 | HEAD the response must only contain the header information and |
| 1808 | no Entity-Body; |
| 1809 | |
| 1810 | POST an entity describing or containing the result of the action. |
| 1811 | |
| 1812 | 201 Created |
| 1813 | |
| 1814 | The request has been fulfilled and resulted in a new resource being |
| 1815 | created. The newly created resource can be referenced by the URI(s) |
| 1816 | returned in the entity of the response. The origin server should |
| 1817 | create the resource before using this Status-Code. If the action |
| 1818 | cannot be carried out immediately, the server must include in the |
| 1819 | response body a description of when the resource will be available; |
| 1820 | otherwise, the server should respond with 202 (accepted). |
| 1821 | |
| 1822 | Of the methods defined by this specification, only POST can create a |
| 1823 | resource. |
| 1824 | |
| 1825 | 202 Accepted |
| 1826 | |
| 1827 | The request has been accepted for processing, but the processing |
| 1828 | has not been completed. The request may or may not eventually be |
| 1829 | acted upon, as it may be disallowed when processing actually takes |
| 1830 | place. There is no facility for re-sending a status code from an |
| 1831 | asynchronous operation such as this. |
| 1832 | |
| 1833 | The 202 response is intentionally non-committal. Its purpose is to |
| 1834 | allow a server to accept a request for some other process (perhaps |
| 1835 | a batch-oriented process that is only run once per day) without |
| 1836 | requiring that the user agent's connection to the server persist |
| 1837 | until the process is completed. The entity returned with this |
| 1838 | response should include an indication of the request's current |
| 1839 | status and either a pointer to a status monitor or some estimate of |
| 1840 | when the user can expect the request to be fulfilled. |
| 1841 | |
| 1842 | 204 No Content |
| 1843 | |
| 1844 | The server has fulfilled the request but there is no new |
| 1845 | information to send back. If the client is a user agent, it should |
| 1846 | not change its document view from that which caused the request to |
| 1847 | |
| 1848 | |
| 1849 | |
| 1850 | Berners-Lee, et al Informational [Page 33] |
| 1851 | \f |
| 1852 | RFC 1945 HTTP/1.0 May 1996 |
| 1853 | |
| 1854 | |
| 1855 | be generated. This response is primarily intended to allow input |
| 1856 | for scripts or other actions to take place without causing a change |
| 1857 | to the user agent's active document view. The response may include |
| 1858 | new metainformation in the form of entity headers, which should |
| 1859 | apply to the document currently in the user agent's active view. |
| 1860 | |
| 1861 | 9.3 Redirection 3xx |
| 1862 | |
| 1863 | This class of status code indicates that further action needs to be |
| 1864 | taken by the user agent in order to fulfill the request. The action |
| 1865 | required may be carried out by the user agent without interaction |
| 1866 | with the user if and only if the method used in the subsequent |
| 1867 | request is GET or HEAD. A user agent should never automatically |
| 1868 | redirect a request more than 5 times, since such redirections usually |
| 1869 | indicate an infinite loop. |
| 1870 | |
| 1871 | 300 Multiple Choices |
| 1872 | |
| 1873 | This response code is not directly used by HTTP/1.0 applications, |
| 1874 | but serves as the default for interpreting the 3xx class of |
| 1875 | responses. |
| 1876 | |
| 1877 | The requested resource is available at one or more locations. |
| 1878 | Unless it was a HEAD request, the response should include an entity |
| 1879 | containing a list of resource characteristics and locations from |
| 1880 | which the user or user agent can choose the one most appropriate. |
| 1881 | If the server has a preferred choice, it should include the URL in |
| 1882 | a Location field; user agents may use this field value for |
| 1883 | automatic redirection. |
| 1884 | |
| 1885 | 301 Moved Permanently |
| 1886 | |
| 1887 | The requested resource has been assigned a new permanent URL and |
| 1888 | any future references to this resource should be done using that |
| 1889 | URL. Clients with link editing capabilities should automatically |
| 1890 | relink references to the Request-URI to the new reference returned |
| 1891 | by the server, where possible. |
| 1892 | |
| 1893 | The new URL must be given by the Location field in the response. |
| 1894 | Unless it was a HEAD request, the Entity-Body of the response |
| 1895 | should contain a short note with a hyperlink to the new URL. |
| 1896 | |
| 1897 | If the 301 status code is received in response to a request using |
| 1898 | the POST method, the user agent must not automatically redirect the |
| 1899 | request unless it can be confirmed by the user, since this might |
| 1900 | change the conditions under which the request was issued. |
| 1901 | |
| 1902 | |
| 1903 | |
| 1904 | |
| 1905 | |
| 1906 | Berners-Lee, et al Informational [Page 34] |
| 1907 | \f |
| 1908 | RFC 1945 HTTP/1.0 May 1996 |
| 1909 | |
| 1910 | |
| 1911 | Note: When automatically redirecting a POST request after |
| 1912 | receiving a 301 status code, some existing user agents will |
| 1913 | erroneously change it into a GET request. |
| 1914 | |
| 1915 | 302 Moved Temporarily |
| 1916 | |
| 1917 | The requested resource resides temporarily under a different URL. |
| 1918 | Since the redirection may be altered on occasion, the client should |
| 1919 | continue to use the Request-URI for future requests. |
| 1920 | |
| 1921 | The URL must be given by the Location field in the response. Unless |
| 1922 | it was a HEAD request, the Entity-Body of the response should |
| 1923 | contain a short note with a hyperlink to the new URI(s). |
| 1924 | |
| 1925 | If the 302 status code is received in response to a request using |
| 1926 | the POST method, the user agent must not automatically redirect the |
| 1927 | request unless it can be confirmed by the user, since this might |
| 1928 | change the conditions under which the request was issued. |
| 1929 | |
| 1930 | Note: When automatically redirecting a POST request after |
| 1931 | receiving a 302 status code, some existing user agents will |
| 1932 | erroneously change it into a GET request. |
| 1933 | |
| 1934 | 304 Not Modified |
| 1935 | |
| 1936 | If the client has performed a conditional GET request and access is |
| 1937 | allowed, but the document has not been modified since the date and |
| 1938 | time specified in the If-Modified-Since field, the server must |
| 1939 | respond with this status code and not send an Entity-Body to the |
| 1940 | client. Header fields contained in the response should only include |
| 1941 | information which is relevant to cache managers or which may have |
| 1942 | changed independently of the entity's Last-Modified date. Examples |
| 1943 | of relevant header fields include: Date, Server, and Expires. A |
| 1944 | cache should update its cached entity to reflect any new field |
| 1945 | values given in the 304 response. |
| 1946 | |
| 1947 | 9.4 Client Error 4xx |
| 1948 | |
| 1949 | The 4xx class of status code is intended for cases in which the |
| 1950 | client seems to have erred. If the client has not completed the |
| 1951 | request when a 4xx code is received, it should immediately cease |
| 1952 | sending data to the server. Except when responding to a HEAD request, |
| 1953 | the server should include an entity containing an explanation of the |
| 1954 | error situation, and whether it is a temporary or permanent |
| 1955 | condition. These status codes are applicable to any request method. |
| 1956 | |
| 1957 | |
| 1958 | |
| 1959 | |
| 1960 | |
| 1961 | |
| 1962 | Berners-Lee, et al Informational [Page 35] |
| 1963 | \f |
| 1964 | RFC 1945 HTTP/1.0 May 1996 |
| 1965 | |
| 1966 | |
| 1967 | Note: If the client is sending data, server implementations on TCP |
| 1968 | should be careful to ensure that the client acknowledges receipt |
| 1969 | of the packet(s) containing the response prior to closing the |
| 1970 | input connection. If the client continues sending data to the |
| 1971 | server after the close, the server's controller will send a reset |
| 1972 | packet to the client, which may erase the client's unacknowledged |
| 1973 | input buffers before they can be read and interpreted by the HTTP |
| 1974 | application. |
| 1975 | |
| 1976 | 400 Bad Request |
| 1977 | |
| 1978 | The request could not be understood by the server due to malformed |
| 1979 | syntax. The client should not repeat the request without |
| 1980 | modifications. |
| 1981 | |
| 1982 | 401 Unauthorized |
| 1983 | |
| 1984 | The request requires user authentication. The response must include |
| 1985 | a WWW-Authenticate header field (Section 10.16) containing a |
| 1986 | challenge applicable to the requested resource. The client may |
| 1987 | repeat the request with a suitable Authorization header field |
| 1988 | (Section 10.2). If the request already included Authorization |
| 1989 | credentials, then the 401 response indicates that authorization has |
| 1990 | been refused for those credentials. If the 401 response contains |
| 1991 | the same challenge as the prior response, and the user agent has |
| 1992 | already attempted authentication at least once, then the user |
| 1993 | should be presented the entity that was given in the response, |
| 1994 | since that entity may include relevant diagnostic information. HTTP |
| 1995 | access authentication is explained in Section 11. |
| 1996 | |
| 1997 | 403 Forbidden |
| 1998 | |
| 1999 | The server understood the request, but is refusing to fulfill it. |
| 2000 | Authorization will not help and the request should not be repeated. |
| 2001 | If the request method was not HEAD and the server wishes to make |
| 2002 | public why the request has not been fulfilled, it should describe |
| 2003 | the reason for the refusal in the entity body. This status code is |
| 2004 | commonly used when the server does not wish to reveal exactly why |
| 2005 | the request has been refused, or when no other response is |
| 2006 | applicable. |
| 2007 | |
| 2008 | 404 Not Found |
| 2009 | |
| 2010 | The server has not found anything matching the Request-URI. No |
| 2011 | indication is given of whether the condition is temporary or |
| 2012 | permanent. If the server does not wish to make this information |
| 2013 | available to the client, the status code 403 (forbidden) can be |
| 2014 | used instead. |
| 2015 | |
| 2016 | |
| 2017 | |
| 2018 | Berners-Lee, et al Informational [Page 36] |
| 2019 | \f |
| 2020 | RFC 1945 HTTP/1.0 May 1996 |
| 2021 | |
| 2022 | |
| 2023 | 9.5 Server Error 5xx |
| 2024 | |
| 2025 | Response status codes beginning with the digit "5" indicate cases in |
| 2026 | which the server is aware that it has erred or is incapable of |
| 2027 | performing the request. If the client has not completed the request |
| 2028 | when a 5xx code is received, it should immediately cease sending data |
| 2029 | to the server. Except when responding to a HEAD request, the server |
| 2030 | should include an entity containing an explanation of the error |
| 2031 | situation, and whether it is a temporary or permanent condition. |
| 2032 | These response codes are applicable to any request method and there |
| 2033 | are no required header fields. |
| 2034 | |
| 2035 | 500 Internal Server Error |
| 2036 | |
| 2037 | The server encountered an unexpected condition which prevented it |
| 2038 | from fulfilling the request. |
| 2039 | |
| 2040 | 501 Not Implemented |
| 2041 | |
| 2042 | The server does not support the functionality required to fulfill |
| 2043 | the request. This is the appropriate response when the server does |
| 2044 | not recognize the request method and is not capable of supporting |
| 2045 | it for any resource. |
| 2046 | |
| 2047 | 502 Bad Gateway |
| 2048 | |
| 2049 | The server, while acting as a gateway or proxy, received an invalid |
| 2050 | response from the upstream server it accessed in attempting to |
| 2051 | fulfill the request. |
| 2052 | |
| 2053 | 503 Service Unavailable |
| 2054 | |
| 2055 | The server is currently unable to handle the request due to a |
| 2056 | temporary overloading or maintenance of the server. The implication |
| 2057 | is that this is a temporary condition which will be alleviated |
| 2058 | after some delay. |
| 2059 | |
| 2060 | Note: The existence of the 503 status code does not imply |
| 2061 | that a server must use it when becoming overloaded. Some |
| 2062 | servers may wish to simply refuse the connection. |
| 2063 | |
| 2064 | 10. Header Field Definitions |
| 2065 | |
| 2066 | This section defines the syntax and semantics of all commonly used |
| 2067 | HTTP/1.0 header fields. For general and entity header fields, both |
| 2068 | sender and recipient refer to either the client or the server, |
| 2069 | depending on who sends and who receives the message. |
| 2070 | |
| 2071 | |
| 2072 | |
| 2073 | |
| 2074 | Berners-Lee, et al Informational [Page 37] |
| 2075 | \f |
| 2076 | RFC 1945 HTTP/1.0 May 1996 |
| 2077 | |
| 2078 | |
| 2079 | 10.1 Allow |
| 2080 | |
| 2081 | The Allow entity-header field lists the set of methods supported by |
| 2082 | the resource identified by the Request-URI. The purpose of this field |
| 2083 | is strictly to inform the recipient of valid methods associated with |
| 2084 | the resource. The Allow header field is not permitted in a request |
| 2085 | using the POST method, and thus should be ignored if it is received |
| 2086 | as part of a POST entity. |
| 2087 | |
| 2088 | Allow = "Allow" ":" 1#method |
| 2089 | |
| 2090 | Example of use: |
| 2091 | |
| 2092 | Allow: GET, HEAD |
| 2093 | |
| 2094 | This field cannot prevent a client from trying other methods. |
| 2095 | However, the indications given by the Allow header field value should |
| 2096 | be followed. The actual set of allowed methods is defined by the |
| 2097 | origin server at the time of each request. |
| 2098 | |
| 2099 | A proxy must not modify the Allow header field even if it does not |
| 2100 | understand all the methods specified, since the user agent may have |
| 2101 | other means of communicating with the origin server. |
| 2102 | |
| 2103 | The Allow header field does not indicate what methods are implemented |
| 2104 | by the server. |
| 2105 | |
| 2106 | 10.2 Authorization |
| 2107 | |
| 2108 | A user agent that wishes to authenticate itself with a server-- |
| 2109 | usually, but not necessarily, after receiving a 401 response--may do |
| 2110 | so by including an Authorization request-header field with the |
| 2111 | request. The Authorization field value consists of credentials |
| 2112 | containing the authentication information of the user agent for the |
| 2113 | realm of the resource being requested. |
| 2114 | |
| 2115 | Authorization = "Authorization" ":" credentials |
| 2116 | |
| 2117 | HTTP access authentication is described in Section 11. If a request |
| 2118 | is authenticated and a realm specified, the same credentials should |
| 2119 | be valid for all other requests within this realm. |
| 2120 | |
| 2121 | Responses to requests containing an Authorization field are not |
| 2122 | cachable. |
| 2123 | |
| 2124 | |
| 2125 | |
| 2126 | |
| 2127 | |
| 2128 | |
| 2129 | |
| 2130 | Berners-Lee, et al Informational [Page 38] |
| 2131 | \f |
| 2132 | RFC 1945 HTTP/1.0 May 1996 |
| 2133 | |
| 2134 | |
| 2135 | 10.3 Content-Encoding |
| 2136 | |
| 2137 | The Content-Encoding entity-header field is used as a modifier to the |
| 2138 | media-type. When present, its value indicates what additional content |
| 2139 | coding has been applied to the resource, and thus what decoding |
| 2140 | mechanism must be applied in order to obtain the media-type |
| 2141 | referenced by the Content-Type header field. The Content-Encoding is |
| 2142 | primarily used to allow a document to be compressed without losing |
| 2143 | the identity of its underlying media type. |
| 2144 | |
| 2145 | Content-Encoding = "Content-Encoding" ":" content-coding |
| 2146 | |
| 2147 | Content codings are defined in Section 3.5. An example of its use is |
| 2148 | |
| 2149 | Content-Encoding: x-gzip |
| 2150 | |
| 2151 | The Content-Encoding is a characteristic of the resource identified |
| 2152 | by the Request-URI. Typically, the resource is stored with this |
| 2153 | encoding and is only decoded before rendering or analogous usage. |
| 2154 | |
| 2155 | 10.4 Content-Length |
| 2156 | |
| 2157 | The Content-Length entity-header field indicates the size of the |
| 2158 | Entity-Body, in decimal number of octets, sent to the recipient or, |
| 2159 | in the case of the HEAD method, the size of the Entity-Body that |
| 2160 | would have been sent had the request been a GET. |
| 2161 | |
| 2162 | Content-Length = "Content-Length" ":" 1*DIGIT |
| 2163 | |
| 2164 | An example is |
| 2165 | |
| 2166 | Content-Length: 3495 |
| 2167 | |
| 2168 | Applications should use this field to indicate the size of the |
| 2169 | Entity-Body to be transferred, regardless of the media type of the |
| 2170 | entity. A valid Content-Length field value is required on all |
| 2171 | HTTP/1.0 request messages containing an entity body. |
| 2172 | |
| 2173 | Any Content-Length greater than or equal to zero is a valid value. |
| 2174 | Section 7.2.2 describes how to determine the length of a response |
| 2175 | entity body if a Content-Length is not given. |
| 2176 | |
| 2177 | Note: The meaning of this field is significantly different from |
| 2178 | the corresponding definition in MIME, where it is an optional |
| 2179 | field used within the "message/external-body" content-type. In |
| 2180 | HTTP, it should be used whenever the entity's length can be |
| 2181 | determined prior to being transferred. |
| 2182 | |
| 2183 | |
| 2184 | |
| 2185 | |
| 2186 | Berners-Lee, et al Informational [Page 39] |
| 2187 | \f |
| 2188 | RFC 1945 HTTP/1.0 May 1996 |
| 2189 | |
| 2190 | |
| 2191 | 10.5 Content-Type |
| 2192 | |
| 2193 | The Content-Type entity-header field indicates the media type of the |
| 2194 | Entity-Body sent to the recipient or, in the case of the HEAD method, |
| 2195 | the media type that would have been sent had the request been a GET. |
| 2196 | |
| 2197 | Content-Type = "Content-Type" ":" media-type |
| 2198 | |
| 2199 | Media types are defined in Section 3.6. An example of the field is |
| 2200 | |
| 2201 | Content-Type: text/html |
| 2202 | |
| 2203 | Further discussion of methods for identifying the media type of an |
| 2204 | entity is provided in Section 7.2.1. |
| 2205 | |
| 2206 | 10.6 Date |
| 2207 | |
| 2208 | The Date general-header field represents the date and time at which |
| 2209 | the message was originated, having the same semantics as orig-date in |
| 2210 | RFC 822. The field value is an HTTP-date, as described in Section |
| 2211 | 3.3. |
| 2212 | |
| 2213 | Date = "Date" ":" HTTP-date |
| 2214 | |
| 2215 | An example is |
| 2216 | |
| 2217 | Date: Tue, 15 Nov 1994 08:12:31 GMT |
| 2218 | |
| 2219 | If a message is received via direct connection with the user agent |
| 2220 | (in the case of requests) or the origin server (in the case of |
| 2221 | responses), then the date can be assumed to be the current date at |
| 2222 | the receiving end. However, since the date--as it is believed by the |
| 2223 | origin--is important for evaluating cached responses, origin servers |
| 2224 | should always include a Date header. Clients should only send a Date |
| 2225 | header field in messages that include an entity body, as in the case |
| 2226 | of the POST request, and even then it is optional. A received message |
| 2227 | which does not have a Date header field should be assigned one by the |
| 2228 | recipient if the message will be cached by that recipient or |
| 2229 | gatewayed via a protocol which requires a Date. |
| 2230 | |
| 2231 | In theory, the date should represent the moment just before the |
| 2232 | entity is generated. In practice, the date can be generated at any |
| 2233 | time during the message origination without affecting its semantic |
| 2234 | value. |
| 2235 | |
| 2236 | Note: An earlier version of this document incorrectly specified |
| 2237 | that this field should contain the creation date of the enclosed |
| 2238 | Entity-Body. This has been changed to reflect actual (and proper) |
| 2239 | |
| 2240 | |
| 2241 | |
| 2242 | Berners-Lee, et al Informational [Page 40] |
| 2243 | \f |
| 2244 | RFC 1945 HTTP/1.0 May 1996 |
| 2245 | |
| 2246 | |
| 2247 | usage. |
| 2248 | |
| 2249 | 10.7 Expires |
| 2250 | |
| 2251 | The Expires entity-header field gives the date/time after which the |
| 2252 | entity should be considered stale. This allows information providers |
| 2253 | to suggest the volatility of the resource, or a date after which the |
| 2254 | information may no longer be valid. Applications must not cache this |
| 2255 | entity beyond the date given. The presence of an Expires field does |
| 2256 | not imply that the original resource will change or cease to exist |
| 2257 | at, before, or after that time. However, information providers that |
| 2258 | know or even suspect that a resource will change by a certain date |
| 2259 | should include an Expires header with that date. The format is an |
| 2260 | absolute date and time as defined by HTTP-date in Section 3.3. |
| 2261 | |
| 2262 | Expires = "Expires" ":" HTTP-date |
| 2263 | |
| 2264 | An example of its use is |
| 2265 | |
| 2266 | Expires: Thu, 01 Dec 1994 16:00:00 GMT |
| 2267 | |
| 2268 | If the date given is equal to or earlier than the value of the Date |
| 2269 | header, the recipient must not cache the enclosed entity. If a |
| 2270 | resource is dynamic by nature, as is the case with many data- |
| 2271 | producing processes, entities from that resource should be given an |
| 2272 | appropriate Expires value which reflects that dynamism. |
| 2273 | |
| 2274 | The Expires field cannot be used to force a user agent to refresh its |
| 2275 | display or reload a resource; its semantics apply only to caching |
| 2276 | mechanisms, and such mechanisms need only check a resource's |
| 2277 | expiration status when a new request for that resource is initiated. |
| 2278 | |
| 2279 | User agents often have history mechanisms, such as "Back" buttons and |
| 2280 | history lists, which can be used to redisplay an entity retrieved |
| 2281 | earlier in a session. By default, the Expires field does not apply to |
| 2282 | history mechanisms. If the entity is still in storage, a history |
| 2283 | mechanism should display it even if the entity has expired, unless |
| 2284 | the user has specifically configured the agent to refresh expired |
| 2285 | history documents. |
| 2286 | |
| 2287 | Note: Applications are encouraged to be tolerant of bad or |
| 2288 | misinformed implementations of the Expires header. A value of zero |
| 2289 | (0) or an invalid date format should be considered equivalent to |
| 2290 | an "expires immediately." Although these values are not legitimate |
| 2291 | for HTTP/1.0, a robust implementation is always desirable. |
| 2292 | |
| 2293 | |
| 2294 | |
| 2295 | |
| 2296 | |
| 2297 | |
| 2298 | Berners-Lee, et al Informational [Page 41] |
| 2299 | \f |
| 2300 | RFC 1945 HTTP/1.0 May 1996 |
| 2301 | |
| 2302 | |
| 2303 | 10.8 From |
| 2304 | |
| 2305 | The From request-header field, if given, should contain an Internet |
| 2306 | e-mail address for the human user who controls the requesting user |
| 2307 | agent. The address should be machine-usable, as defined by mailbox in |
| 2308 | RFC 822 [7] (as updated by RFC 1123 [6]): |
| 2309 | |
| 2310 | From = "From" ":" mailbox |
| 2311 | |
| 2312 | An example is: |
| 2313 | |
| 2314 | From: webmaster@w3.org |
| 2315 | |
| 2316 | This header field may be used for logging purposes and as a means for |
| 2317 | identifying the source of invalid or unwanted requests. It should not |
| 2318 | be used as an insecure form of access protection. The interpretation |
| 2319 | of this field is that the request is being performed on behalf of the |
| 2320 | person given, who accepts responsibility for the method performed. In |
| 2321 | particular, robot agents should include this header so that the |
| 2322 | person responsible for running the robot can be contacted if problems |
| 2323 | occur on the receiving end. |
| 2324 | |
| 2325 | The Internet e-mail address in this field may be separate from the |
| 2326 | Internet host which issued the request. For example, when a request |
| 2327 | is passed through a proxy, the original issuer's address should be |
| 2328 | used. |
| 2329 | |
| 2330 | Note: The client should not send the From header field without the |
| 2331 | user's approval, as it may conflict with the user's privacy |
| 2332 | interests or their site's security policy. It is strongly |
| 2333 | recommended that the user be able to disable, enable, and modify |
| 2334 | the value of this field at any time prior to a request. |
| 2335 | |
| 2336 | 10.9 If-Modified-Since |
| 2337 | |
| 2338 | The If-Modified-Since request-header field is used with the GET |
| 2339 | method to make it conditional: if the requested resource has not been |
| 2340 | modified since the time specified in this field, a copy of the |
| 2341 | resource will not be returned from the server; instead, a 304 (not |
| 2342 | modified) response will be returned without any Entity-Body. |
| 2343 | |
| 2344 | If-Modified-Since = "If-Modified-Since" ":" HTTP-date |
| 2345 | |
| 2346 | An example of the field is: |
| 2347 | |
| 2348 | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
| 2349 | |
| 2350 | |
| 2351 | |
| 2352 | |
| 2353 | |
| 2354 | Berners-Lee, et al Informational [Page 42] |
| 2355 | \f |
| 2356 | RFC 1945 HTTP/1.0 May 1996 |
| 2357 | |
| 2358 | |
| 2359 | A conditional GET method requests that the identified resource be |
| 2360 | transferred only if it has been modified since the date given by the |
| 2361 | If-Modified-Since header. The algorithm for determining this includes |
| 2362 | the following cases: |
| 2363 | |
| 2364 | a) If the request would normally result in anything other than |
| 2365 | a 200 (ok) status, or if the passed If-Modified-Since date |
| 2366 | is invalid, the response is exactly the same as for a |
| 2367 | normal GET. A date which is later than the server's current |
| 2368 | time is invalid. |
| 2369 | |
| 2370 | b) If the resource has been modified since the |
| 2371 | If-Modified-Since date, the response is exactly the same as |
| 2372 | for a normal GET. |
| 2373 | |
| 2374 | c) If the resource has not been modified since a valid |
| 2375 | If-Modified-Since date, the server shall return a 304 (not |
| 2376 | modified) response. |
| 2377 | |
| 2378 | The purpose of this feature is to allow efficient updates of cached |
| 2379 | information with a minimum amount of transaction overhead. |
| 2380 | |
| 2381 | 10.10 Last-Modified |
| 2382 | |
| 2383 | The Last-Modified entity-header field indicates the date and time at |
| 2384 | which the sender believes the resource was last modified. The exact |
| 2385 | semantics of this field are defined in terms of how the recipient |
| 2386 | should interpret it: if the recipient has a copy of this resource |
| 2387 | which is older than the date given by the Last-Modified field, that |
| 2388 | copy should be considered stale. |
| 2389 | |
| 2390 | Last-Modified = "Last-Modified" ":" HTTP-date |
| 2391 | |
| 2392 | An example of its use is |
| 2393 | |
| 2394 | Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT |
| 2395 | |
| 2396 | The exact meaning of this header field depends on the implementation |
| 2397 | of the sender and the nature of the original resource. For files, it |
| 2398 | may be just the file system last-modified time. For entities with |
| 2399 | dynamically included parts, it may be the most recent of the set of |
| 2400 | last-modify times for its component parts. For database gateways, it |
| 2401 | may be the last-update timestamp of the record. For virtual objects, |
| 2402 | it may be the last time the internal state changed. |
| 2403 | |
| 2404 | An origin server must not send a Last-Modified date which is later |
| 2405 | than the server's time of message origination. In such cases, where |
| 2406 | the resource's last modification would indicate some time in the |
| 2407 | |
| 2408 | |
| 2409 | |
| 2410 | Berners-Lee, et al Informational [Page 43] |
| 2411 | \f |
| 2412 | RFC 1945 HTTP/1.0 May 1996 |
| 2413 | |
| 2414 | |
| 2415 | future, the server must replace that date with the message |
| 2416 | origination date. |
| 2417 | |
| 2418 | 10.11 Location |
| 2419 | |
| 2420 | The Location response-header field defines the exact location of the |
| 2421 | resource that was identified by the Request-URI. For 3xx responses, |
| 2422 | the location must indicate the server's preferred URL for automatic |
| 2423 | redirection to the resource. Only one absolute URL is allowed. |
| 2424 | |
| 2425 | Location = "Location" ":" absoluteURI |
| 2426 | |
| 2427 | An example is |
| 2428 | |
| 2429 | Location: http://www.w3.org/hypertext/WWW/NewLocation.html |
| 2430 | |
| 2431 | 10.12 Pragma |
| 2432 | |
| 2433 | The Pragma general-header field is used to include implementation- |
| 2434 | specific directives that may apply to any recipient along the |
| 2435 | request/response chain. All pragma directives specify optional |
| 2436 | behavior from the viewpoint of the protocol; however, some systems |
| 2437 | may require that behavior be consistent with the directives. |
| 2438 | |
| 2439 | Pragma = "Pragma" ":" 1#pragma-directive |
| 2440 | |
| 2441 | pragma-directive = "no-cache" | extension-pragma |
| 2442 | extension-pragma = token [ "=" word ] |
| 2443 | |
| 2444 | When the "no-cache" directive is present in a request message, an |
| 2445 | application should forward the request toward the origin server even |
| 2446 | if it has a cached copy of what is being requested. This allows a |
| 2447 | client to insist upon receiving an authoritative response to its |
| 2448 | request. It also allows a client to refresh a cached copy which is |
| 2449 | known to be corrupted or stale. |
| 2450 | |
| 2451 | Pragma directives must be passed through by a proxy or gateway |
| 2452 | application, regardless of their significance to that application, |
| 2453 | since the directives may be applicable to all recipients along the |
| 2454 | request/response chain. It is not possible to specify a pragma for a |
| 2455 | specific recipient; however, any pragma directive not relevant to a |
| 2456 | recipient should be ignored by that recipient. |
| 2457 | |
| 2458 | 10.13 Referer |
| 2459 | |
| 2460 | The Referer request-header field allows the client to specify, for |
| 2461 | the server's benefit, the address (URI) of the resource from which |
| 2462 | the Request-URI was obtained. This allows a server to generate lists |
| 2463 | |
| 2464 | |
| 2465 | |
| 2466 | Berners-Lee, et al Informational [Page 44] |
| 2467 | \f |
| 2468 | RFC 1945 HTTP/1.0 May 1996 |
| 2469 | |
| 2470 | |
| 2471 | of back-links to resources for interest, logging, optimized caching, |
| 2472 | etc. It also allows obsolete or mistyped links to be traced for |
| 2473 | maintenance. The Referer field must not be sent if the Request-URI |
| 2474 | was obtained from a source that does not have its own URI, such as |
| 2475 | input from the user keyboard. |
| 2476 | |
| 2477 | Referer = "Referer" ":" ( absoluteURI | relativeURI ) |
| 2478 | |
| 2479 | Example: |
| 2480 | |
| 2481 | Referer: http://www.w3.org/hypertext/DataSources/Overview.html |
| 2482 | |
| 2483 | If a partial URI is given, it should be interpreted relative to the |
| 2484 | Request-URI. The URI must not include a fragment. |
| 2485 | |
| 2486 | Note: Because the source of a link may be private information or |
| 2487 | may reveal an otherwise private information source, it is strongly |
| 2488 | recommended that the user be able to select whether or not the |
| 2489 | Referer field is sent. For example, a browser client could have a |
| 2490 | toggle switch for browsing openly/anonymously, which would |
| 2491 | respectively enable/disable the sending of Referer and From |
| 2492 | information. |
| 2493 | |
| 2494 | 10.14 Server |
| 2495 | |
| 2496 | The Server response-header field contains information about the |
| 2497 | software used by the origin server to handle the request. The field |
| 2498 | can contain multiple product tokens (Section 3.7) and comments |
| 2499 | identifying the server and any significant subproducts. By |
| 2500 | convention, the product tokens are listed in order of their |
| 2501 | significance for identifying the application. |
| 2502 | |
| 2503 | Server = "Server" ":" 1*( product | comment ) |
| 2504 | |
| 2505 | Example: |
| 2506 | |
| 2507 | Server: CERN/3.0 libwww/2.17 |
| 2508 | |
| 2509 | If the response is being forwarded through a proxy, the proxy |
| 2510 | application must not add its data to the product list. |
| 2511 | |
| 2512 | Note: Revealing the specific software version of the server may |
| 2513 | allow the server machine to become more vulnerable to attacks |
| 2514 | against software that is known to contain security holes. Server |
| 2515 | implementors are encouraged to make this field a configurable |
| 2516 | option. |
| 2517 | |
| 2518 | |
| 2519 | |
| 2520 | |
| 2521 | |
| 2522 | Berners-Lee, et al Informational [Page 45] |
| 2523 | \f |
| 2524 | RFC 1945 HTTP/1.0 May 1996 |
| 2525 | |
| 2526 | |
| 2527 | Note: Some existing servers fail to restrict themselves to the |
| 2528 | product token syntax within the Server field. |
| 2529 | |
| 2530 | 10.15 User-Agent |
| 2531 | |
| 2532 | The User-Agent request-header field contains information about the |
| 2533 | user agent originating the request. This is for statistical purposes, |
| 2534 | the tracing of protocol violations, and automated recognition of user |
| 2535 | agents for the sake of tailoring responses to avoid particular user |
| 2536 | agent limitations. Although it is not required, user agents should |
| 2537 | include this field with requests. The field can contain multiple |
| 2538 | product tokens (Section 3.7) and comments identifying the agent and |
| 2539 | any subproducts which form a significant part of the user agent. By |
| 2540 | convention, the product tokens are listed in order of their |
| 2541 | significance for identifying the application. |
| 2542 | |
| 2543 | User-Agent = "User-Agent" ":" 1*( product | comment ) |
| 2544 | |
| 2545 | Example: |
| 2546 | |
| 2547 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
| 2548 | |
| 2549 | Note: Some current proxy applications append their product |
| 2550 | information to the list in the User-Agent field. This is not |
| 2551 | recommended, since it makes machine interpretation of these |
| 2552 | fields ambiguous. |
| 2553 | |
| 2554 | Note: Some existing clients fail to restrict themselves to |
| 2555 | the product token syntax within the User-Agent field. |
| 2556 | |
| 2557 | 10.16 WWW-Authenticate |
| 2558 | |
| 2559 | The WWW-Authenticate response-header field must be included in 401 |
| 2560 | (unauthorized) response messages. The field value consists of at |
| 2561 | least one challenge that indicates the authentication scheme(s) and |
| 2562 | parameters applicable to the Request-URI. |
| 2563 | |
| 2564 | WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge |
| 2565 | |
| 2566 | The HTTP access authentication process is described in Section 11. |
| 2567 | User agents must take special care in parsing the WWW-Authenticate |
| 2568 | field value if it contains more than one challenge, or if more than |
| 2569 | one WWW-Authenticate header field is provided, since the contents of |
| 2570 | a challenge may itself contain a comma-separated list of |
| 2571 | authentication parameters. |
| 2572 | |
| 2573 | |
| 2574 | |
| 2575 | |
| 2576 | |
| 2577 | |
| 2578 | Berners-Lee, et al Informational [Page 46] |
| 2579 | \f |
| 2580 | RFC 1945 HTTP/1.0 May 1996 |
| 2581 | |
| 2582 | |
| 2583 | 11. Access Authentication |
| 2584 | |
| 2585 | HTTP provides a simple challenge-response authentication mechanism |
| 2586 | which may be used by a server to challenge a client request and by a |
| 2587 | client to provide authentication information. It uses an extensible, |
| 2588 | case-insensitive token to identify the authentication scheme, |
| 2589 | followed by a comma-separated list of attribute-value pairs which |
| 2590 | carry the parameters necessary for achieving authentication via that |
| 2591 | scheme. |
| 2592 | |
| 2593 | auth-scheme = token |
| 2594 | |
| 2595 | auth-param = token "=" quoted-string |
| 2596 | |
| 2597 | The 401 (unauthorized) response message is used by an origin server |
| 2598 | to challenge the authorization of a user agent. This response must |
| 2599 | include a WWW-Authenticate header field containing at least one |
| 2600 | challenge applicable to the requested resource. |
| 2601 | |
| 2602 | challenge = auth-scheme 1*SP realm *( "," auth-param ) |
| 2603 | |
| 2604 | realm = "realm" "=" realm-value |
| 2605 | realm-value = quoted-string |
| 2606 | |
| 2607 | The realm attribute (case-insensitive) is required for all |
| 2608 | authentication schemes which issue a challenge. The realm value |
| 2609 | (case-sensitive), in combination with the canonical root URL of the |
| 2610 | server being accessed, defines the protection space. These realms |
| 2611 | allow the protected resources on a server to be partitioned into a |
| 2612 | set of protection spaces, each with its own authentication scheme |
| 2613 | and/or authorization database. The realm value is a string, generally |
| 2614 | assigned by the origin server, which may have additional semantics |
| 2615 | specific to the authentication scheme. |
| 2616 | |
| 2617 | A user agent that wishes to authenticate itself with a server-- |
| 2618 | usually, but not necessarily, after receiving a 401 response--may do |
| 2619 | so by including an Authorization header field with the request. The |
| 2620 | Authorization field value consists of credentials containing the |
| 2621 | authentication information of the user agent for the realm of the |
| 2622 | resource being requested. |
| 2623 | |
| 2624 | credentials = basic-credentials |
| 2625 | | ( auth-scheme #auth-param ) |
| 2626 | |
| 2627 | The domain over which credentials can be automatically applied by a |
| 2628 | user agent is determined by the protection space. If a prior request |
| 2629 | has been authorized, the same credentials may be reused for all other |
| 2630 | requests within that protection space for a period of time determined |
| 2631 | |
| 2632 | |
| 2633 | |
| 2634 | Berners-Lee, et al Informational [Page 47] |
| 2635 | \f |
| 2636 | RFC 1945 HTTP/1.0 May 1996 |
| 2637 | |
| 2638 | |
| 2639 | by the authentication scheme, parameters, and/or user preference. |
| 2640 | Unless otherwise defined by the authentication scheme, a single |
| 2641 | protection space cannot extend outside the scope of its server. |
| 2642 | |
| 2643 | If the server does not wish to accept the credentials sent with a |
| 2644 | request, it should return a 403 (forbidden) response. |
| 2645 | |
| 2646 | The HTTP protocol does not restrict applications to this simple |
| 2647 | challenge-response mechanism for access authentication. Additional |
| 2648 | mechanisms may be used, such as encryption at the transport level or |
| 2649 | via message encapsulation, and with additional header fields |
| 2650 | specifying authentication information. However, these additional |
| 2651 | mechanisms are not defined by this specification. |
| 2652 | |
| 2653 | Proxies must be completely transparent regarding user agent |
| 2654 | authentication. That is, they must forward the WWW-Authenticate and |
| 2655 | Authorization headers untouched, and must not cache the response to a |
| 2656 | request containing Authorization. HTTP/1.0 does not provide a means |
| 2657 | for a client to be authenticated with a proxy. |
| 2658 | |
| 2659 | 11.1 Basic Authentication Scheme |
| 2660 | |
| 2661 | The "basic" authentication scheme is based on the model that the user |
| 2662 | agent must authenticate itself with a user-ID and a password for each |
| 2663 | realm. The realm value should be considered an opaque string which |
| 2664 | can only be compared for equality with other realms on that server. |
| 2665 | The server will authorize the request only if it can validate the |
| 2666 | user-ID and password for the protection space of the Request-URI. |
| 2667 | There are no optional authentication parameters. |
| 2668 | |
| 2669 | Upon receipt of an unauthorized request for a URI within the |
| 2670 | protection space, the server should respond with a challenge like the |
| 2671 | following: |
| 2672 | |
| 2673 | WWW-Authenticate: Basic realm="WallyWorld" |
| 2674 | |
| 2675 | where "WallyWorld" is the string assigned by the server to identify |
| 2676 | the protection space of the Request-URI. |
| 2677 | |
| 2678 | To receive authorization, the client sends the user-ID and password, |
| 2679 | separated by a single colon (":") character, within a base64 [5] |
| 2680 | encoded string in the credentials. |
| 2681 | |
| 2682 | basic-credentials = "Basic" SP basic-cookie |
| 2683 | |
| 2684 | basic-cookie = <base64 [5] encoding of userid-password, |
| 2685 | except not limited to 76 char/line> |
| 2686 | |
| 2687 | |
| 2688 | |
| 2689 | |
| 2690 | Berners-Lee, et al Informational [Page 48] |
| 2691 | \f |
| 2692 | RFC 1945 HTTP/1.0 May 1996 |
| 2693 | |
| 2694 | |
| 2695 | userid-password = [ token ] ":" *TEXT |
| 2696 | |
| 2697 | If the user agent wishes to send the user-ID "Aladdin" and password |
| 2698 | "open sesame", it would use the following header field: |
| 2699 | |
| 2700 | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| 2701 | |
| 2702 | The basic authentication scheme is a non-secure method of filtering |
| 2703 | unauthorized access to resources on an HTTP server. It is based on |
| 2704 | the assumption that the connection between the client and the server |
| 2705 | can be regarded as a trusted carrier. As this is not generally true |
| 2706 | on an open network, the basic authentication scheme should be used |
| 2707 | accordingly. In spite of this, clients should implement the scheme in |
| 2708 | order to communicate with servers that use it. |
| 2709 | |
| 2710 | 12. Security Considerations |
| 2711 | |
| 2712 | This section is meant to inform application developers, information |
| 2713 | providers, and users of the security limitations in HTTP/1.0 as |
| 2714 | described by this document. The discussion does not include |
| 2715 | definitive solutions to the problems revealed, though it does make |
| 2716 | some suggestions for reducing security risks. |
| 2717 | |
| 2718 | 12.1 Authentication of Clients |
| 2719 | |
| 2720 | As mentioned in Section 11.1, the Basic authentication scheme is not |
| 2721 | a secure method of user authentication, nor does it prevent the |
| 2722 | Entity-Body from being transmitted in clear text across the physical |
| 2723 | network used as the carrier. HTTP/1.0 does not prevent additional |
| 2724 | authentication schemes and encryption mechanisms from being employed |
| 2725 | to increase security. |
| 2726 | |
| 2727 | 12.2 Safe Methods |
| 2728 | |
| 2729 | The writers of client software should be aware that the software |
| 2730 | represents the user in their interactions over the Internet, and |
| 2731 | should be careful to allow the user to be aware of any actions they |
| 2732 | may take which may have an unexpected significance to themselves or |
| 2733 | others. |
| 2734 | |
| 2735 | In particular, the convention has been established that the GET and |
| 2736 | HEAD methods should never have the significance of taking an action |
| 2737 | other than retrieval. These methods should be considered "safe." This |
| 2738 | allows user agents to represent other methods, such as POST, in a |
| 2739 | special way, so that the user is made aware of the fact that a |
| 2740 | possibly unsafe action is being requested. |
| 2741 | |
| 2742 | |
| 2743 | |
| 2744 | |
| 2745 | |
| 2746 | Berners-Lee, et al Informational [Page 49] |
| 2747 | \f |
| 2748 | RFC 1945 HTTP/1.0 May 1996 |
| 2749 | |
| 2750 | |
| 2751 | Naturally, it is not possible to ensure that the server does not |
| 2752 | generate side-effects as a result of performing a GET request; in |
| 2753 | fact, some dynamic resources consider that a feature. The important |
| 2754 | distinction here is that the user did not request the side-effects, |
| 2755 | so therefore cannot be held accountable for them. |
| 2756 | |
| 2757 | 12.3 Abuse of Server Log Information |
| 2758 | |
| 2759 | A server is in the position to save personal data about a user's |
| 2760 | requests which may identify their reading patterns or subjects of |
| 2761 | interest. This information is clearly confidential in nature and its |
| 2762 | handling may be constrained by law in certain countries. People using |
| 2763 | the HTTP protocol to provide data are responsible for ensuring that |
| 2764 | such material is not distributed without the permission of any |
| 2765 | individuals that are identifiable by the published results. |
| 2766 | |
| 2767 | 12.4 Transfer of Sensitive Information |
| 2768 | |
| 2769 | Like any generic data transfer protocol, HTTP cannot regulate the |
| 2770 | content of the data that is transferred, nor is there any a priori |
| 2771 | method of determining the sensitivity of any particular piece of |
| 2772 | information within the context of any given request. Therefore, |
| 2773 | applications should supply as much control over this information as |
| 2774 | possible to the provider of that information. Three header fields are |
| 2775 | worth special mention in this context: Server, Referer and From. |
| 2776 | |
| 2777 | Revealing the specific software version of the server may allow the |
| 2778 | server machine to become more vulnerable to attacks against software |
| 2779 | that is known to contain security holes. Implementors should make the |
| 2780 | Server header field a configurable option. |
| 2781 | |
| 2782 | The Referer field allows reading patterns to be studied and reverse |
| 2783 | links drawn. Although it can be very useful, its power can be abused |
| 2784 | if user details are not separated from the information contained in |
| 2785 | the Referer. Even when the personal information has been removed, the |
| 2786 | Referer field may indicate a private document's URI whose publication |
| 2787 | would be inappropriate. |
| 2788 | |
| 2789 | The information sent in the From field might conflict with the user's |
| 2790 | privacy interests or their site's security policy, and hence it |
| 2791 | should not be transmitted without the user being able to disable, |
| 2792 | enable, and modify the contents of the field. The user must be able |
| 2793 | to set the contents of this field within a user preference or |
| 2794 | application defaults configuration. |
| 2795 | |
| 2796 | We suggest, though do not require, that a convenient toggle interface |
| 2797 | be provided for the user to enable or disable the sending of From and |
| 2798 | Referer information. |
| 2799 | |
| 2800 | |
| 2801 | |
| 2802 | Berners-Lee, et al Informational [Page 50] |
| 2803 | \f |
| 2804 | RFC 1945 HTTP/1.0 May 1996 |
| 2805 | |
| 2806 | |
| 2807 | 12.5 Attacks Based On File and Path Names |
| 2808 | |
| 2809 | Implementations of HTTP origin servers should be careful to restrict |
| 2810 | the documents returned by HTTP requests to be only those that were |
| 2811 | intended by the server administrators. If an HTTP server translates |
| 2812 | HTTP URIs directly into file system calls, the server must take |
| 2813 | special care not to serve files that were not intended to be |
| 2814 | delivered to HTTP clients. For example, Unix, Microsoft Windows, and |
| 2815 | other operating systems use ".." as a path component to indicate a |
| 2816 | directory level above the current one. On such a system, an HTTP |
| 2817 | server must disallow any such construct in the Request-URI if it |
| 2818 | would otherwise allow access to a resource outside those intended to |
| 2819 | be accessible via the HTTP server. Similarly, files intended for |
| 2820 | reference only internally to the server (such as access control |
| 2821 | files, configuration files, and script code) must be protected from |
| 2822 | inappropriate retrieval, since they might contain sensitive |
| 2823 | information. Experience has shown that minor bugs in such HTTP server |
| 2824 | implementations have turned into security risks. |
| 2825 | |
| 2826 | 13. Acknowledgments |
| 2827 | |
| 2828 | This specification makes heavy use of the augmented BNF and generic |
| 2829 | constructs defined by David H. Crocker for RFC 822 [7]. Similarly, it |
| 2830 | reuses many of the definitions provided by Nathaniel Borenstein and |
| 2831 | Ned Freed for MIME [5]. We hope that their inclusion in this |
| 2832 | specification will help reduce past confusion over the relationship |
| 2833 | between HTTP/1.0 and Internet mail message formats. |
| 2834 | |
| 2835 | The HTTP protocol has evolved considerably over the past four years. |
| 2836 | It has benefited from a large and active developer community--the |
| 2837 | many people who have participated on the www-talk mailing list--and |
| 2838 | it is that community which has been most responsible for the success |
| 2839 | of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert |
| 2840 | Cailliau, Daniel W. Connolly, Bob Denny, Jean-Francois Groff, Phillip |
| 2841 | M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou |
| 2842 | Montulli, Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve |
| 2843 | special recognition for their efforts in defining aspects of the |
| 2844 | protocol for early versions of this specification. |
| 2845 | |
| 2846 | Paul Hoffman contributed sections regarding the informational status |
| 2847 | of this document and Appendices C and D. |
| 2848 | |
| 2849 | |
| 2850 | |
| 2851 | |
| 2852 | |
| 2853 | |
| 2854 | |
| 2855 | |
| 2856 | |
| 2857 | |
| 2858 | Berners-Lee, et al Informational [Page 51] |
| 2859 | \f |
| 2860 | RFC 1945 HTTP/1.0 May 1996 |
| 2861 | |
| 2862 | |
| 2863 | This document has benefited greatly from the comments of all those |
| 2864 | participating in the HTTP-WG. In addition to those already mentioned, |
| 2865 | the following individuals have contributed to this specification: |
| 2866 | |
| 2867 | Gary Adams Harald Tveit Alvestrand |
| 2868 | Keith Ball Brian Behlendorf |
| 2869 | Paul Burchard Maurizio Codogno |
| 2870 | Mike Cowlishaw Roman Czyborra |
| 2871 | Michael A. Dolan John Franks |
| 2872 | Jim Gettys Marc Hedlund |
| 2873 | Koen Holtman Alex Hopmann |
| 2874 | Bob Jernigan Shel Kaphan |
| 2875 | Martijn Koster Dave Kristol |
| 2876 | Daniel LaLiberte Paul Leach |
| 2877 | Albert Lunde John C. Mallery |
| 2878 | Larry Masinter Mitra |
| 2879 | Jeffrey Mogul Gavin Nicol |
| 2880 | Bill Perry Jeffrey Perry |
| 2881 | Owen Rees Luigi Rizzo |
| 2882 | David Robinson Marc Salomon |
| 2883 | Rich Salz Jim Seidman |
| 2884 | Chuck Shotton Eric W. Sink |
| 2885 | Simon E. Spero Robert S. Thau |
| 2886 | Francois Yergeau Mary Ellen Zurko |
| 2887 | Jean-Philippe Martin-Flatin |
| 2888 | |
| 2889 | 14. References |
| 2890 | |
| 2891 | [1] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., |
| 2892 | Torrey, D., and B. Alberti, "The Internet Gopher Protocol: A |
| 2893 | Distributed Document Search and Retrieval Protocol", RFC 1436, |
| 2894 | University of Minnesota, March 1993. |
| 2895 | |
| 2896 | [2] Berners-Lee, T., "Universal Resource Identifiers in WWW: A |
| 2897 | Unifying Syntax for the Expression of Names and Addresses of |
| 2898 | Objects on the Network as used in the World-Wide Web", |
| 2899 | RFC 1630, CERN, June 1994. |
| 2900 | |
| 2901 | [3] Berners-Lee, T., and D. Connolly, "Hypertext Markup Language - |
| 2902 | 2.0", RFC 1866, MIT/W3C, November 1995. |
| 2903 | |
| 2904 | [4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform |
| 2905 | Resource Locators (URL)", RFC 1738, CERN, Xerox PARC, |
| 2906 | University of Minnesota, December 1994. |
| 2907 | |
| 2908 | |
| 2909 | |
| 2910 | |
| 2911 | |
| 2912 | |
| 2913 | |
| 2914 | Berners-Lee, et al Informational [Page 52] |
| 2915 | \f |
| 2916 | RFC 1945 HTTP/1.0 May 1996 |
| 2917 | |
| 2918 | |
| 2919 | [5] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail |
| 2920 | Extensions) Part One: Mechanisms for Specifying and Describing |
| 2921 | the Format of Internet Message Bodies", RFC 1521, Bellcore, |
| 2922 | Innosoft, September 1993. |
| 2923 | |
| 2924 | [6] Braden, R., "Requirements for Internet hosts - Application and |
| 2925 | Support", STD 3, RFC 1123, IETF, October 1989. |
| 2926 | |
| 2927 | [7] Crocker, D., "Standard for the Format of ARPA Internet Text |
| 2928 | Messages", STD 11, RFC 822, UDEL, August 1982. |
| 2929 | |
| 2930 | [8] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang, |
| 2931 | J. Sui, and M. Grinbaum. "WAIS Interface Protocol Prototype |
| 2932 | Functional Specification." (v1.5), Thinking Machines |
| 2933 | Corporation, April 1990. |
| 2934 | |
| 2935 | [9] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, |
| 2936 | UC Irvine, June 1995. |
| 2937 | |
| 2938 | [10] Horton, M., and R. Adams, "Standard for interchange of USENET |
| 2939 | Messages", RFC 1036 (Obsoletes RFC 850), AT&T Bell |
| 2940 | Laboratories, Center for Seismic Studies, December 1987. |
| 2941 | |
| 2942 | [11] Kantor, B., and P. Lapsley, "Network News Transfer Protocol: |
| 2943 | A Proposed Standard for the Stream-Based Transmission of News", |
| 2944 | RFC 977, UC San Diego, UC Berkeley, February 1986. |
| 2945 | |
| 2946 | [12] Postel, J., "Simple Mail Transfer Protocol." STD 10, RFC 821, |
| 2947 | USC/ISI, August 1982. |
| 2948 | |
| 2949 | [13] Postel, J., "Media Type Registration Procedure." RFC 1590, |
| 2950 | USC/ISI, March 1994. |
| 2951 | |
| 2952 | [14] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", |
| 2953 | STD 9, RFC 959, USC/ISI, October 1985. |
| 2954 | |
| 2955 | [15] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC |
| 2956 | 1700, USC/ISI, October 1994. |
| 2957 | |
| 2958 | [16] Sollins, K., and L. Masinter, "Functional Requirements for |
| 2959 | Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation, |
| 2960 | December 1994. |
| 2961 | |
| 2962 | [17] US-ASCII. Coded Character Set - 7-Bit American Standard Code |
| 2963 | for Information Interchange. Standard ANSI X3.4-1986, ANSI, |
| 2964 | 1986. |
| 2965 | |
| 2966 | |
| 2967 | |
| 2968 | |
| 2969 | |
| 2970 | Berners-Lee, et al Informational [Page 53] |
| 2971 | \f |
| 2972 | RFC 1945 HTTP/1.0 May 1996 |
| 2973 | |
| 2974 | |
| 2975 | [18] ISO-8859. International Standard -- Information Processing -- |
| 2976 | 8-bit Single-Byte Coded Graphic Character Sets -- |
| 2977 | Part 1: Latin alphabet No. 1, ISO 8859-1:1987. |
| 2978 | Part 2: Latin alphabet No. 2, ISO 8859-2, 1987. |
| 2979 | Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. |
| 2980 | Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. |
| 2981 | Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. |
| 2982 | Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987. |
| 2983 | Part 7: Latin/Greek alphabet, ISO 8859-7, 1987. |
| 2984 | Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. |
| 2985 | Part 9: Latin alphabet No. 5, ISO 8859-9, 1990. |
| 2986 | |
| 2987 | 15. Authors' Addresses |
| 2988 | |
| 2989 | Tim Berners-Lee |
| 2990 | Director, W3 Consortium |
| 2991 | MIT Laboratory for Computer Science |
| 2992 | 545 Technology Square |
| 2993 | Cambridge, MA 02139, U.S.A. |
| 2994 | |
| 2995 | Fax: +1 (617) 258 8682 |
| 2996 | EMail: timbl@w3.org |
| 2997 | |
| 2998 | |
| 2999 | Roy T. Fielding |
| 3000 | Department of Information and Computer Science |
| 3001 | University of California |
| 3002 | Irvine, CA 92717-3425, U.S.A. |
| 3003 | |
| 3004 | Fax: +1 (714) 824-4056 |
| 3005 | EMail: fielding@ics.uci.edu |
| 3006 | |
| 3007 | |
| 3008 | Henrik Frystyk Nielsen |
| 3009 | W3 Consortium |
| 3010 | MIT Laboratory for Computer Science |
| 3011 | 545 Technology Square |
| 3012 | Cambridge, MA 02139, U.S.A. |
| 3013 | |
| 3014 | Fax: +1 (617) 258 8682 |
| 3015 | EMail: frystyk@w3.org |
| 3016 | |
| 3017 | |
| 3018 | |
| 3019 | |
| 3020 | |
| 3021 | |
| 3022 | |
| 3023 | |
| 3024 | |
| 3025 | |
| 3026 | Berners-Lee, et al Informational [Page 54] |
| 3027 | \f |
| 3028 | RFC 1945 HTTP/1.0 May 1996 |
| 3029 | |
| 3030 | |
| 3031 | Appendices |
| 3032 | |
| 3033 | These appendices are provided for informational reasons only -- they |
| 3034 | do not form a part of the HTTP/1.0 specification. |
| 3035 | |
| 3036 | A. Internet Media Type message/http |
| 3037 | |
| 3038 | In addition to defining the HTTP/1.0 protocol, this document serves |
| 3039 | as the specification for the Internet media type "message/http". The |
| 3040 | following is to be registered with IANA [13]. |
| 3041 | |
| 3042 | Media Type name: message |
| 3043 | |
| 3044 | Media subtype name: http |
| 3045 | |
| 3046 | Required parameters: none |
| 3047 | |
| 3048 | Optional parameters: version, msgtype |
| 3049 | |
| 3050 | version: The HTTP-Version number of the enclosed message |
| 3051 | (e.g., "1.0"). If not present, the version can be |
| 3052 | determined from the first line of the body. |
| 3053 | |
| 3054 | msgtype: The message type -- "request" or "response". If |
| 3055 | not present, the type can be determined from the |
| 3056 | first line of the body. |
| 3057 | |
| 3058 | Encoding considerations: only "7bit", "8bit", or "binary" are |
| 3059 | permitted |
| 3060 | |
| 3061 | Security considerations: none |
| 3062 | |
| 3063 | B. Tolerant Applications |
| 3064 | |
| 3065 | Although this document specifies the requirements for the generation |
| 3066 | of HTTP/1.0 messages, not all applications will be correct in their |
| 3067 | implementation. We therefore recommend that operational applications |
| 3068 | be tolerant of deviations whenever those deviations can be |
| 3069 | interpreted unambiguously. |
| 3070 | |
| 3071 | Clients should be tolerant in parsing the Status-Line and servers |
| 3072 | tolerant when parsing the Request-Line. In particular, they should |
| 3073 | accept any amount of SP or HT characters between fields, even though |
| 3074 | only a single SP is required. |
| 3075 | |
| 3076 | The line terminator for HTTP-header fields is the sequence CRLF. |
| 3077 | However, we recommend that applications, when parsing such headers, |
| 3078 | recognize a single LF as a line terminator and ignore the leading CR. |
| 3079 | |
| 3080 | |
| 3081 | |
| 3082 | Berners-Lee, et al Informational [Page 55] |
| 3083 | \f |
| 3084 | RFC 1945 HTTP/1.0 May 1996 |
| 3085 | |
| 3086 | |
| 3087 | C. Relationship to MIME |
| 3088 | |
| 3089 | HTTP/1.0 uses many of the constructs defined for Internet Mail (RFC |
| 3090 | 822 [7]) and the Multipurpose Internet Mail Extensions (MIME [5]) to |
| 3091 | allow entities to be transmitted in an open variety of |
| 3092 | representations and with extensible mechanisms. However, RFC 1521 |
| 3093 | discusses mail, and HTTP has a few features that are different than |
| 3094 | those described in RFC 1521. These differences were carefully chosen |
| 3095 | to optimize performance over binary connections, to allow greater |
| 3096 | freedom in the use of new media types, to make date comparisons |
| 3097 | easier, and to acknowledge the practice of some early HTTP servers |
| 3098 | and clients. |
| 3099 | |
| 3100 | At the time of this writing, it is expected that RFC 1521 will be |
| 3101 | revised. The revisions may include some of the practices found in |
| 3102 | HTTP/1.0 but not in RFC 1521. |
| 3103 | |
| 3104 | This appendix describes specific areas where HTTP differs from RFC |
| 3105 | 1521. Proxies and gateways to strict MIME environments should be |
| 3106 | aware of these differences and provide the appropriate conversions |
| 3107 | where necessary. Proxies and gateways from MIME environments to HTTP |
| 3108 | also need to be aware of the differences because some conversions may |
| 3109 | be required. |
| 3110 | |
| 3111 | C.1 Conversion to Canonical Form |
| 3112 | |
| 3113 | RFC 1521 requires that an Internet mail entity be converted to |
| 3114 | canonical form prior to being transferred, as described in Appendix G |
| 3115 | of RFC 1521 [5]. Section 3.6.1 of this document describes the forms |
| 3116 | allowed for subtypes of the "text" media type when transmitted over |
| 3117 | HTTP. |
| 3118 | |
| 3119 | RFC 1521 requires that content with a Content-Type of "text" |
| 3120 | represent line breaks as CRLF and forbids the use of CR or LF outside |
| 3121 | of line break sequences. HTTP allows CRLF, bare CR, and bare LF to |
| 3122 | indicate a line break within text content when a message is |
| 3123 | transmitted over HTTP. |
| 3124 | |
| 3125 | Where it is possible, a proxy or gateway from HTTP to a strict RFC |
| 3126 | 1521 environment should translate all line breaks within the text |
| 3127 | media types described in Section 3.6.1 of this document to the RFC |
| 3128 | 1521 canonical form of CRLF. Note, however, that this may be |
| 3129 | complicated by the presence of a Content-Encoding and by the fact |
| 3130 | that HTTP allows the use of some character sets which do not use |
| 3131 | octets 13 and 10 to represent CR and LF, as is the case for some |
| 3132 | multi-byte character sets. |
| 3133 | |
| 3134 | |
| 3135 | |
| 3136 | |
| 3137 | |
| 3138 | Berners-Lee, et al Informational [Page 56] |
| 3139 | \f |
| 3140 | RFC 1945 HTTP/1.0 May 1996 |
| 3141 | |
| 3142 | |
| 3143 | C.2 Conversion of Date Formats |
| 3144 | |
| 3145 | HTTP/1.0 uses a restricted set of date formats (Section 3.3) to |
| 3146 | simplify the process of date comparison. Proxies and gateways from |
| 3147 | other protocols should ensure that any Date header field present in a |
| 3148 | message conforms to one of the HTTP/1.0 formats and rewrite the date |
| 3149 | if necessary. |
| 3150 | |
| 3151 | C.3 Introduction of Content-Encoding |
| 3152 | |
| 3153 | RFC 1521 does not include any concept equivalent to HTTP/1.0's |
| 3154 | Content-Encoding header field. Since this acts as a modifier on the |
| 3155 | media type, proxies and gateways from HTTP to MIME-compliant |
| 3156 | protocols must either change the value of the Content-Type header |
| 3157 | field or decode the Entity-Body before forwarding the message. (Some |
| 3158 | experimental applications of Content-Type for Internet mail have used |
| 3159 | a media-type parameter of ";conversions=<content-coding>" to perform |
| 3160 | an equivalent function as Content-Encoding. However, this parameter |
| 3161 | is not part of RFC 1521.) |
| 3162 | |
| 3163 | C.4 No Content-Transfer-Encoding |
| 3164 | |
| 3165 | HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC |
| 3166 | 1521. Proxies and gateways from MIME-compliant protocols to HTTP must |
| 3167 | remove any non-identity CTE ("quoted-printable" or "base64") encoding |
| 3168 | prior to delivering the response message to an HTTP client. |
| 3169 | |
| 3170 | Proxies and gateways from HTTP to MIME-compliant protocols are |
| 3171 | responsible for ensuring that the message is in the correct format |
| 3172 | and encoding for safe transport on that protocol, where "safe |
| 3173 | transport" is defined by the limitations of the protocol being used. |
| 3174 | Such a proxy or gateway should label the data with an appropriate |
| 3175 | Content-Transfer-Encoding if doing so will improve the likelihood of |
| 3176 | safe transport over the destination protocol. |
| 3177 | |
| 3178 | C.5 HTTP Header Fields in Multipart Body-Parts |
| 3179 | |
| 3180 | In RFC 1521, most header fields in multipart body-parts are generally |
| 3181 | ignored unless the field name begins with "Content-". In HTTP/1.0, |
| 3182 | multipart body-parts may contain any HTTP header fields which are |
| 3183 | significant to the meaning of that part. |
| 3184 | |
| 3185 | D. Additional Features |
| 3186 | |
| 3187 | This appendix documents protocol elements used by some existing HTTP |
| 3188 | implementations, but not consistently and correctly across most |
| 3189 | HTTP/1.0 applications. Implementors should be aware of these |
| 3190 | features, but cannot rely upon their presence in, or interoperability |
| 3191 | |
| 3192 | |
| 3193 | |
| 3194 | Berners-Lee, et al Informational [Page 57] |
| 3195 | \f |
| 3196 | RFC 1945 HTTP/1.0 May 1996 |
| 3197 | |
| 3198 | |
| 3199 | with, other HTTP/1.0 applications. |
| 3200 | |
| 3201 | D.1 Additional Request Methods |
| 3202 | |
| 3203 | D.1.1 PUT |
| 3204 | |
| 3205 | The PUT method requests that the enclosed entity be stored under the |
| 3206 | supplied Request-URI. If the Request-URI refers to an already |
| 3207 | existing resource, the enclosed entity should be considered as a |
| 3208 | modified version of the one residing on the origin server. If the |
| 3209 | Request-URI does not point to an existing resource, and that URI is |
| 3210 | capable of being defined as a new resource by the requesting user |
| 3211 | agent, the origin server can create the resource with that URI. |
| 3212 | |
| 3213 | The fundamental difference between the POST and PUT requests is |
| 3214 | reflected in the different meaning of the Request-URI. The URI in a |
| 3215 | POST request identifies the resource that will handle the enclosed |
| 3216 | entity as data to be processed. That resource may be a data-accepting |
| 3217 | process, a gateway to some other protocol, or a separate entity that |
| 3218 | accepts annotations. In contrast, the URI in a PUT request identifies |
| 3219 | the entity enclosed with the request -- the user agent knows what URI |
| 3220 | is intended and the server should not apply the request to some other |
| 3221 | resource. |
| 3222 | |
| 3223 | D.1.2 DELETE |
| 3224 | |
| 3225 | The DELETE method requests that the origin server delete the resource |
| 3226 | identified by the Request-URI. |
| 3227 | |
| 3228 | D.1.3 LINK |
| 3229 | |
| 3230 | The LINK method establishes one or more Link relationships between |
| 3231 | the existing resource identified by the Request-URI and other |
| 3232 | existing resources. |
| 3233 | |
| 3234 | D.1.4 UNLINK |
| 3235 | |
| 3236 | The UNLINK method removes one or more Link relationships from the |
| 3237 | existing resource identified by the Request-URI. |
| 3238 | |
| 3239 | D.2 Additional Header Field Definitions |
| 3240 | |
| 3241 | D.2.1 Accept |
| 3242 | |
| 3243 | The Accept request-header field can be used to indicate a list of |
| 3244 | media ranges which are acceptable as a response to the request. The |
| 3245 | asterisk "*" character is used to group media types into ranges, with |
| 3246 | "*/*" indicating all media types and "type/*" indicating all subtypes |
| 3247 | |
| 3248 | |
| 3249 | |
| 3250 | Berners-Lee, et al Informational [Page 58] |
| 3251 | \f |
| 3252 | RFC 1945 HTTP/1.0 May 1996 |
| 3253 | |
| 3254 | |
| 3255 | of that type. The set of ranges given by the client should represent |
| 3256 | what types are acceptable given the context of the request. |
| 3257 | |
| 3258 | D.2.2 Accept-Charset |
| 3259 | |
| 3260 | The Accept-Charset request-header field can be used to indicate a |
| 3261 | list of preferred character sets other than the default US-ASCII and |
| 3262 | ISO-8859-1. This field allows clients capable of understanding more |
| 3263 | comprehensive or special-purpose character sets to signal that |
| 3264 | capability to a server which is capable of representing documents in |
| 3265 | those character sets. |
| 3266 | |
| 3267 | D.2.3 Accept-Encoding |
| 3268 | |
| 3269 | The Accept-Encoding request-header field is similar to Accept, but |
| 3270 | restricts the content-coding values which are acceptable in the |
| 3271 | response. |
| 3272 | |
| 3273 | D.2.4 Accept-Language |
| 3274 | |
| 3275 | The Accept-Language request-header field is similar to Accept, but |
| 3276 | restricts the set of natural languages that are preferred as a |
| 3277 | response to the request. |
| 3278 | |
| 3279 | D.2.5 Content-Language |
| 3280 | |
| 3281 | The Content-Language entity-header field describes the natural |
| 3282 | language(s) of the intended audience for the enclosed entity. Note |
| 3283 | that this may not be equivalent to all the languages used within the |
| 3284 | entity. |
| 3285 | |
| 3286 | D.2.6 Link |
| 3287 | |
| 3288 | The Link entity-header field provides a means for describing a |
| 3289 | relationship between the entity and some other resource. An entity |
| 3290 | may include multiple Link values. Links at the metainformation level |
| 3291 | typically indicate relationships like hierarchical structure and |
| 3292 | navigation paths. |
| 3293 | |
| 3294 | D.2.7 MIME-Version |
| 3295 | |
| 3296 | HTTP messages may include a single MIME-Version general-header field |
| 3297 | to indicate what version of the MIME protocol was used to construct |
| 3298 | the message. Use of the MIME-Version header field, as defined by RFC |
| 3299 | 1521 [5], should indicate that the message is MIME-conformant. |
| 3300 | Unfortunately, some older HTTP/1.0 servers send it indiscriminately, |
| 3301 | and thus this field should be ignored. |
| 3302 | |
| 3303 | |
| 3304 | |
| 3305 | |
| 3306 | Berners-Lee, et al Informational [Page 59] |
| 3307 | \f |
| 3308 | RFC 1945 HTTP/1.0 May 1996 |
| 3309 | |
| 3310 | |
| 3311 | D.2.8 Retry-After |
| 3312 | |
| 3313 | The Retry-After response-header field can be used with a 503 (service |
| 3314 | unavailable) response to indicate how long the service is expected to |
| 3315 | be unavailable to the requesting client. The value of this field can |
| 3316 | be either an HTTP-date or an integer number of seconds (in decimal) |
| 3317 | after the time of the response. |
| 3318 | |
| 3319 | D.2.9 Title |
| 3320 | |
| 3321 | The Title entity-header field indicates the title of the entity. |
| 3322 | |
| 3323 | D.2.10 URI |
| 3324 | |
| 3325 | The URI entity-header field may contain some or all of the Uniform |
| 3326 | Resource Identifiers (Section 3.2) by which the Request-URI resource |
| 3327 | can be identified. There is no guarantee that the resource can be |
| 3328 | accessed using the URI(s) specified. |
| 3329 | |
| 3330 | |
| 3331 | |
| 3332 | |
| 3333 | |
| 3334 | |
| 3335 | |
| 3336 | |
| 3337 | |
| 3338 | |
| 3339 | |
| 3340 | |
| 3341 | |
| 3342 | |
| 3343 | |
| 3344 | |
| 3345 | |
| 3346 | |
| 3347 | |
| 3348 | |
| 3349 | |
| 3350 | |
| 3351 | |
| 3352 | |
| 3353 | |
| 3354 | |
| 3355 | |
| 3356 | |
| 3357 | |
| 3358 | |
| 3359 | |
| 3360 | |
| 3361 | |
| 3362 | Berners-Lee, et al Informational [Page 60] |
| 3363 | \f |