idnits 2.17.1 draft-ietf-http-v10-spec-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2617 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 4, 1995) is 10462 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'CRLF' on line 416 ** Downref: Normative reference to an Informational RFC: RFC 1436 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 1630 (ref. '2') ** Downref: Normative reference to an Historic draft: draft-ietf-html-spec (ref. '3') ** Obsolete normative reference: RFC 1738 (ref. '4') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1521 (ref. '5') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 822 (ref. '7') (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 1808 (ref. '9') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 850 (ref. '10') (Obsoleted by RFC 1036) ** Obsolete normative reference: RFC 977 (ref. '11') (Obsoleted by RFC 3977) ** Obsolete normative reference: RFC 821 (ref. '12') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1590 (ref. '13') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1700 (ref. '15') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 1737 (ref. '16') -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' Summary: 20 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 HTTP Working Group T. Berners-Lee, MIT/LCS 2 INTERNET-DRAFT R. Fielding, UC Irvine 3 H. Frystyk, MIT/LCS 4 Expires March 4, 1996 September 4, 1995 6 Hypertext Transfer Protocol -- HTTP/1.0 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet-Drafts 18 as reference material or to cite them other than as "work in 19 progress". 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. Please send comments to 28 the HTTP working group at . Discussions 29 of the working group are archived at 30 . General discussions 31 about HTTP and the applications which use HTTP should take place on 32 the mailing list. 34 Abstract 36 The Hypertext Transfer Protocol (HTTP) is an application-level 37 protocol with the lightness and speed necessary for distributed, 38 collaborative, hypermedia information systems. It is a generic, 39 stateless, object-oriented protocol which can be used for many 40 tasks, such as name servers and distributed object management 41 systems, through extension of its request methods (commands). A 42 feature of HTTP is the typing and negotiation of data 43 representation, allowing systems to be built independently of the 44 data being transferred. 46 HTTP has been in use by the World-Wide Web global information 47 initiative since 1990. This specification reflects common usage of 48 the protocol referred to as "HTTP/1.0". 50 Table of Contents 52 1. Introduction 53 1.1 Purpose 54 1.2 Overall Operation 55 1.3 Terminology 57 2. Notational Conventions and Generic Grammar 58 2.1 Augmented BNF 59 2.2 Basic Rules 61 3. Protocol Parameters 62 3.1 HTTP Version 63 3.2 Uniform Resource Identifiers 64 3.2.1 General Syntax 65 3.2.2 http URL 66 3.3 Date/Time Formats 67 3.4 Character Sets 68 3.5 Content Codings 69 3.6 Media Types 70 3.6.1 Canonicalization and Text Defaults 71 3.6.2 Multipart Types 72 3.7 Product Tokens 74 4. HTTP Message 75 4.1 Message Types 76 4.2 Message Headers 77 4.3 General Message Header Fields 79 5. Request 80 5.1 Request-Line 81 5.2 Method 82 5.2.1 GET 83 5.2.2 HEAD 84 5.2.3 POST 85 5.3 Request-URI 86 5.4 Request Header Fields 88 6. Response 89 6.1 Status-Line 90 6.2 Status Codes and Reason Phrases 91 6.2.1 Informational 1xx 92 6.2.2 Successful 2xx 93 6.2.3 Redirection 3xx 94 6.2.4 Client Error 4xx 95 6.2.5 Server Errors 5xx 96 6.3 Response Header Fields 98 7. Entity 99 7.1 Entity Header Fields 100 7.2 Entity Body 101 7.2.1 Type 102 7.2.2 Length 104 8. Header Field Definitions 105 8.1 Allow 106 8.2 Authorization 107 8.3 Content-Encoding 108 8.4 Content-Length 109 8.5 Content-Type 110 8.6 Date 111 8.7 Expires 112 8.8 From 113 8.9 If-Modified-Since 114 8.10 Last-Modified 115 8.11 Location 116 8.12 MIME-Version 117 8.13 Pragma 118 8.14 Referer 119 8.15 Server 120 8.16 User-Agent 121 8.17 WWW-Authenticate 123 9. Access Authentication 124 9.1 Basic Authentication Scheme 126 10. Security Considerations 127 10.1 Authentication of Clients 128 10.2 Safe Methods 129 10.3 Abuse of Server Log Information 130 10.4 Transfer of Sensitive Information 132 11. Acknowledgments 134 12. References 136 13. Authors' Addresses 138 Appendix A. Internet Media Type message/http 140 Appendix B. Tolerant Applications 142 Appendix C. Relationship to MIME 143 C.1 Conversion to Canonical Form 144 C.1.1 Representation of Line Breaks 145 C.1.2 Default Character Set 146 C.2 Conversion of Date Formats 147 C.3 Introduction of Content-Encoding 148 C.4 No Content-Transfer-Encoding 150 1. Introduction 152 1.1 Purpose 154 The Hypertext Transfer Protocol (HTTP) is an application-level 155 protocol with the lightness and speed necessary for distributed, 156 collaborative, hypermedia information systems. HTTP has been in use 157 by the World-Wide Web global information initiative since 1990. 158 This specification reflects common usage of the protocol referred 159 to as "HTTP/1.0". This specification is not intended to become an 160 Internet standard; rather, it defines those features of the HTTP 161 protocol that can reasonably be expected of any implementation 162 which claims to be using HTTP/1.0. 164 Practical information systems require more functionality than 165 simple retrieval, including search, front-end update, and 166 annotation. HTTP/1.0 allows an open-ended set of methods to be used 167 to indicate the purpose of a request. It builds on the discipline 168 of reference provided by the Uniform Resource Identifier (URI) [2], 169 as a location (URL) [4] or name (URN) [16], for indicating the 170 resource on which a method is to be applied. Messages are passed in 171 a format similar to that used by Internet Mail [7] and the 172 Multipurpose Internet Mail Extensions (MIME) [5]. 174 HTTP/1.0 is also used for communication between user agents and 175 various gateways, allowing hypermedia access to existing Internet 176 protocols like SMTP [12], NNTP [11], FTP [14], Gopher [1], and 177 WAIS [8]. HTTP/1.0 is designed to allow such gateways, via proxy 178 servers, without any loss of the data conveyed by those earlier 179 protocols. 181 1.2 Overall Operation 183 The HTTP protocol is based on a request/response paradigm. A 184 requesting program (termed a client) establishes a connection with 185 a receiving program (termed a server) and sends a request to the 186 server in the form of a request method, URI, and protocol version, 187 followed by a MIME-like message containing request modifiers, 188 client information, and possible body content. The server responds 189 with a status line, including its protocol version and a success or 190 error code, followed by a MIME-like message containing server 191 information, entity metainformation, and possible body content. It 192 should be noted that a given program may be capable of being both a 193 client and a server; our use of those terms refers only to the role 194 being performed by the program during a particular connection, 195 rather than to the program's purpose in general. 197 On the Internet, the communication generally takes place over a 198 TCP/IP connection. The default port is TCP 80 [15], but other ports 199 can be used. This does not preclude the HTTP/1.0 protocol from 200 being implemented on top of any other protocol on the Internet, or 201 on other networks. HTTP only presumes a reliable transport; any 202 protocol that provides such guarantees can be used, and the mapping 203 of the HTTP/1.0 request and response structures onto the transport 204 data units of the protocol in question is outside the scope of this 205 specification. 207 Current practice requires that the connection be established by the 208 client prior to each request and closed by the server after sending 209 the response. Both clients and servers must be capable of handling 210 cases where either party closes the connection prematurely, due to 211 user action, automated time-out, or program failure. In any case, 212 the closing of the connection by either or both parties always 213 terminates the current request, regardless of its status. 215 1.3 Terminology 217 This specification uses a number of terms to refer to the roles 218 played by participants in, and objects of, the HTTP communication. 220 connection 222 A virtual circuit established between two parties for the 223 purpose of communication. 225 message 227 A structured sequence of octets transmitted via the connection 228 as the basic component of communication. 230 request 232 An HTTP request message (as defined in Section 5). 234 response 236 An HTTP response message (as defined in Section 6). 238 resource 240 A network data object or service which can be identified by a 241 URI (Section 3.2). 243 entity 245 A particular representation or rendition of a resource that may 246 be enclosed within a request or response message. An entity 247 consists of metainformation in the form of entity headers and 248 content in the form of an entity body. 250 client 252 A program that establishes connections for the purpose of 253 sending requests. 255 user agent 257 The client program which is closest to the user and which 258 initiates requests at their behest. These are often browsers, 259 editors, spiders (web-traversing robots), or other end user 260 tools. 262 server 264 A program that accepts connections in order to service requests 265 by sending back responses. 267 origin server 269 The server on which a given resource resides or is to be created. 271 proxy 273 An intermediary program which acts as both a server and a client 274 for the purpose of forwarding requests. Proxies are often used 275 to act as a portal through a network firewall. A proxy server 276 accepts requests from other clients and services them either 277 internally or by passing them, with possible translation, on to 278 other servers. A caching proxy is a proxy server with a local 279 cache of server responses -- some requested resources can be 280 serviced from the cache rather than from the origin server. Some 281 proxy servers also act as origin servers. 283 gateway 285 A proxy which services HTTP requests by translation into 286 protocols other than HTTP. The reply sent from the remote server 287 to the gateway is likewise translated into HTTP before being 288 forwarded to the user agent. 290 2. Notational Conventions and Generic Grammar 292 2.1 Augmented BNF 294 All of the mechanisms specified in this document are described in 295 both prose and an augmented Backus-Naur Form (BNF) similar to that 296 used by RFC 822 [7]. Implementors will need to be familiar with the 297 notation in order to understand this specification. The augmented 298 BNF includes the following constructs: 300 name = definition 302 The name of a rule is simply the name itself (without any 303 enclosing "<" and ">") and is separated from its definition by 304 the equal character "=". Whitespace is only significant in that 305 indentation of continuation lines is used to indicate a rule 306 definition that spans more than one line. Certain basic rules 307 are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. 308 Angle brackets are used within definitions whenever their 309 presence will facilitate discerning the use of rule names. 311 "literal" 313 Quotation marks surround literal text. Unless stated otherwise, 314 the text is case-insensitive. 316 rule1 | rule2 318 Elements separated by a bar ("I") are alternatives, 319 e.g., "yes | no" will accept yes or no. 321 (rule1 rule2) 323 Elements enclosed in parentheses are treated as a single 324 element. Thus, "(elem (foo | bar) elem)" allows the token 325 sequences "elem foo elem" and "elem bar elem". 327 *rule 329 The character "*" preceding an element indicates repetition. The 330 full form is "*element" indicating at least and at 331 most occurrences of element. Default values are 0 and 332 infinity so that "*(element)" allows any number, including zero; 333 "1*element" requires at least one; and "1*2element" allows one 334 or two. 336 [rule] 338 Square brackets enclose optional elements; "[foo bar]" is 339 equivalent to "*1(foo bar)". 341 N rule 343 Specific repetition: "(element)" is equivalent to 344 "*(element)"; that is, exactly occurrences of 345 (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a 346 string of three alphabetic characters. 348 #rule 350 A construct "#" is defined, similar to "*", for defining lists 351 of elements. The full form is "#element" indicating at 352 least and at most elements, each separated by one or 353 more commas (",") and optional linear whitespace (LWS). This 354 makes the usual form of lists very easy; a rule such as 355 "( *LWS element *( *LWS "," *LWS element ))" can be shown as 356 "1#element". Wherever this construct is used, null elements are 357 allowed, but do not contribute to the count of elements present. 358 That is, "(element), , (element)" is permitted, but counts as 359 only two elements. Therefore, where at least one element is 360 required, at least one non-null element must be present. Default 361 values are 0 and infinity so that "#(element)" allows any 362 number, including zero; "1#element" requires at least one; and 363 "1#2element" allows one or two. 365 ; comment 367 A semi-colon, set off some distance to the right of rule text, 368 starts a comment that continues to the end of line. This is a 369 simple way of including useful notes in parallel with the 370 specifications. 372 implied *LWS 374 The grammar described by this specification is word-based. 375 Except where noted otherwise, zero or more linear whitespace 376 (LWS) can be included between any two adjacent words (token or 377 quoted-string), and between adjacent tokens and delimiters 378 (tspecials), without changing the interpretation of a field. 379 However, applications should attempt to follow "common form" 380 when generating HTTP constructs, since there exist some 381 implementations that fail to accept anything beyond the common 382 forms. 384 2.2 Basic Rules 386 The following rules are used throughout this specification to 387 describe basic parsing constructs. The US-ASCII coded character set 388 is defined by [17]. 390 OCTET = 391 CHAR = 392 UPALPHA = 393 LOALPHA = 394 ALPHA = UPALPHA | LOALPHA 395 DIGIT = 396 CTL = 398 CR = 399 LF = 400 SP = 401 HT = 402 <"> = 404 HTTP/1.0 defines the octet sequence CR LF as the end-of-line marker 405 for all protocol elements except the Entity-Body (see Appendix B 406 for tolerant applications). The end-of-line marker within an 407 Entity-Body is defined by its associated media type, as described 408 in Section 3.6. 410 CRLF = CR LF 412 HTTP/1.0 headers may be folded onto multiple lines if the 413 continuation lines begin with linear whitespace characters. All 414 linear whitespace, including folding, has the same semantics as SP. 416 LWS = [CRLF] 1*( SP | HT ) 418 However, folding of header lines is not expected by some 419 applications, and should not be generated by HTTP/1.0 applications. 421 Many HTTP/1.0 header field values consist of words separated by LWS 422 or special characters. These special characters must be in a quoted 423 string to be used within a parameter value. 425 word = token | quoted-string 427 token = 1* 429 tspecials = "(" | ")" | "<" | ">" | "@" 430 | "," | ";" | ":" | "\" | <"> 431 | "/" | "[" | "]" | "?" | "=" 432 | "{" | "}" | SP | HT 434 Comments may be included in some HTTP header fields by surrounding 435 the comment text with parentheses. Comments are only allowed in 436 fields containing "comment" as part of their field value definition. 438 comment = "(" *( ctext | comment ) ")" 439 ctext = 441 A string of text is parsed as a single word if it is quoted using 442 double-quote marks. 444 quoted-string = ( <"> *(qdtext) <"> ) 446 qdtext = and CTLs, 447 but including LWS> 449 Single-character quoting using the backslash ("\") character is not 450 permitted in HTTP/1.0. 452 The text rule is only used for descriptive field contents and 453 values that are not intended to be interpreted by the message 454 parser. Words of *text may contain octets from character sets other 455 than US-ASCII. 457 text = 460 Recipients of header field text containing octets outside the 461 US-ASCII character set may assume that they represent ISO-8859-1 462 characters. 464 3. Protocol Parameters 466 3.1 HTTP Version 468 HTTP uses a "." numbering scheme to indicate versions 469 of the protocol. The protocol versioning policy is intended to 470 allow the sender to indicate the format of a message and its 471 capacity for understanding further HTTP communication, rather than 472 the features obtained via that communication. No change is made to 473 the version number for the addition of message components which do 474 not affect communication behavior or which only add to extensible 475 field values. The number is incremented when the changes 476 made to the protocol add features which do not change the general 477 message parsing algorithm, but which may add to the message 478 semantics and imply additional capabilities of the sender. The 479 number is incremented when the format of a message within 480 the protocol is changed. 482 The version of an HTTP message is indicated by an HTTP-Version 483 field in the first line of the message. If the protocol version is 484 not specified, the recipient must assume that the message is in the 485 simple HTTP/0.9 format. 487 HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT 489 Note that the major and minor numbers should be treated as separate 490 integers and that each may be incremented higher than a single 491 digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in 492 turn is lower than HTTP/12.3. Leading zeros should be ignored by 493 recipients and never generated by senders. 495 This document defines both the 0.9 and 1.0 versions of the HTTP 496 protocol. Applications sending Full-Request or Full-Response 497 messages, as defined by this specification, must include an 498 HTTP-Version of "HTTP/1.0". 500 HTTP/1.0 servers must: 502 o recognize the format of the Request-Line for HTTP/0.9 and 503 HTTP/1.0 requests; 505 o understand any valid request in the format of HTTP/0.9 or 506 HTTP/1.0; 508 o respond appropriately with a message in the same protocol 509 version used by the client. 511 HTTP/1.0 clients must: 513 o recognize the format of the Status-Line for HTTP/1.0 responses; 515 o understand any valid response in the format of HTTP/0.9 or 516 HTTP/1.0. 518 Proxies must be careful in forwarding requests that are received in 519 a format different than that of the proxy's native version. Since 520 the protocol version indicates the protocol capability of the 521 sender, a proxy must never send a message with a version indicator 522 which is greater than its native version; if a higher version 523 request is received, the proxy must either downgrade the request 524 version or respond with an error. Requests with a version lower 525 than that of the proxy's native format may be upgraded by the proxy 526 before being forwarded; the proxy's response to that request must 527 follow the normal server requirements. 529 3.2 Uniform Resource Identifiers 531 URIs have been known by many names: WWW addresses, Universal 532 Document Identifiers, Universal Resource Identifiers [2], and 533 finally the combination of Uniform Resource Locators (URL) [4] and 534 Names (URN) [16]. As far as HTTP is concerned, Uniform Resource 535 Identifiers are simply formatted strings which identify--via name, 536 location, or any other characteristic--a network resource. 538 3.2.1 General Syntax 540 URIs in HTTP/1.0 can be represented in absolute form or relative to 541 some known base URI [9], depending upon the context of their use. 542 The two forms are differentiated by the fact that absolute URIs 543 always begin with a scheme name followed by a colon. 545 URI = ( absoluteURI | relativeURI ) [ "#" fragment ] 547 absoluteURI = scheme ":" *( uchar | reserved ) 549 relativeURI = net_path | abs_path | rel_path 551 net_path = "//" net_loc [ abs_path ] 552 abs_path = "/" rel_path 553 rel_path = [ path ] [ ";" params ] [ "?" query ] 555 path = fsegment *( "/" segment ) 556 fsegment = 1*pchar 557 segment = *pchar 559 params = param *( ";" param ) 560 param = *( pchar | "/" ) 562 scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." ) 563 net_loc = *( pchar | ";" | "?" ) 564 query = *( uchar | reserved ) 565 fragment = *( uchar | reserved ) 567 pchar = uchar | ":" | "@" | "&" | "=" 568 uchar = unreserved | escape 569 unreserved = ALPHA | DIGIT | safe | extra | national 571 escape = "%" hex hex 572 hex = "A" | "B" | "C" | "D" | "E" | "F" 573 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT 575 reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" 576 safe = "$" | "-" | "_" | "." | "+" 577 extra = "!" | "*" | "'" | "(" | ")" | "," 578 national = 581 For definitive information on URL syntax and semantics, see 582 RFC 1738 [4] and RFC 1808 [9]. The BNF above includes national 583 characters not allowed in valid URLs as specified by RFC 1738, 584 since HTTP servers are not restricted in the set of unreserved 585 characters allowed to represent the rel_path part of addresses, and 586 HTTP proxies may receive requests for URIs not defined by RFC 1738. 588 3.2.2 http URL 590 The "http" scheme is used to locate network resources via the HTTP 591 protocol. This section defines the scheme-specific syntax and 592 semantics for http URLs. 594 http_URL = "http:" "//" host [ ":" port ] abs_path 596 host = 597 port = *DIGIT 599 If the port is empty or not given, port 80 is assumed. The 600 semantics are that the identified resource is located at the server 601 listening for TCP connections on that port of that host, and the 602 Request-URI for the resource is abs_path. If the abs_path is not 603 present in the URL, it must be given as "/" when used as a 604 Request-URI. 606 The canonical form for "http" URLs is obtained by converting any 607 UPALPHA characters in host to their LOALPHA equivalent (hostnames 608 are case-insensitive), eliding the [ ":" port ] if the port is 80, 609 and replacing an empty abs_path with "/". 611 3.3 Date/Time Formats 613 HTTP/1.0 applications have historically allowed three different 614 formats for the representation of date/time stamps: 616 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 617 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 618 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 620 The first format is preferred as an Internet standard and 621 represents a fixed-length subset of that defined by RFC 1123 [6] 622 (an update to RFC 822 [7]). The second format is in common use, but 623 is based on the obsolete RFC 850 [10] date format and lacks a 624 four-digit year. HTTP/1.0 clients and servers that parse the date 625 value should accept all three formats, though they must never 626 generate the third (asctime) format. 628 Note: Recipients of date values are encouraged to be robust 629 in accepting date values that may have been generated by 630 non-HTTP applications, as is sometimes the case when 631 retrieving or posting messages via gateways to SMTP or NNTP. 633 All HTTP/1.0 date/time stamps must be represented in Universal Time 634 (UT), also known as Greenwich Mean Time (GMT), without exception. 635 This is indicated in the first two formats by the inclusion of 636 "GMT" as the three-letter abbreviation for time zone, and should be 637 assumed when reading the asctime format. 639 HTTP-date = rfc1123-date | rfc850-date | asctime-date 641 rfc1123-date = wkday "," SP date1 SP time SP "GMT" 642 rfc850-date = weekday "," SP date2 SP time SP "GMT" 643 asctime-date = wkday SP date3 SP time SP 4DIGIT 645 date1 = 2DIGIT SP month SP 4DIGIT 646 ; day month year (e.g., 02 Jun 1982) 647 date2 = 2DIGIT "-" month "-" 2DIGIT 648 ; day-month-year (e.g., 02-Jun-82) 649 date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) 650 ; month day (e.g., Jun 2) 652 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 653 ; 00:00:00 - 23:59:59 655 wkday = "Mon" | "Tue" | "Wed" 656 | "Thu" | "Fri" | "Sat" | "Sun" 658 weekday = "Monday" | "Tuesday" | "Wednesday" 659 | "Thursday" | "Friday" | "Saturday" | "Sunday" 661 month = "Jan" | "Feb" | "Mar" | "Apr" 662 | "May" | "Jun" | "Jul" | "Aug" 663 | "Sep" | "Oct" | "Nov" | "Dec" 665 Note: HTTP/1.0 requirements for the date/time stamp format 666 apply only to their usage within the protocol stream. 667 Clients and servers are not required to use these formats 668 for user presentation, request logging, etc. 670 3.4 Character Sets 672 HTTP uses the same definition of the term "character set" as that 673 described for MIME: 675 The term "character set" is used in this document to 676 refer to a method used with one or more tables to convert 677 a sequence of octets into a sequence of characters. Note 678 that unconditional conversion in the other direction is 679 not required, in that not all characters may be available 680 in a given character set and a character set may provide 681 more than one sequence of octets to represent a 682 particular character. This definition is intended to 683 allow various kinds of character encodings, from simple 684 single-table mappings such as US-ASCII to complex table 685 switching methods such as those that use ISO 2022's 686 techniques. However, the definition associated with a 687 MIME character set name must fully specify the mapping to 688 be performed from octets to characters. In particular, 689 use of external profiling information to determine the 690 exact mapping is not permitted. 692 HTTP character sets are identified by case-insensitive tokens. The 693 complete set of tokens are defined by the IANA Character Set 694 registry [15]. However, because that registry does not define a 695 single, consistent token for each character set, we define here the 696 preferred names for those character sets most likely to be used 697 with HTTP entities. These character sets include those registered 698 by RFC 1521 [5] -- the US-ASCII [17] and ISO-8859 [18] character 699 sets -- and other names specifically recommended for use within MIME 700 charset parameters. 702 charset = "US-ASCII" 703 | "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3" 704 | "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6" 705 | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9" 706 | "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR" 707 | "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8" 708 | token 710 Although HTTP allows an arbitrary token to be used as a charset 711 value, any token that has a predefined value within the IANA 712 Character Set registry [15] must represent the character set 713 defined by that registry. Applications are encouraged, but not 714 required, to limit their use of character sets to those defined by 715 the IANA registry. 717 Note: This use of the term "character set" is more commonly 718 referred to as a "character encoding." However, since HTTP 719 and MIME share the same registry, it is important that the 720 terminology also be shared. 722 3.5 Content Codings 724 Content coding values are used to indicate an encoding 725 transformation that has been or can be applied to a resource. 726 Content codings are primarily used to allow a document to be 727 compressed or encrypted without losing the identity of its 728 underlying media type. Typically, the resource is stored in this 729 encoding and only decoded before rendering or analogous usage. 731 content-coding = "x-gzip" | "x-compress" | token 733 Note: For future compatibility, HTTP/1.0 applications should 734 consider "gzip" and "compress" to be equivalent to "x-gzip" 735 and "x-compress", respectively. 737 All content-coding values are case-insensitive. HTTP/1.0 uses 738 content-coding values in the Content-Encoding (Section 8.3) header 739 field. Although the value describes the content-coding, what is 740 more important is that it indicates what decoding mechanism will be 741 required to remove the encoding. Note that a single program may be 742 capable of decoding multiple content-coding formats. Two values are 743 defined by this specification: 745 x-gzip 746 An encoding format produced by the file compression program 747 "gzip" (GNU zip) developed by Jean-loup Gailly. This format is 748 typically a Lempel-Ziv coding (LZ77) with a 32 bit CRC. Gzip is 749 available from the GNU project at 750 . 752 x-compress 753 The encoding format produced by the file compression program 754 "compress". This format is an adaptive Lempel-Ziv-Welch coding 755 (LZW). 757 Note: Use of program names for the identification of 758 encoding formats is not desirable and should be discouraged 759 for future encodings. Their use here is representative of 760 historical practice, not good design. 762 3.6 Media Types 764 HTTP uses Internet Media Types [13] (formerly referred to as MIME 765 Content-Types [5]) in order to provide open and extensible data 766 typing and type negotiation. For mail applications, where there is 767 no type negotiation between sender and receiver, it is reasonable 768 to put strict limits on the set of allowed media types. With HTTP, 769 where the sender and recipient can communicate directly, 770 applications are allowed more freedom in the use of non-registered 771 types. The following grammar for media types is a superset of that 772 for MIME because it does not restrict itself to the official IANA 773 and x-token types. 775 media-type = type "/" subtype *( ";" parameter ) 776 type = token 777 subtype = token 779 Parameters may follow the type/subtype in the form of 780 attribute/value pairs. 782 parameter = attribute "=" value 783 attribute = token 784 value = token | quoted-string 786 The type, subtype, and parameter attribute names are 787 case-insensitive. Parameter values may or may not be 788 case-sensitive, depending on the semantics of the parameter name. 789 LWS must not be generated between the type and subtype, nor between 790 an attribute and its value. 792 Many current applications do not recognize media type parameters. 793 Since parameters are a fundamental aspect of media types, this must 794 be considered an error in those applications. Nevertheless, 795 HTTP/1.0 applications should only use media type parameters when 796 they are necessary to define the content of a message. 798 If a given media-type value has been registered by the IANA, any 799 use of that value must be indicative of the registered data format. 800 Although HTTP allows the use of non-registered media types, such 801 usage must not conflict with the IANA registry. Data providers are 802 strongly encouraged to register their media types with IANA via the 803 procedures outlined in RFC 1590 [13]. 805 All media-type's registered by IANA must be preferred over 806 extension tokens. However, HTTP does not limit conforming 807 applications to the use of officially registered media types, nor 808 does it encourage the use of an "x-" prefix for unofficial types 809 outside of explicitly short experimental use between consenting 810 applications. 812 3.6.1 Canonicalization and Text Defaults 814 Media types are registered in a canonical form. In general, entity 815 bodies transferred via HTTP must be represented in the appropriate 816 canonical form prior to transmission. If the body has been encoded 817 via a Content-Encoding, the data must be in canonical form prior to 818 that encoding. However, HTTP modifies the canonical form 819 requirements for media of primary type "text" and for "application" 820 types consisting of text-like records. 822 HTTP redefines the canonical form of text media to allow multiple 823 octet sequences to indicate a text line break. In addition to the 824 preferred form of CRLF, HTTP applications must accept a bare CR or 825 LF alone as representing a single line break in text media. 826 Furthermore, if the text media is represented in a character set 827 which does not use octets 13 and 10 for CR and LF respectively, as 828 is the case for some multi-byte character sets, HTTP allows the use 829 of whatever octet sequence(s) is defined by that character set to 830 represent the equivalent of CRLF, bare CR, and bare LF. It is 831 assumed that any recipient capable of using such a character set 832 will know the appropriate octet sequence for representing line 833 breaks within that character set. 835 Note: This interpretation of line breaks applies only to the 836 contents of an Entity-Body and only after any 837 Content-Encoding has been removed. All other HTTP constructs 838 use CRLF exclusively to indicate a line break. Content 839 codings define their own line break requirements. 841 A recipient of an HTTP text entity should translate the received 842 entity line breaks to the local line break conventions before 843 saving the entity external to the application and its cache; 844 whether this translation takes place immediately upon receipt of 845 the entity, or only when prompted by the user, is entirely up to 846 the individual application. 848 HTTP also redefines the default character set for text media in an 849 entity body. If a textual media type defines a charset parameter 850 with a registered default value of "US-ASCII", HTTP changes the 851 default to be "ISO-8859-1". Since the ISO-8859-1 [18] character set 852 is a superset of US-ASCII [17], this has no effect upon the 853 interpretation of entity bodies which only contain octets within 854 the US-ASCII set (0 - 127). The presence of a charset parameter 855 value in a Content-Type header field overrides the default. 857 It is recommended that the character set of an entity body be 858 labelled as the lowest common denominator of the character codes 859 used within a document, with the exception that no label is 860 preferred over the labels US-ASCII or ISO-8859-1. 862 3.6.2 Multipart Types 864 MIME provides for a number of "multipart" types -- encapsulations of 865 several entities within a single message's Entity-Body. The 866 multipart types registered by IANA [15] do not have any special 867 meaning for HTTP/1.0, though user agents may need to understand 868 each type in order to correctly interpret the purpose of each 869 body-part. Ideally, an HTTP user agent should follow the same or 870 similar behavior as a MIME user agent does upon receipt of a 871 multipart type. 873 As in MIME [5], all multipart types share a common syntax and must 874 include a boundary parameter as part of the media type value. The 875 message body is itself a protocol element and must therefore use 876 only CRLF to represent line breaks between body-parts. Unlike in 877 MIME, multipart body-parts may contain HTTP header fields which are 878 significant to the meaning of that part. 880 3.7 Product Tokens 882 Product tokens are used to allow communicating applications to 883 identify themselves via a simple product token, with an optional 884 slash and version designator. Most fields using product tokens also 885 allow subproducts which form a significant part of the application 886 to be listed, separated by whitespace. By convention, the products 887 are listed in order of their significance for identifying the 888 application. 890 product = token ["/" product-version] 891 product-version = token 893 Examples: 895 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 897 Server: Apache/0.8.4 899 Product tokens should be short and to the point -- use of them for 900 advertizing or other non-essential information is explicitly 901 forbidden. Although any token character may appear in a 902 product-version, this token should only be used for a version 903 identifier (i.e., successive versions of the same product should 904 only differ in the product-version portion of the product value). 906 4. HTTP Message 908 4.1 Message Types 910 HTTP messages consist of requests from client to server and 911 responses from server to client. 913 HTTP-message = Simple-Request ; HTTP/0.9 messages 914 | Simple-Response 915 | Full-Request ; HTTP/1.0 messages 916 | Full-Response 918 Full-Request and Full-Response use the generic message format of 919 RFC 822 [7] for transferring entities. Both messages may include 920 optional header fields (a.k.a. "headers") and an entity body. The 921 entity body is separated from the headers by a null line (i.e., a 922 line with nothing preceding the CRLF). 924 Full-Request = Request-Line ; Section 5.1 925 *( General-Header ; Section 4.3 926 | Request-Header ; Section 5.4 927 | Entity-Header ) ; Section 7.1 928 CRLF 929 [ Entity-Body ] ; Section 7.2 931 Full-Response = Status-Line ; Section 6.1 932 *( General-Header ; Section 4.3 933 | Response-Header ; Section 6.3 934 | Entity-Header ) ; Section 7.1 935 CRLF 936 [ Entity-Body ] ; Section 7.2 938 Simple-Request and Simple-Response do not allow the use of any 939 header information and are limited to a single request method (GET). 941 Simple-Request = "GET" SP Request-URI CRLF 943 Simple-Response = [ Entity-Body ] 945 Use of the Simple-Request format is discouraged because it prevents 946 the server from identifying the media type of the returned entity. 948 4.2 Message Headers 950 HTTP header fields, which include General-Header (Section 4.3), 951 Request-Header (Section 5.4), Response-Header (Section 6.3), and 952 Entity-Header (Section 7.1) fields, follow the same generic format 953 as that given in Section 3.1 of RFC 822 [7]. Each header field 954 consists of a name followed immediately by a colon (":"), a single 955 space (SP) character, and the field value. Field names are 956 case-insensitive. Header fields can be extended over multiple lines 957 by preceding each extra line with at least one LWS, though this is 958 not recommended. 960 HTTP-header = field-name ":" [ field-value ] CRLF 962 field-name = 1* 963 field-value = *( field-content | LWS ) 965 field-content = 969 The order in which header fields are received is not significant. 970 However, it is "good practice" to send General-Header fields first, 971 followed by Request-Header or Response-Header fields prior to the 972 Entity-Header fields. 974 Multiple HTTP-header fields with the same field-name may be present 975 in a message if and only if the entire field-value for that header 976 field is defined as a comma-separated list [i.e., #(values)]. It 977 must be possible to combine the multiple header fields into one 978 "field-name: field-value" pair, without changing the semantics of 979 the message, by appending each subsequent field-value to the first, 980 each separated by a comma. 982 4.3 General Message Header Fields 984 There are a few header fields which have general applicability for 985 both request and response messages, but which do not apply to the 986 communicating parties or the content being transferred. These 987 headers apply only to the message being transmitted. 989 General-Header = Date ; Section 8.6 990 | MIME-Version ; Section 8.12 991 | Pragma ; Section 8.13 993 General header field names can be extended only via a change in the 994 protocol version. Unknown header fields are treated as 995 Entity-Header fields. 997 5. Request 999 A request message from a client to a server includes, within the 1000 first line of that message, the method to be applied to the 1001 resource requested, the identifier of the resource, and the 1002 protocol version in use. For backwards compatibility with the more 1003 limited HTTP/0.9 protocol, there are two valid formats for an HTTP 1004 request: 1006 Request = Simple-Request | Full-Request 1008 Simple-Request = "GET" SP Request-URI CRLF 1010 Full-Request = Request-Line ; Section 5.1 1011 *( General-Header ; Section 4.3 1012 | Request-Header ; Section 5.4 1013 | Entity-Header ) ; Section 7.1 1014 CRLF 1015 [ Entity-Body ] ; Section 7.2 1017 If an HTTP/1.0 server receives a Simple-Request, it must respond 1018 with an HTTP/0.9 Simple-Response. An HTTP/1.0 client capable of 1019 receiving a Full-Response should never generate a Simple-Request. 1021 5.1 Request-Line 1023 The Request-Line begins with a method token, followed by the 1024 Request-URI and the protocol version, and ending with CRLF. The 1025 elements are separated by SP characters. No CR or LF are allowed 1026 except in the final CRLF sequence. 1028 Request-Line = Method SP Request-URI SP HTTP-Version CRLF 1030 Note that the difference between a Simple-Request and the 1031 Request-Line of a Full-Request is the presence of the HTTP-Version 1032 field and the availability of methods other than GET. 1034 5.2 Method 1036 The Method token indicates the method to be performed on the 1037 resource identified by the Request-URI. The method is 1038 case-sensitive. 1040 Method = "GET" | "HEAD" | "POST" 1041 | extension-method 1043 extension-method = token 1045 The list of methods acceptable by a specific resource can change 1046 dynamically; the client is notified through the return code of the 1047 response if a method is not allowed on a resource. Servers should 1048 return the status code 501 (not implemented) if the method is 1049 unknown or not implemented. 1051 The set of common methods for HTTP/1.0 is described below. Although 1052 this set can be easily expanded, additional methods cannot be 1053 assumed to share the same semantics for separately extended clients 1054 and servers. 1056 5.2.1 GET 1058 The GET method means retrieve whatever information (in the form of 1059 an entity) is identified by the Request-URI. If the Request-URI 1060 refers to a data-producing process, it is the produced data which 1061 shall be returned as the entity in the response and not the source 1062 text of the process, unless that text happens to be the output of 1063 the process. 1065 The semantics of the GET method changes to a "conditional GET" if 1066 the request message includes an If-Modified-Since header field. A 1067 conditional GET method requests that the identified resource be 1068 transferred only if it has been modified since the date given by 1069 the If-Modified-Since header, as described in Section 8.9. The 1070 conditional GET method is intended to reduce network usage by 1071 allowing cached entities to be refreshed without requiring multiple 1072 requests or transferring unnecessary data. 1074 5.2.2 HEAD 1076 The HEAD method is identical to GET except that the server must not 1077 return any Entity-Body in the response. The metainformation 1078 contained in the HTTP headers in response to a HEAD request should 1079 be identical to the information sent in response to a GET request. 1080 This method can be used for obtaining metainformation about the 1081 resource identified by the Request-URI without transferring the 1082 Entity-Body itself. This method is often used for testing hypertext 1083 links for validity, accessibility, and recent modification. 1085 There is no "conditional HEAD" request analogous to the conditional 1086 GET. If an If-Modified-Since header field is included with a HEAD 1087 request, it should be ignored. 1089 5.2.3 POST 1091 The POST method is used to request that the destination server 1092 accept the entity enclosed in the request as a new subordinate of 1093 the resource identified by the Request-URI in the Request-Line. 1094 POST is designed to allow a uniform method to cover the following 1095 functions: 1097 o Annotation of existing resources; 1099 o Posting a message to a bulletin board, newsgroup, mailing list, 1100 or similar group of articles; 1102 o Providing a block of data, such as the result of submitting a 1103 form [3], to a data-handling process; 1105 o Extending a database through an append operation. 1107 The actual function performed by the POST method is determined by 1108 the server and is usually dependent on the Request-URI. The posted 1109 entity is subordinate to that URI in the same way that a file is 1110 subordinate to a directory containing it, a news article is 1111 subordinate to a newsgroup to which it is posted, or a record is 1112 subordinate to a database. 1114 A successful POST does not require that the entity be created as a 1115 resource on the origin server or made accessible for future 1116 reference. That is, the action performed by the POST method might 1117 not result in a resource that can be identified by a URI. In this 1118 case, either 200 (ok) or 204 (no content) is the appropriate 1119 response status, depending on whether or not the response includes 1120 an entity that describes the result. 1122 If a resource has been created on the origin server, the response 1123 should be 201 (created) and contain an entity (preferably of type 1124 "text/html") which describes the status of the request and refers 1125 to the new resource. 1127 A valid Content-Length is required on all HTTP/1.0 POST requests. 1128 An HTTP/1.0 server should respond with a 400 (bad request) message 1129 if it cannot determine the length of the request message's content. 1131 Caching intermediaries must not cache responses to a POST request. 1133 5.3 Request-URI 1135 The Request-URI is a Uniform Resource Identifier (Section 3.2) and 1136 identifies the resource upon which to apply the request. 1138 Request-URI = absoluteURI | abs_path 1140 The two options for Request-URI are dependent on the nature of the 1141 request. 1143 The absoluteURI form is only allowed when the request is being made 1144 to a proxy server. The proxy is requested to forward the request 1145 and return the response. If the request is GET or HEAD and a 1146 response is cached, the proxy may use the cached message if it 1147 passes any restrictions in the Expires header field. Note that the 1148 proxy may forward the request on to another proxy or directly to 1149 the origin server specified by the absoluteURI. In order to avoid 1150 request loops, a proxy must be able to recognize all of its server 1151 names, including any aliases, local variations, and the numeric IP 1152 address. An example Request-Line would be: 1154 GET http://www.w3.org/hypertext/WWW/TheProject.html HTTP/1.0 1156 The most common form of Request-URI is that used to identify a 1157 resource on an origin server. In this case, only the absolute path 1158 of the URI is transmitted (see Section 3.2.1, abs_path). For 1159 example, a client wishing to retrieve the resource above directly 1160 from the origin server would create a TCP connection to port 80 of 1161 the host "www.w3.org" and send the line: 1163 GET /hypertext/WWW/TheProject.html HTTP/1.0 1165 followed by the remainder of the Full-Request. Note that the 1166 absolute path cannot be empty; if none is present in the original 1167 URI, it must be given as "/" (the server root). 1169 5.4 Request Header Fields 1171 The request header fields allow the client to pass additional 1172 information about the request, and about the client itself, to the 1173 server. All header fields are optional and conform to the generic 1174 HTTP-header syntax. 1176 Request-Header = Authorization ; Section 8.2 1177 | From ; Section 8.8 1178 | If-Modified-Since ; Section 8.9 1179 | Referer ; Section 8.14 1180 | User-Agent ; Section 8.16 1182 Request-Header field names can be extended only via a change in the 1183 protocol version. Unknown header fields are treated as 1184 Entity-Header fields. 1186 6. Response 1188 After receiving and interpreting a request message, a server 1189 responds in the form of an HTTP response message. 1191 Response = Simple-Response | Full-Response 1193 Simple-Response= [ Entity-Body ] 1195 Full-Response = Status-Line ; Section 6.1 1196 *( General-Header ; Section 4.3 1197 | Response-Header ; Section 6.3 1198 | Entity-Header ) ; Section 7.1 1199 CRLF 1200 [ Entity-Body ] ; Section 7.2 1202 A Simple-Response should only be sent in response to an HTTP/0.9 1203 Simple-Request or if the server only supports the more limited 1204 HTTP/0.9 protocol. If a client sends an HTTP/1.0 Full-Request and 1205 receives a response that does not begin with a Status-Line, it 1206 should assume that the response is a Simple-Response and parse it 1207 accordingly. Note that the Simple-Response consists only of the 1208 entity body and is terminated by the server closing the connection. 1210 6.1 Status-Line 1212 The first line of a Full-Response message is the Status-Line, 1213 consisting of the protocol version followed by a numeric status 1214 code and its associated textual phrase, with each element separated 1215 by SP characters. No CR or LF is allowed except in the final CRLF 1216 sequence. 1218 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 1220 Since a status line always begins with the protocol version and 1221 status code 1223 "HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP 1225 (e.g., "HTTP/1.0 200 "), the presence of that expression is 1226 sufficient to differentiate a Full-Response from a Simple-Response. 1227 Although the Simple-Response format may allow such an expression to 1228 occur at the beginning of an entity body, and thus cause a 1229 misinterpretation of the message if it was given in response to a 1230 Full-Request, most HTTP/0.9 servers are limited to responses of 1231 type "text/html" and therefore would never generate such a response. 1233 6.2 Status Codes and Reason Phrases 1235 The Status-Code element is a 3-digit integer result code of the 1236 attempt to understand and satisfy the request. The Reason-Phrase is 1237 intended to give a short textual description of the Status-Code. 1238 The Status-Code is intended for use by automata and the 1239 Reason-Phrase is intended for the human user. The client is not 1240 required to examine or display the Reason-Phrase. 1242 The first digit of the Status-Code defines the class of response. 1243 The last two digits do not have any categorization role. There are 1244 5 values for the first digit: 1246 o 1xx: Informational - Not used, but reserved for future use 1248 o 2xx: Success - The action was successfully received, 1249 understood, and accepted. 1251 o 3xx: Redirection - Further action must be taken in order to 1252 complete the request 1254 o 4xx: Client Error - The request contains bad syntax or cannot 1255 be fulfilled 1257 o 5xx: Server Error - The server failed to fulfill an apparently 1258 valid request 1260 The individual values of the numeric status codes defined for 1261 HTTP/1.0, and an example set of corresponding Reason-Phrase's, are 1262 presented below. The reason phrases listed here are only 1263 recommended -- they may be replaced by local equivalents without 1264 affecting the protocol. 1266 Status-Code = "200" ; OK 1267 | "201" ; Created 1268 | "202" ; Accepted 1269 | "204" ; No Content 1270 | "301" ; Moved Permanently 1271 | "302" ; Moved Temporarily 1272 | "304" ; Not Modified 1273 | "400" ; Bad Request 1274 | "401" ; Unauthorized 1275 | "403" ; Forbidden 1276 | "404" ; Not Found 1277 | "500" ; Internal Server Error 1278 | "501" ; Not Implemented 1279 | "502" ; Bad Gateway 1280 | "503" ; Service Unavailable 1281 | extension-code 1283 extension-code = 3DIGIT 1285 Reason-Phrase = * 1287 HTTP status codes are extensible, but the above codes are the only 1288 ones generally recognized in current practice. HTTP applications 1289 are not required to understand the meaning of all registered status 1290 codes, though such understanding is obviously desirable. However, 1291 applications must understand the class of any status code, as 1292 indicated by the first digit, and treat any unknown response as 1293 being equivalent to the x00 status code of that class. For example, 1294 if an unknown status code of 421 is received by the client, it can 1295 safely assume that there was something wrong with its request and 1296 treat the response as if it had received a 400 status code. In such 1297 cases, user agents are encouraged to present the entity returned 1298 with the response to the user, since that entity is likely to 1299 include human-readable information which will explain the unusual 1300 status. 1302 Each Status-Code is described below, including a description of 1303 which method(s) it can follow and any metainformation required in 1304 the response. 1306 6.2.1 Informational 1xx 1308 This class of status code indicates a provisional response, 1309 consisting only of the Status-Line and optional headers, and is 1310 terminated by an empty line. HTTP/1.0 does not define any 1xx 1311 status codes and they are not a valid response to a HTTP/1.0 1312 request. However, they may be useful for experimental applications 1313 which are outside the scope of this specification. 1315 6.2.2 Successful 2xx 1317 This class of status code indicates that the client's request was 1318 successfully received, understood, and accepted. 1320 200 OK 1322 The request has succeeded. The information returned with the 1323 response is dependent on the method used in the request, as follows: 1325 GET an entity corresponding to the requested resource is being 1326 sent in the response; 1328 HEAD the response must only contain the header information and 1329 no Entity-Body; 1331 POST an entity describing or containing the result of the action. 1333 201 Created 1335 The request has been fulfilled and resulted in a new resource being 1336 created. The newly created resource can be referenced by the URI(s) 1337 returned in the entity of the response. The origin server is 1338 encouraged, but not obliged, to actually create the resource before 1339 using this Status-Code. If the action cannot be carried out 1340 immediately, or within a clearly defined timeframe, the server 1341 should respond with 202 (accepted) instead. 1343 Of the methods defined by this specification, only POST can create 1344 a resource. 1346 202 Accepted 1348 The request has been accepted for processing, but the processing 1349 has not been completed. The request may or may not eventually be 1350 acted upon, as it may be disallowed when processing actually takes 1351 place. There is no facility for re-sending a status code from an 1352 asynchronous operation such as this. 1354 The 202 response is intentionally non-committal. Its purpose is to 1355 allow a server to accept a request for some other process (perhaps 1356 a batch-oriented process that is only run once per day) without 1357 requiring that the user agent's connection to the server persist 1358 until the process is completed. The entity returned with this 1359 response should include an indication of the request's current 1360 status and either a pointer to a status monitor or some estimate of 1361 when the user can expect the request to be fulfilled. 1363 204 No Content 1365 The server has fulfilled the request but there is no new 1366 information to send back. If the client is a user agent, it should 1367 not change its document view from that which caused the request to 1368 be generated. This response is primarily intended to allow input 1369 for scripts or other actions to take place without causing a change 1370 to the user agent's active document view. The response may include 1371 new metainformation in the form of entity headers, which should 1372 apply to the document currently in the user agent's active view. 1374 6.2.3 Redirection 3xx 1376 This class of status code indicates that further action needs to be 1377 taken by the user agent in order to fulfill the request. The action 1378 required can sometimes be carried out by the user agent without 1379 interaction with the user, but it is strongly recommended that this 1380 only take place if the method used in the request is GET or HEAD. A 1381 user agent should never automatically redirect a request more than 1382 5 times, since such redirections usually indicate an infinite loop. 1384 300 Multiple Choices 1386 This response code is not directly used by HTTP/1.0 applications, 1387 but serves as the default for interpreting the 3xx class of 1388 responses. 1390 The requested resource is available at one or more locations. 1391 Unless it was a HEAD request, the response should include an entity 1392 containing a list of resource characteristics and locations from 1393 which the user or user agent can choose the one most appropriate. 1394 If the server has a preferred choice, it should include the URL in 1395 a Location field; user agents may use the Location value for 1396 automatic redirection. 1398 301 Moved Permanently 1400 The requested resource has been assigned a new permanent URL and 1401 any future references to this resource should be done using that 1402 URL. Clients with link editing capabilities are encouraged to 1403 automatically relink references to the Request-URI to the new 1404 reference returned by the server, where possible. 1406 The new URL must be given by the Location field in the response. 1407 Unless it was a HEAD request, the Entity-Body of the response 1408 should contain a short note with a hyperlink to the new URL. 1410 If the 301 status code is received in response to a request using 1411 the POST method, the user agent must not automatically redirect the 1412 request unless it can be confirmed by the user, since this might 1413 change the conditions under which the request was issued. 1415 302 Moved Temporarily 1417 The requested resource resides temporarily under a different URL. 1418 Since the redirection may be altered on occasion, the client should 1419 continue to use the Request-URI for future requests. 1421 The URL must be given by the Location field in the response. Unless 1422 it was a HEAD request, the Entity-Body of the response should 1423 contain a short note with a hyperlink to the new URI(s). 1425 If the 302 status code is received in response to a request using 1426 the POST method, the user agent must not automatically redirect the 1427 request unless it can be confirmed by the user, since this might 1428 change the conditions under which the request was issued. 1430 304 Not Modified 1432 If the client has performed a conditional GET request and access is 1433 allowed, but the document has not been modified since the date and 1434 time specified in the If-Modified-Since field, the server shall 1435 respond with this status code and not send an Entity-Body to the 1436 client. Header fields contained in the response should only include 1437 information which is relevant to cache managers and which may have 1438 changed independently of the entity's Last-Modified date. Examples 1439 of relevant header fields include: Date, Server, and Expires. 1441 6.2.4 Client Error 4xx 1443 The 4xx class of status code is intended for cases in which the 1444 client seems to have erred. If the client has not completed the 1445 request when a 4xx code is received, it should immediately cease 1446 sending data to the server. Except when responding to a HEAD 1447 request, the server is encouraged to include an entity containing 1448 an explanation of the error situation, and whether it is a 1449 temporary or permanent condition. These status codes are applicable 1450 to any request method. 1452 Note: If the client is sending data, server implementations 1453 on TCP should be careful to ensure that the client 1454 acknowledges receipt of the packet(s) containing the 1455 response prior to closing the input connection. If the 1456 client continues sending data to the server after the close, 1457 the server's controller will send a reset packet to the 1458 client, which may erase the client's unacknowledged input 1459 buffers before they can be read and interpreted by the HTTP 1460 application. 1462 400 Bad Request 1464 The request could not be understood by the server due to malformed 1465 syntax. The client is discouraged from repeating the request 1466 without modifications. 1468 401 Unauthorized 1470 The request requires user authentication. The response must include 1471 a WWW-Authenticate header field (Section 8.17) containing a 1472 challenge applicable to the requested resource. The client may 1473 repeat the request with a suitable Authorization header field. If 1474 the request already included Authorization credentials, then the 1475 401 response indicates that authorization has been refused for 1476 those credentials. If the 401 response contains the same challenge 1477 as the prior response, and the user agent has already attempted 1478 authentication at least once, then the user should be presented the 1479 entity that was given in the response, since that entity may 1480 include relevent diagnostic information. HTTP access authentication 1481 is explained in Section 9. 1483 403 Forbidden 1485 The server understood the request, but is refusing to perform the 1486 request for an unspecified reason. Authorization will not help and 1487 the request should not be repeated. This status code can be used if 1488 the server does not want to make public why the request has not 1489 been fulfilled. 1491 404 Not Found 1493 The server has not found anything matching the Request-URI. No 1494 indication is given of whether the condition is temporary or 1495 permanent. If the server does not wish to make this information 1496 available to the client, the status code 403 (forbidden) can be 1497 used instead. 1499 6.2.5 Server Errors 5xx 1501 Response status codes beginning with the digit "5" indicate cases 1502 in which the server is aware that it has erred or is incapable of 1503 performing the request. If the client has not completed the request 1504 when a 5xx code is received, it should immediately cease sending 1505 data to the server. Except when responding to a HEAD request, the 1506 server is encouraged to include an entity containing an explanation 1507 of the error situation, and whether it is a temporary or permanent 1508 condition. These response codes are applicable to any request 1509 method and there are no required header fields. 1511 500 Internal Server Error 1513 The server encountered an unexpected condition which prevented it 1514 from fulfilling the request. 1516 501 Not Implemented 1518 The server does not support the functionality required to fulfill 1519 the request. This is the appropriate response when the server does 1520 not recognize the request method and is not capable of supporting 1521 it for any resource. 1523 502 Bad Gateway 1525 The server received an invalid response from the gateway or 1526 upstream server it accessed in attempting to fulfill the request. 1528 503 Service Unavailable 1530 The server is currently unable to handle the request due to a 1531 temporary overloading or maintenance of the server. The implication 1532 is that this is a temporary condition which will be alleviated 1533 after some delay. 1535 Note: The existence of the 503 status code does not imply 1536 that a server must use it when becoming overloaded. Some 1537 servers may wish to simply refuse the connection. 1539 6.3 Response Header Fields 1541 The response header fields allow the server to pass additional 1542 information about the response which cannot be placed in the 1543 Status-Line. These header fields are not intended to give 1544 information about an Entity-Body returned in the response, but 1545 about the server itself. 1547 Response-Header = Location ; Section 8.11 1548 | Server ; Section 8.15 1549 | WWW-Authenticate ; Section 8.17 1551 Response-Header field names can be extended only via a change in 1552 the protocol version. Unknown header fields are treated as 1553 Entity-Header fields. 1555 7. Entity 1557 Full-Request and Full-Response messages may transfer an entity 1558 within some requests and responses. An entity consists of 1559 Entity-Header fields and (usually) an Entity-Body. In this section, 1560 both sender and recipient refer to either the client or the server, 1561 depending on who sends and who receives the entity. 1563 7.1 Entity Header Fields 1565 Entity-Header fields define optional metainformation about the 1566 Entity-Body or, if no body is present, about the resource 1567 identified by the request. 1569 Entity-Header = Allow ; Section 8.1 1570 | Content-Encoding ; Section 8.3 1571 | Content-Length ; Section 8.4 1572 | Content-Type ; Section 8.5 1573 | Expires ; Section 8.7 1574 | Last-Modified ; Section 8.10 1575 | extension-header 1577 extension-header=HTTP-header 1579 The extension-header mechanism allows additional Entity-Header to 1580 be defined without changing the protocol, but these fields cannot 1581 be assumed to be recognizable by the recipient. Unknown header 1582 fields should be ignored by the recipient and forwarded by proxies. 1584 7.2 Entity Body 1586 The entity-body (if any) sent with an HTTP/1.0 request or response 1587 is in a format and encoding defined by the Entity-Header fields. 1589 Entity-Body = *OCTET 1591 An entity-body is included with a request message only when the 1592 request method calls for one. This specification defines one 1593 request method, POST, that allows an entity-body. In general, the 1594 presence of an entity-body in a request is signaled by the 1595 inclusion of a Content-Length header field in the request message 1596 headers. HTTP/1.0 requests containing content must include a valid 1597 Content-Length header field. 1599 For response messages, whether or not an entity-body is included 1600 with a message is dependent on both the request method and the 1601 response code. All responses to the HEAD request method must not 1602 include a body, even though the presence of content header fields 1603 may lead one to believe they do. The responses 204 (no content) and 1604 304 (not modified) must not include a message body. 1606 7.2.1 Type 1608 When an Entity-Body is included with a message, the data type of 1609 that body is determined via the header fields Content-Type and 1610 Content-Encoding. These define a two-layer, ordered encoding model: 1612 entity-body := Content-Encoding( Content-Type( data ) ) 1614 A Content-Type specifies the media type of the underlying data. A 1615 Content-Encoding may be used to indicate any additional content 1616 coding applied to the type, usually for the purpose of data 1617 compression, that is a property of the resource requested. The 1618 default for the content encoding is none (i.e., the identity 1619 function). 1621 The Content-Type header field has no default value. If and only if 1622 the media type is not given by a Content-Type header, as is always 1623 the case for Simple-Response messages, the receiver may attempt to 1624 guess the media type via inspection of its content and/or the name 1625 extension(s) of the URL used to specify the resource. If the media 1626 type remains unknown, the receiver should treat it as type 1627 "application/octet-stream". 1629 7.2.2 Length 1631 When an Entity-Body is included with a message, the length of that 1632 body may be determined in one of several ways. If a Content-Length 1633 header field is present, its value in bytes represents the length 1634 of the Entity-Body. Otherwise, the body length is determined by the 1635 closing of the connection by the server. 1637 Closing the connection cannot be used to indicate the end of a 1638 request body, since it leaves no possibility for the server to send 1639 back a response. Therefore, HTTP/1.0 requests containing content 1640 must include a valid Content-Length header field. If a request 1641 contains an entity body and Content-Length is not specified, and 1642 the server does not recognize or cannot calculate the length from 1643 other fields, then the server should send a 400 (bad request) 1644 response. 1646 Note: Some older servers supply an invalid Content-Length 1647 when sending a document that contains server-side includes 1648 dynamically inserted into the data stream. It must be 1649 emphasized that this will not be tolerated by future 1650 versions of HTTP. Unless the client knows that it is 1651 receiving a response from a compliant server, it should not 1652 depend on the Content-Length value being correct. 1654 8. Header Field Definitions 1656 This section defines the syntax and semantics of all standard 1657 HTTP/1.0 header fields. For Entity-Header fields, both sender and 1658 recipient refer to either the client or the server, depending on 1659 who sends and who receives the entity. 1661 8.1 Allow 1663 The Allow header field lists the set of methods supported by the 1664 resource identified by the Request-URI. The purpose of this field 1665 is strictly to inform the recipient of valid methods associated 1666 with the resource. The Allow header field is not permitted in a 1667 request using the POST method, and thus should be ignored if it is 1668 received as part of a POST entity. 1670 Allow = "Allow" ":" 1#method 1672 Example of use: 1674 Allow: GET, HEAD 1676 This field cannot prevent a client from trying other methods. 1677 However, the indications given by the Allow field value should be 1678 followed. This field has no default value; if left undefined, the 1679 set of allowed methods is defined by the origin server at the time 1680 of each request. 1682 A proxy must not modify the allow header even if it does not 1683 understand all the methods specified, since the user agent may have 1684 other means of communicating with the origin server. 1686 The Allow header field does not indicate what methods are 1687 implemented by the server. 1689 8.2 Authorization 1691 A user agent that wishes to authenticate itself with a 1692 server--usually, but not necessarily, after receiving a 401 1693 response--may do so by including an Authorization header field with 1694 the request. The Authorization field value consists of credentials 1695 containing the authentication information of the user agent for the 1696 realm of the resource being requested. 1698 Authorization = "Authorization" ":" credentials 1700 HTTP access authentication is described in Section 9. If a request 1701 is authenticated and a realm specified, the same credentials should 1702 be valid for all other requests within this realm. 1704 Proxies must not cache the response to a request containing an 1705 Authorization field. 1707 8.3 Content-Encoding 1709 The Content-Encoding header field is used as a modifier to the 1710 media-type. When present, its value indicates what additional 1711 content coding has been applied to the resource, and thus what 1712 decoding mechanism must be applied in order to obtain the 1713 media-type referenced by the Content-Type header field. The 1714 Content-Encoding is primarily used to allow a document to be 1715 compressed without losing the identity of its underlying media type. 1717 Content-Encoding = "Content-Encoding" ":" content-coding 1719 Content codings are defined in Section 3.5. An example of its use is 1721 Content-Encoding: x-gzip 1723 The Content-Encoding is a characteristic of the resource identified 1724 by the Request-URI. Typically, the resource is stored with this 1725 encoding and is only decoded before rendering or analogous usage. 1727 8.4 Content-Length 1729 The Content-Length header field indicates the size of the 1730 Entity-Body, in decimal number of octets, sent to the recipient or, 1731 in the case of the HEAD method, the size of the Entity-Body that 1732 would have been sent had the request been a GET. 1734 Content-Length = "Content-Length" ":" 1*DIGIT 1736 An example is 1738 Content-Length: 3495 1740 Although it is not required, applications are strongly encouraged 1741 to use this field to indicate the size of the Entity-Body to be 1742 transferred, regardless of the media type of the entity. 1744 Any Content-Length greater than or equal to zero is a valid value. 1745 Section 7.2.2 describes how to determine the length of an 1746 Entity-Body if a Content-Length is not given. 1748 Note: The meaning of this field is significantly different 1749 from the corresponding definition in MIME, where it is an 1750 optional field used within the "message/external-body" 1751 content-type. In HTTP, it should be used whenever the 1752 entity's length can be determined prior to being transferred. 1754 8.5 Content-Type 1756 The Content-Type header field indicates the media type of the 1757 Entity-Body sent to the recipient or, in the case of the HEAD 1758 method, the media type that would have been sent had the request 1759 been a GET. 1761 Content-Type = "Content-Type" ":" media-type 1763 Media types are defined in Section 3.6. An example of the field is 1765 Content-Type: text/html 1767 The Content-Type header field has no default value. Further 1768 discussion of methods for identifying the media type of an entity 1769 is provided in Section 7.2.1. 1771 8.6 Date 1773 The Date header represents the date and time at which the message 1774 was originated, having the same semantics as orig-date in RFC 822. 1775 The field value is an HTTP-date, as described in Section 3.3. 1777 Date = "Date" ":" HTTP-date 1779 An example is 1781 Date: Tue, 15 Nov 1994 08:12:31 GMT 1783 If a message is received via direct connection with the user agent 1784 (in the case of requests) or the origin server (in the case of 1785 responses), then the default date can be assumed to be the current 1786 date at the receiving end. However, since the date--as it is 1787 believed by the origin--is important for evaluating cached 1788 responses, origin servers should always include a Date header. 1789 Clients should only send a Date header field in messages that 1790 include an entity body, as in the case of the POST request, and 1791 even then it is optional. A received message which does not have a 1792 Date header field should be assigned one by the receiver if and 1793 only if the message will be cached by that receiver or gatewayed 1794 via a protocol which requires a Date. 1796 Only one Date header field is allowed per message. In theory, the 1797 date should represent the moment just before the entity is 1798 generated. In practice, the date can be generated at any time 1799 during the message origination without affecting its semantic value. 1801 Note: An earlier version of this document incorrectly 1802 specified that this field should contain the creation date 1803 of the enclosed Entity-Body. This has been changed to 1804 reflect actual (and proper) usage. 1806 8.7 Expires 1808 The Expires field gives the date/time after which the entity should 1809 be considered stale. This allows information providers to suggest 1810 the volatility of the resource. Caching clients, including proxies, 1811 must not cache this copy of the resource beyond the date given, 1812 unless its status has been updated by a later check of the origin 1813 server. The presence of an Expires field does not imply that the 1814 original resource will change or cease to exist at, before, or 1815 after that time. However, information providers that know or even 1816 suspect that a resource will change by a certain date are strongly 1817 encouraged to include an Expires header with that date. The format 1818 is an absolute date and time as defined by HTTP-date in Section 3.3. 1820 Expires = "Expires" ":" HTTP-date 1822 An example of its use is 1824 Expires: Thu, 01 Dec 1994 16:00:00 GMT 1826 The Expires field has no default value. If the date given is equal 1827 to or earlier than the value of the Date header, the recipient must 1828 not cache the enclosed entity. If a resource is dynamic by nature, 1829 as is the case with many data-producing processes, copies of that 1830 resource should be given an appropriate Expires value which 1831 reflects that dynamism. 1833 The Expires field cannot be used to force a user agent to refresh 1834 its display or reload a resource; its semantics apply only to 1835 caching mechanisms, and such mechanisms need only check a 1836 resource's expiration status when a new request for that resource 1837 is initiated. 1839 User agents often have history mechanisms, such as "Back" buttons 1840 and history lists, which can be used to redisplay an entity 1841 retrieved earlier in a session. By default, the Expires field does 1842 not apply to history mechanisms. If the entity is still in storage, 1843 a history mechanism should display it even if the entity has 1844 expired, unless the user has specifically configured the agent to 1845 refresh expired history documents. 1847 Note: Applications are encouraged to be tolerant of bad or 1848 misinformed implementations of the Expires header. A value 1849 of zero (0) or an invalid date format should be considered 1850 equivalent to an "expires immediately." Although these 1851 values are not legitimate for HTTP/1.0, a robust 1852 implementation is always desirable. 1854 8.8 From 1856 The From header field, if given, should contain an Internet e-mail 1857 address for the human user who controls the requesting user agent. 1858 The address should be machine-usable, as defined by mailbox in 1859 RFC 822 [7] (as updated by RFC 1123 [6]): 1861 From = "From" ":" mailbox 1863 An example is: 1865 From: webmaster@w3.org 1867 This header field may be used for logging purposes and as a means 1868 for identifying the source of invalid or unwanted requests. It 1869 should not be used as an insecure form of access protection. The 1870 interpretation of this field is that the request is being performed 1871 on behalf of the person given, who accepts responsibility for the 1872 method performed. In particular, robot agents should include this 1873 header so that the person responsible for running the robot can be 1874 contacted if problems occur on the receiving end. 1876 The Internet e-mail address in this field may be separate from the 1877 Internet host which issued the request. For example, when a request 1878 is passed through a proxy, the original issuer's address should be 1879 used. 1881 Note: The client should not send the From header field 1882 without the user's approval, as it may conflict with the 1883 user's privacy interests or their site's security policy. It 1884 is strongly recommended that the user be able to disable, 1885 enable, and modify the value of this field at any time prior 1886 to a request. 1888 8.9 If-Modified-Since 1890 The If-Modified-Since header field is used with the GET method to 1891 make it conditional: if the requested resource has not been 1892 modified since the time specified in this field, a copy of the 1893 resource will not be returned from the server; instead, a 304 (not 1894 modified) response will be returned without any Entity-Body. 1896 If-Modified-Since = "If-Modified-Since" ":" HTTP-date 1898 An example of the field is: 1900 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 1902 A conditional GET method requests that the identified resource be 1903 transferred only if it has been modified since the date given by 1904 the If-Modified-Since header. The algorithm for determining this 1905 includes the following cases: 1907 a) If the request would normally result in anything other than 1908 a 200 (ok) status, or if the passed If-Modified-Since date 1909 is invalid, the response is exactly the same as for a 1910 normal GET. A date which is later than the server's current 1911 time is invalid. 1913 b) If the resource has been modified since the 1914 If-Modified-Since date, the response is exactly the same as 1915 for a normal GET. 1917 c) If the resource has not been modified since a valid 1918 If-Modified-Since date, the server shall return a 304 (not 1919 modified) response. 1921 The purpose of this feature is to allow efficient updates of cached 1922 information with a minimum amount of transaction overhead. 1924 8.10 Last-Modified 1926 The Last-Modified header field indicates the date and time at which 1927 the sender believes the resource was last modified. The exact 1928 semantics of this field are defined in terms of how the receiver 1929 should interpret it: if the receiver has a copy of this resource 1930 which is older than the date given by the Last-Modified field, that 1931 copy should be considered stale. 1933 Last-Modified = "Last-Modified" ":" HTTP-date 1935 An example of its use is 1937 Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT 1939 The exact meaning of this header field depends on the 1940 implementation of the sender and the nature of the original 1941 resource. For files, it may be just the file system last-modified 1942 time. For entities with dynamically included parts, it may be the 1943 most recent of the set of last-modify times for its component 1944 parts. For database gateways, it may be the last-update timestamp 1945 of the record. For virtual objects, it may be the last time the 1946 internal state changed. 1948 An origin server must not send a Last-Modified date which is later 1949 than the server's time of message origination. In such cases, where 1950 the resource's last modification would indicate some time in the 1951 future, the server must replace that date with the message 1952 origination date. 1954 8.11 Location 1956 The Location response header field defines the exact location of 1957 the resource that was identified by the Request-URI. For 3xx 1958 responses, the location must indicate the server's preferred URL 1959 for automatic redirection to the resource. Only one absolute URL is 1960 allowed. 1962 Location = "Location" ":" absoluteURI 1964 An example is 1966 Location: http://www.w3.org/hypertext/WWW/NewLocation.html 1968 8.12 MIME-Version 1970 HTTP is not a MIME-conformant protocol (see Appendix C). However, 1971 HTTP/1.0 messages may include a single MIME-Version header field to 1972 indicate what version of the MIME protocol was used to construct 1973 the message. Use of the MIME-Version header field should indicate 1974 that the message is in full compliance with the MIME protocol (as 1975 defined in [5]). Unfortunately, current versions of HTTP/1.0 1976 clients and servers use this field indiscriminately, and thus 1977 receivers must not take it for granted that the message is indeed 1978 in full compliance with MIME. Gateways are responsible for ensuring 1979 this compliance (where possible) when exporting HTTP messages to 1980 strict MIME environments. Future HTTP/1.0 applications must only 1981 use MIME-Version when the message is intended to be MIME-conformant. 1983 MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT 1985 MIME version "1.0" is the default for use in HTTP/1.0. However, 1986 HTTP/1.0 message parsing and semantics are defined by this document 1987 and not the MIME specification. 1989 8.13 Pragma 1991 The Pragma message header field is used to include 1992 implementation-specific directives that may apply to any recipient 1993 along the request/response chain. The directives typically specify 1994 behavior intended to prevent intermediate proxies or caches from 1995 adversely interfering with the request or response. All pragma 1996 directives specify optional behavior from the viewpoint of the 1997 protocol; however, some systems may require that behavior be 1998 consistent with the directives. HTTP/1.0 only defines semantics for 1999 the "no-cache" directive on request messages. 2001 Pragma = "Pragma" ":" 1#pragma-directive 2003 pragma-directive = "no-cache" | extension-pragma 2004 extension-pragma = token [ "=" word ] 2006 When the "no-cache" directive is present in a request message, a 2007 caching intermediary should forward the request toward the origin 2008 server even if it has a cached copy of what is being requested. 2009 This allows a client to insist upon receiving an authoritative 2010 response to its request. It also allows a client to refresh a 2011 cached copy which is known to be corrupted or stale. 2013 Pragma directives must be passed through by a proxy, regardless of 2014 their significance to that proxy, since the directives may be 2015 applicable to all recipients along the request/response chain. It 2016 is not possible to specify a pragma for a specific recipient; 2017 however, any pragma directive not relevant to a recipient should be 2018 ignored by that recipient. 2020 8.14 Referer 2022 The Referer request header field allows the client to specify, for 2023 the server's benefit, the address (URI) of the resource from which 2024 the Request-URI was obtained. This allows a server to generate 2025 lists of back-links to resources for interest, logging, optimized 2026 caching, etc. It also allows obsolete or mistyped links to be 2027 traced for maintenance. The Referer field must not be sent if the 2028 Request-URI was obtained from a source that does not have its own 2029 URI, such as input from the user keyboard. 2031 Referer = "Referer" ":" ( absoluteURI | relativeURI ) 2033 Example: 2035 Referer: http://www.w3.org/hypertext/DataSources/Overview.html 2037 If a partial URI is given, it should be interpreted relative to the 2038 Request-URI. The URI must not include a fragment. 2040 Note: Because the source of a link may be private 2041 information or may reveal an otherwise private information 2042 source, it is strongly recommended that the user be able to 2043 select whether or not the Referer field is sent. For 2044 example, a browser client could have a toggle switch for 2045 browsing openly/anonymously, which would respectively 2046 enable/disable the sending of Referer and From information. 2048 8.15 Server 2050 The Server response header field contains information about the 2051 software used by the origin server to handle the request. The field 2052 can contain multiple product tokens (Section 3.7) and comments 2053 identifying the server and any significant subproducts. By 2054 convention, the product tokens are listed in order of their 2055 significance for identifying the application. 2057 Server = "Server" ":" 1*( product | comment ) 2059 Example: 2061 Server: CERN/3.0 libwww/2.17 2063 If the response is being forwarded through a proxy, the proxy 2064 application should not add its data to the product list. 2066 Note: Revealing the specific software version of the server 2067 may allow the server machine to become more vulnerable to 2068 attacks against software that is known to contain security 2069 holes. Server implementors are encouraged to make this field 2070 a configurable option. 2072 8.16 User-Agent 2074 The User-Agent field contains information about the user agent 2075 originating the request. This is for statistical purposes, the 2076 tracing of protocol violations, and automated recognition of user 2077 agents for the sake of tailoring responses to avoid particular user 2078 agent limitations. Although it is not required, user agents should 2079 always include this field with requests. The field can contain 2080 multiple product tokens (Section 3.7) and comments identifying the 2081 agent and any subproducts which form a significant part of the user 2082 agent. By convention, the product tokens are listed in order of 2083 their significance for identifying the application. 2085 User-Agent = "User-Agent" ":" 1*( product | comment ) 2087 Example: 2089 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 2091 The User-Agent field may include additional information within 2092 comments. 2094 Note: Some current proxy applications append their product 2095 information to the list in the User-Agent field. This is not 2096 recommended, since it makes machine interpretation of these 2097 fields ambiguous. 2099 8.17 WWW-Authenticate 2101 The WWW-Authenticate header field must be included in 401 2102 (unauthorized) response messages. The field value consists of at 2103 least one challenge that indicates the authentication scheme(s) and 2104 parameters applicable to the Request-URI. 2106 WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge 2108 The HTTP access authentication process is described in Section 9. 2109 User agents must take special care in parsing the WWW-Authenticate 2110 field value if it contains more than one challenge, or if more than 2111 one WWW-Authenticate header field is provided, since the contents 2112 of a challenge may itself contain a comma-separated list of 2113 authentication parameters. 2115 9. Access Authentication 2117 HTTP provides a simple challenge-response authentication mechanism 2118 which may be used by a server to challenge a client request and by 2119 a client to provide authentication information. It uses an 2120 extensible, case-insensitive token to identify the authentication 2121 scheme, followed by a comma-separated list of attribute-value pairs 2122 which carry the parameters necessary for achieving authentication 2123 via that scheme. 2125 auth-scheme = token 2127 auth-param = token "=" quoted-string 2129 The 401 (unauthorized) response message is used by an origin server 2130 to challenge the authorization of a user agent. This response must 2131 include a WWW-Authenticate header field containing at least one 2132 challenge applicable to the requested resource. 2134 challenge = auth-scheme 1*SP realm *( "," auth-param ) 2136 realm = "realm" "=" realm-value 2137 realm-value = quoted-string 2139 The realm attribute (case-insensitive) is required for all 2140 authentication schemes which issue a challenge. The realm value 2141 (case-sensitive), in combination with the canonical root URL of the 2142 server being accessed, defines the protection space. These realms 2143 allow the protected resources on a server to be partitioned into a 2144 set of protection spaces, each with its own authentication scheme 2145 and/or authorization database. The realm value is a string, 2146 generally assigned by the origin server, which may have additional 2147 semantics specific to the authentication scheme. 2149 A user agent that wishes to authenticate itself with a 2150 server--usually, but not necessarily, after receiving a 401 2151 response--may do so by including an Authorization header field with 2152 the request. The Authorization field value consists of credentials 2153 containing the authentication information of the user agent for the 2154 realm of the resource being requested. 2156 credentials = basic-credentials 2157 | ( auth-scheme #auth-param ) 2159 The domain over which credentials can be automatically applied by a 2160 user agent is determined by the protection space. If a prior 2161 request has been authorized, the same credentials may be reused for 2162 all other requests within that protection space for a period of 2163 time determined by the authentication scheme, parameters, and/or 2164 user preference. Unless otherwise defined by the authentication 2165 scheme, a single protection space cannot extend outside the scope 2166 of its server. 2168 If the server does not wish to accept the credentials sent with a 2169 request, it should return a 403 (forbidden) response. 2171 The HTTP protocol does not restrict applications to this simple 2172 challenge-response mechanism for access authentication. Additional 2173 mechanisms may be used at the transport level, via message 2174 encapsulation, and/or with additional header fields specifying 2175 authentication information. However, these additional mechanisms 2176 are not defined by this specification. 2178 Proxies must be completely transparent regarding user agent 2179 authentication. That is, they must forward the WWW-Authenticate and 2180 Authorization headers untouched, and must not cache the response to 2181 a request containing Authorization. HTTP/1.0 does not provide a 2182 means for a client to be authenticated with a proxy. 2184 9.1 Basic Authentication Scheme 2186 The "basic" authentication scheme is based on the model that the 2187 user agent must authenticate itself with a user-ID and a password 2188 for each realm. The realm value should be considered an opaque 2189 string which can only be compared for equality with other realms on 2190 that server. The server will authorize the request only if it can 2191 validate the user-ID and password for the protection space of the 2192 Request-URI. There are no optional authentication parameters. 2194 Upon receipt of an unauthorized request for a URI within the 2195 protection space, the server should respond with a challenge like 2196 the following: 2198 WWW-Authenticate: Basic realm="WallyWorld" 2200 where "WallyWorld" is the string assigned by the server to identify 2201 the protection space of the Request-URI. 2203 To receive authorization, the client sends the user-ID and 2204 password, separated by a single colon (":") character, within a 2205 base64 [5] encoded string in the credentials. 2207 basic-credentials = "Basic" SP basic-cookie 2209 basic-cookie = 2212 userid-password = [ token ] ":" *text 2214 If the user agent wishes to send the user-ID "Aladdin" and password 2215 "open sesame", it would use the following header field: 2217 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 2219 The basic authentication scheme is a non-secure method of filtering 2220 unauthorized access to resources on an HTTP server. It is based on 2221 the assumption that the connection between the client and the 2222 server can be regarded as a trusted carrier. As this is not 2223 generally true on an open network, the basic authentication scheme 2224 should be used accordingly. In spite of this, clients are 2225 encouraged to implement the scheme in order to communicate with 2226 servers that use it. 2228 10. Security Considerations 2230 This section is meant to inform application developers, information 2231 providers, and users of the security limitations in HTTP/1.0 as 2232 described by this document. The discussion does not include 2233 definitive solutions to the problems revealed, though it does make 2234 some suggestions for reducing security risks. 2236 10.1 Authentication of Clients 2238 As mentioned in Section 9.1, the Basic authentication scheme is not 2239 a secure method of user authentication, nor does it prevent the 2240 Entity-Body from being transmitted in clear text across the 2241 physical network used as the carrier. HTTP/1.0 does not prevent 2242 additional authentication schemes and encryption mechanisms from 2243 being employed to increase security. 2245 10.2 Safe Methods 2247 The writers of client software should be aware that the software 2248 represents the user in their interactions over the Internet, and 2249 should be careful to allow the user to be aware of any actions they 2250 may take which may have an unexpected significance to themselves or 2251 others. 2253 In particular, the convention has been established that the GET and 2254 HEAD methods should never have the significance of taking an action 2255 other than retrieval. These methods should be considered "safe." 2256 This allows user agents to represent other methods, such as POST, 2257 in a special way, so that the user is made aware of the fact that a 2258 possibly unsafe action is being requested. 2260 Naturally, it is not possible to ensure that the server does not 2261 generate side-effects as a result of performing a GET request; in 2262 fact, some dynamic resources consider that a feature. The important 2263 distinction here is that the user did not request the side-effects, 2264 so therefore cannot be held accountable for them. 2266 10.3 Abuse of Server Log Information 2268 A server is in the position to save personal data about a user's 2269 requests which may identify their reading patterns or subjects of 2270 interest. This information is clearly confidential in nature and 2271 its handling may be constrained by law in certain countries. People 2272 using the HTTP protocol to provide data are responsible for 2273 ensuring that such material is not distributed without the 2274 permission of any individuals that are identifiable by the 2275 published results. 2277 10.4 Transfer of Sensitive Information 2279 Like any generic data transfer protocol, HTTP cannot regulate the 2280 content of the data that is transferred, nor is there any a priori 2281 method of determining the sensitivity of any particular piece of 2282 information within the context of any given request. Therefore, 2283 applications are encouraged to supply as much control over this 2284 information as possible to the provider of that information. Three 2285 header fields are worth special mention in this context: Server, 2286 Referer and From. 2288 Revealing the specific software version of the server may allow the 2289 server machine to become more vulnerable to attacks against 2290 software that is known to contain security holes. Implementors are 2291 encouraged to make the Server header field a configurable option. 2293 The Referer field allows reading patterns to be studied and reverse 2294 links drawn. Although it can be very useful, its power can be 2295 abused if user details are not separated from the information 2296 contained in the Referer. Even when the personal information has 2297 been removed, the Referer field may indicate a private document's 2298 URI whose publication would be inappropriate. 2300 The information sent in the From field might conflict with the 2301 user's privacy interests or their site's security policy, and hence 2302 it should not be transmitted without the user being able to 2303 disable, enable, and modify the contents of the field. The user 2304 must be able to set the contents of this field within a user 2305 preference or application defaults configuration. 2307 We suggest, though do not require, that a convenient toggle 2308 interface be provided for the user to enable or disable the sending 2309 of From and Referer information. 2311 11. Acknowledgments 2313 This specification makes heavy use of the augmented BNF and generic 2314 constructs defined by David H. Crocker for RFC 822 [7]. Similarly, 2315 it reuses many of the definitions provided by Nathaniel Borenstein 2316 and Ned Freed for MIME [5]. We hope that their inclusion in this 2317 specification will help reduce past confusion over the relationship 2318 between HTTP/1.0 and Internet mail message formats. 2320 The HTTP protocol has evolved considerably over the past three 2321 years. It has benefited from a large and active developer 2322 community--the many people who have participated on the www-talk 2323 mailing list--and it is that community which has been most 2324 responsible for the success of HTTP and of the World-Wide Web in 2325 general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, 2326 Bob Denny, Jean Francois-Groff, Phillip M. Hallam-Baker, 2327 Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, 2328 Tony Sanders, and Marc VanHeyningen deserve special recognition for 2329 their efforts in defining aspects of the protocol for early versions 2330 of this specification. 2332 This document has benefited greatly from the comments of all those 2333 participating in the HTTP-WG. In addition to those already 2334 mentioned, the following individuals have contributed to this 2335 specification: 2337 Gary Adams Harald Tveit Alvestrand 2338 Keith Ball Brian Behlendorf 2339 Paul Burchard Maurizio Codogno 2340 Mike Cowlishaw Roman Czyborra 2341 Michael A. Dolan John Franks 2342 Jim Gettys Marc Hedlund 2343 Koen Holtman Alex Hopmann 2344 Bob Jernigan Shel Kaphan 2345 Martijn Koster Dave Kristol 2346 Daniel LaLiberte Paul Leach 2347 Albert Lunde John C. Mallery 2348 Larry Masinter Mitra 2349 Gavin Nicol Bill Perry 2350 Jeffrey Perry Owen Rees 2351 David Robinson Marc Salomon 2352 Rich Salz Jim Seidman 2353 Chuck Shotton Eric W. Sink 2354 Simon E. Spero Robert S. Thau 2355 Francois Yergeau Mary Ellen Zurko 2357 12. References 2359 [1] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey, 2360 and B. Alberti. "The Internet Gopher Protocol: A distributed 2361 document search and retrieval protocol." RFC 1436, University 2362 of Minnesota, March 1993. 2364 [2] T. Berners-Lee. "Universal Resource Identifiers in WWW: 2365 A Unifying Syntax for the Expression of Names and Addresses of 2366 Objects on the Network as used in the World-Wide Web." 2367 RFC 1630, CERN, June 1994. 2369 [3] T. Berners-Lee and D. Connolly. "HyperText Markup Language 2370 Specification - 2.0." Work in Progress 2371 (draft-ietf-html-spec-05.txt), MIT/W3C, August 1995. 2373 [4] T. Berners-Lee, L. Masinter, and M. McCahill. "Uniform Resource 2374 Locators (URL)." RFC 1738, CERN, Xerox PARC, University of 2375 Minnesota, December 1994. 2377 [5] N. Borenstein and N. Freed. "MIME (Multipurpose Internet Mail 2378 Extensions) Part One: Mechanisms for Specifying and Describing 2379 the Format of Internet Message Bodies." RFC 1521, Bellcore, 2380 Innosoft, September 1993. 2382 [6] R. Braden. "Requirements for Internet hosts - application and 2383 support." STD 3, RFC 1123, IETF, October 1989. 2385 [7] D. H. Crocker. "Standard for the Format of ARPA Internet Text 2386 Messages." STD 11, RFC 822, UDEL, August 1982. 2388 [8] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang, 2389 J. Sui, and M. Grinbaum. "WAIS Interface Protocol Prototype 2390 Functional Specification." (v1.5), Thinking Machines 2391 Corporation, April 1990. 2393 [9] R. Fielding. "Relative Uniform Resource Locators." RFC 1808, 2394 UC Irvine, June 1995. 2396 [10] M. Horton and R. Adams. "Standard for interchange of USENET 2397 messages." RFC 1036 (Obsoletes RFC 850), AT&T Bell 2398 Laboratories, Center for Seismic Studies, December 1987. 2400 [11] B. Kantor and P. Lapsley. "Network News Transfer Protocol: 2401 A Proposed Standard for the Stream-Based Transmission of News." 2402 RFC 977, UC San Diego, UC Berkeley, February 1986. 2404 [12] J. Postel. "Simple Mail Transfer Protocol." STD 10, RFC 821, 2405 USC/ISI, August 1982. 2407 [13] J. Postel. "Media Type Registration Procedure." RFC 1590, 2408 USC/ISI, March 1994. 2410 [14] J. Postel and J. K. Reynolds. "File Transfer Protocol (FTP)." 2411 STD 9, RFC 959, USC/ISI, October 1985. 2413 [15] J. Reynolds and J. Postel. "Assigned Numbers." STD 2, RFC 1700, 2414 USC/ISI, October 1994. 2416 [16] K. Sollins and L. Masinter. "Functional Requirements for 2417 Uniform Resource Names." RFC 1737, MIT/LCS, Xerox Corporation, 2418 December 1994. 2420 [17] US-ASCII. Coded Character Set - 7-Bit American Standard Code 2421 for Information Interchange. Standard ANSI X3.4-1986, ANSI, 2422 1986. 2424 [18] ISO-8859. International Standard -- Information Processing -- 2425 8-bit Single-Byte Coded Graphic Character Sets -- 2426 Part 1: Latin Alphabet No. 1, ISO 8859-1:1987. 2427 Part 2: Latin alphabet No. 2, ISO 8859-2, 1987. 2428 Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. 2429 Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. 2430 Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. 2431 Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987. 2432 Part 7: Latin/Greek alphabet, ISO 8859-7, 1987. 2433 Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. 2434 Part 9: Latin alphabet No. 5, ISO 8859-9, 1990. 2436 13. Authors' Addresses 2438 Tim Berners-Lee 2439 Director, W3 Consortium 2440 MIT Laboratory for Computer Science 2441 545 Technology Square 2442 Cambridge, MA 02139, U.S.A. 2443 Tel: +1 (617) 253 5702 2444 Fax: +1 (617) 258 8682 2445 Email: timbl@w3.org 2447 Roy T. Fielding 2448 Department of Information and Computer Science 2449 University of California 2450 Irvine, CA 92717-3425, U.S.A. 2451 Tel: +1 (714) 824-4049 2452 Fax: +1 (714) 824-4056 2453 Email: fielding@ics.uci.edu 2455 Henrik Frystyk Nielsen 2456 W3 Consortium 2457 MIT Laboratory for Computer Science 2458 545 Technology Square 2459 Cambridge, MA 02139, U.S.A. 2460 Tel: +1 (617) 258 8143 2461 Fax: +1 (617) 258 8682 2462 Email: frystyk@w3.org 2464 Appendices 2466 These appendices are provided for informational reasons only -- they 2467 do not form a part of the HTTP/1.0 specification. 2469 A. Internet Media Type message/http 2471 In addition to defining the HTTP/1.0 protocol, this document serves 2472 as the specification for the Internet media type "message/http". 2473 The following is to be registered with IANA [13]. 2475 Media Type name: message 2477 Media subtype name: http 2479 Required parameters: none 2481 Optional parameters: version, msgtype 2483 version: The HTTP-Version number of the enclosed message 2484 (e.g., "1.0"). If not present, the version can be 2485 determined from the first line of the body. 2487 msgtype: The message type -- "request" or "response". If 2488 not present, the type can be determined from the 2489 first line of the body. 2491 Encoding considerations: only "7bit", "8bit", or "binary" are 2492 permitted 2494 Security considerations: none 2496 B. Tolerant Applications 2498 Although this document specifies the requirements for the 2499 generation of HTTP/1.0 messages, not all applications will be 2500 correct in their implementation. We therefore recommend that 2501 operational applications be tolerant of deviations whenever those 2502 deviations can be interpreted unambiguously. 2504 Clients should be tolerant in parsing the StatusLine and servers 2505 tolerant when parsing the RequestLine. In particular, they should 2506 accept any amount of SP or HT characters between fields, even 2507 though only a single SP is required. 2509 The line terminator for HTTP-header fields is the sequence CRLF. 2510 However, we recommend that applications, when parsing such headers, 2511 recognize a single LF as a line terminator and ignore the leading CR. 2513 C. Relationship to MIME 2515 HTTP/1.0 reuses many of the constructs defined for Internet Mail 2516 (RFC 822 [7]) and the Multipurpose Internet Mail Extensions 2517 (MIME [5]) to allow entities to be transmitted in an open variety 2518 of representations and with extensible mechanisms. However, HTTP is 2519 not a MIME-conforming application. HTTP's performance requirements 2520 differ substantially from those of Internet mail. Since it is not 2521 limited by the restrictions of existing mail protocols and 2522 gateways, HTTP does not obey some of the constraints imposed by 2523 RFC 822 and MIME for mail transport. 2525 This appendix describes specific areas where HTTP differs from 2526 MIME. Gateways to MIME-compliant protocols must be aware of these 2527 differences and provide the appropriate conversions where necessary. 2529 C.1 Conversion to Canonical Form 2531 MIME requires that an entity be converted to canonical form prior 2532 to being transferred, as described in Appendix G of RFC 1521 [5]. 2533 Although HTTP does require media types to be transferred in 2534 canonical form, it changes the definition of "canonical form" for 2535 text-based media types as described in Section 3.6.1. 2537 C.1.1 Representation of Line Breaks 2539 MIME requires that the canonical form of any text type represent 2540 line breaks as CRLF and forbids the use of CR or LF outside of line 2541 break sequences. Since HTTP allows CRLF, bare CR, and bare LF (or 2542 the octet sequence(s) to which they would be translated for the 2543 given character set) to indicate a line break within text content, 2544 recipients of an HTTP message cannot rely upon receiving 2545 MIME-canonical line breaks in text. 2547 Where it is possible, a gateway from HTTP to a MIME-conformant 2548 protocol should translate all line breaks within text/* media types 2549 to the MIME canonical form of CRLF. However, this may be 2550 complicated by the presence of a Content-Encoding and by the fact 2551 that HTTP allows the use of some character sets which do not use 2552 octets 13 and 10 to represent CR and LF, as is the case for some 2553 multi-byte character sets. If canonicalization is performed, the 2554 Content-Length header field value must be updated to reflect the 2555 new body length. 2557 C.1.2 Default Character Set 2559 MIME requires that all subtypes of the top-level Content-Type 2560 "text" have a default character set of US-ASCII [17]. In contrast, 2561 HTTP defines the default character set for "text" to be 2562 ISO-8859-1 [18] (a superset of US-ASCII). Therefore, if a text/* 2563 media type given in the Content-Type header field does not already 2564 include an explicit charset parameter, the parameter 2566 ;charset="iso-8859-1" 2568 should be added by the gateway if the entity contains any octets 2569 greater than 127. 2571 C.2 Conversion of Date Formats 2573 HTTP/1.0 uses a restricted subset of date formats to simplify the 2574 process of date comparison. Gateways from other protocols should 2575 ensure that any Date header field present in a message conforms to 2576 one of the HTTP/1.0 formats and rewrite the date if necessary. 2578 C.3 Introduction of Content-Encoding 2580 MIME does not include any concept equivalent to HTTP's 2581 Content-Encoding header field. Since this acts as a modifier on the 2582 media type, gateways to MIME-conformant protocols must either 2583 change the value of the Content-Type header field or decode the 2584 Entity-Body before forwarding the message. 2586 Note: Some experimental applications of Content-Type for 2587 Internet mail have used a media-type parameter of 2588 ";conversions=" to perform an equivalent 2589 function as Content-Encoding. However, this parameter is not 2590 part of the MIME specification at the time of this writing. 2592 C.4 No Content-Transfer-Encoding 2594 HTTP does not use the Content-Transfer-Encoding (CTE) field of 2595 MIME. Gateways from MIME-compliant protocols must remove any 2596 non-identity CTE ("quoted-printable" or "base64") encoding prior to 2597 delivering the response message to an HTTP client. Gateways to 2598 MIME-compliant protocols are responsible for ensuring that the 2599 message is in the correct format and encoding for safe transport on 2600 that protocol, where "safe transport" is defined by the limitations 2601 of the protocol being used. At a minimum, the CTE field of 2603 Content-Transfer-Encoding: binary 2605 should be added by the gateway if it is unwilling to apply a 2606 content transfer encoding. 2608 An HTTP client may include a Content-Transfer-Encoding as an 2609 extension Entity-Header in a POST request when it knows the 2610 destination of that request is a gateway to a MIME-compliant 2611 protocol.