diff options
Diffstat (limited to 'docs/specs/rfc1945.txt')
| -rw-r--r-- | docs/specs/rfc1945.txt | 3363 |
1 files changed, 0 insertions, 3363 deletions
diff --git a/docs/specs/rfc1945.txt b/docs/specs/rfc1945.txt deleted file mode 100644 index 37f3f23c..00000000 --- a/docs/specs/rfc1945.txt +++ /dev/null @@ -1,3363 +0,0 @@ - - - - - - -Network Working Group T. Berners-Lee -Request for Comments: 1945 MIT/LCS -Category: Informational R. Fielding - UC Irvine - H. Frystyk - MIT/LCS - May 1996 - - - Hypertext Transfer Protocol -- HTTP/1.0 - -Status of This Memo - - This memo provides information for the Internet community. This memo - does not specify an Internet standard of any kind. Distribution of - this memo is unlimited. - -IESG Note: - - The IESG has concerns about this protocol, and expects this document - to be replaced relatively soon by a standards track document. - -Abstract - - The Hypertext Transfer Protocol (HTTP) is an application-level - protocol with the lightness and speed necessary for distributed, - collaborative, hypermedia information systems. It is a generic, - stateless, object-oriented protocol which can be used for many tasks, - such as name servers and distributed object management systems, - through extension of its request methods (commands). A feature of - HTTP is the typing of data representation, allowing systems to be - built independently of the data being transferred. - - HTTP has been in use by the World-Wide Web global information - initiative since 1990. This specification reflects common usage of - the protocol referred to as "HTTP/1.0". - -Table of Contents - - 1. Introduction .............................................. 4 - 1.1 Purpose .............................................. 4 - 1.2 Terminology .......................................... 4 - 1.3 Overall Operation .................................... 6 - 1.4 HTTP and MIME ........................................ 8 - 2. Notational Conventions and Generic Grammar ................ 8 - 2.1 Augmented BNF ........................................ 8 - 2.2 Basic Rules .......................................... 10 - 3. Protocol Parameters ....................................... 12 - - - -Berners-Lee, et al Informational [Page 1] - -RFC 1945 HTTP/1.0 May 1996 - - - 3.1 HTTP Version ......................................... 12 - 3.2 Uniform Resource Identifiers ......................... 14 - 3.2.1 General Syntax ................................ 14 - 3.2.2 http URL ...................................... 15 - 3.3 Date/Time Formats .................................... 15 - 3.4 Character Sets ....................................... 17 - 3.5 Content Codings ...................................... 18 - 3.6 Media Types .......................................... 19 - 3.6.1 Canonicalization and Text Defaults ............ 19 - 3.6.2 Multipart Types ............................... 20 - 3.7 Product Tokens ....................................... 20 - 4. HTTP Message .............................................. 21 - 4.1 Message Types ........................................ 21 - 4.2 Message Headers ...................................... 22 - 4.3 General Header Fields ................................ 23 - 5. Request ................................................... 23 - 5.1 Request-Line ......................................... 23 - 5.1.1 Method ........................................ 24 - 5.1.2 Request-URI ................................... 24 - 5.2 Request Header Fields ................................ 25 - 6. Response .................................................. 25 - 6.1 Status-Line .......................................... 26 - 6.1.1 Status Code and Reason Phrase ................. 26 - 6.2 Response Header Fields ............................... 28 - 7. Entity .................................................... 28 - 7.1 Entity Header Fields ................................. 29 - 7.2 Entity Body .......................................... 29 - 7.2.1 Type .......................................... 29 - 7.2.2 Length ........................................ 30 - 8. Method Definitions ........................................ 30 - 8.1 GET .................................................. 31 - 8.2 HEAD ................................................. 31 - 8.3 POST ................................................. 31 - 9. Status Code Definitions ................................... 32 - 9.1 Informational 1xx .................................... 32 - 9.2 Successful 2xx ....................................... 32 - 9.3 Redirection 3xx ...................................... 34 - 9.4 Client Error 4xx ..................................... 35 - 9.5 Server Error 5xx ..................................... 37 - 10. Header Field Definitions .................................. 37 - 10.1 Allow ............................................... 38 - 10.2 Authorization ....................................... 38 - 10.3 Content-Encoding .................................... 39 - 10.4 Content-Length ...................................... 39 - 10.5 Content-Type ........................................ 40 - 10.6 Date ................................................ 40 - 10.7 Expires ............................................. 41 - 10.8 From ................................................ 42 - - - -Berners-Lee, et al Informational [Page 2] - -RFC 1945 HTTP/1.0 May 1996 - - - 10.9 If-Modified-Since ................................... 42 - 10.10 Last-Modified ....................................... 43 - 10.11 Location ............................................ 44 - 10.12 Pragma .............................................. 44 - 10.13 Referer ............................................. 44 - 10.14 Server .............................................. 45 - 10.15 User-Agent .......................................... 46 - 10.16 WWW-Authenticate .................................... 46 - 11. Access Authentication ..................................... 47 - 11.1 Basic Authentication Scheme ......................... 48 - 12. Security Considerations ................................... 49 - 12.1 Authentication of Clients ........................... 49 - 12.2 Safe Methods ........................................ 49 - 12.3 Abuse of Server Log Information ..................... 50 - 12.4 Transfer of Sensitive Information ................... 50 - 12.5 Attacks Based On File and Path Names ................ 51 - 13. Acknowledgments ........................................... 51 - 14. References ................................................ 52 - 15. Authors' Addresses ........................................ 54 - Appendix A. Internet Media Type message/http ................ 55 - Appendix B. Tolerant Applications ........................... 55 - Appendix C. Relationship to MIME ............................ 56 - C.1 Conversion to Canonical Form ......................... 56 - C.2 Conversion of Date Formats ........................... 57 - C.3 Introduction of Content-Encoding ..................... 57 - C.4 No Content-Transfer-Encoding ......................... 57 - C.5 HTTP Header Fields in Multipart Body-Parts ........... 57 - Appendix D. Additional Features ............................. 57 - D.1 Additional Request Methods ........................... 58 - D.1.1 PUT ........................................... 58 - D.1.2 DELETE ........................................ 58 - D.1.3 LINK .......................................... 58 - D.1.4 UNLINK ........................................ 58 - D.2 Additional Header Field Definitions .................. 58 - D.2.1 Accept ........................................ 58 - D.2.2 Accept-Charset ................................ 59 - D.2.3 Accept-Encoding ............................... 59 - D.2.4 Accept-Language ............................... 59 - D.2.5 Content-Language .............................. 59 - D.2.6 Link .......................................... 59 - D.2.7 MIME-Version .................................. 59 - D.2.8 Retry-After ................................... 60 - D.2.9 Title ......................................... 60 - D.2.10 URI ........................................... 60 - - - - - - - -Berners-Lee, et al Informational [Page 3] - -RFC 1945 HTTP/1.0 May 1996 - - -1. Introduction - -1.1 Purpose - - The Hypertext Transfer Protocol (HTTP) is an application-level - protocol with the lightness and speed necessary for distributed, - collaborative, hypermedia information systems. HTTP has been in use - by the World-Wide Web global information initiative since 1990. This - specification reflects common usage of the protocol referred too as - "HTTP/1.0". This specification describes the features that seem to be - consistently implemented in most HTTP/1.0 clients and servers. The - specification is split into two sections. Those features of HTTP for - which implementations are usually consistent are described in the - main body of this document. Those features which have few or - inconsistent implementations are listed in Appendix D. - - Practical information systems require more functionality than simple - retrieval, including search, front-end update, and annotation. HTTP - allows an open-ended set of methods to be used to indicate the - purpose of a request. It builds on the discipline of reference - provided by the Uniform Resource Identifier (URI) [2], as a location - (URL) [4] or name (URN) [16], for indicating the resource on which a - method is to be applied. Messages are passed in a format similar to - that used by Internet Mail [7] and the Multipurpose Internet Mail - Extensions (MIME) [5]. - - HTTP is also used as a generic protocol for communication between - user agents and proxies/gateways to other Internet protocols, such as - SMTP [12], NNTP [11], FTP [14], Gopher [1], and WAIS [8], allowing - basic hypermedia access to resources available from diverse - applications and simplifying the implementation of user agents. - -1.2 Terminology - - This specification uses a number of terms to refer to the roles - played by participants in, and objects of, the HTTP communication. - - connection - - A transport layer virtual circuit established between two - application programs for the purpose of communication. - - message - - The basic unit of HTTP communication, consisting of a structured - sequence of octets matching the syntax defined in Section 4 and - transmitted via the connection. - - - - -Berners-Lee, et al Informational [Page 4] - -RFC 1945 HTTP/1.0 May 1996 - - - request - - An HTTP request message (as defined in Section 5). - - response - - An HTTP response message (as defined in Section 6). - - resource - - A network data object or service which can be identified by a - URI (Section 3.2). - - entity - - A particular representation or rendition of a data resource, or - reply from a service resource, that may be enclosed within a - request or response message. An entity consists of - metainformation in the form of entity headers and content in the - form of an entity body. - - client - - An application program that establishes connections for the - purpose of sending requests. - - user agent - - The client which initiates a request. These are often browsers, - editors, spiders (web-traversing robots), or other end user - tools. - - server - - An application program that accepts connections in order to - service requests by sending back responses. - - origin server - - The server on which a given resource resides or is to be created. - - proxy - - An intermediary program which acts as both a server and a client - for the purpose of making requests on behalf of other clients. - Requests are serviced internally or by passing them, with - possible translation, on to other servers. A proxy must - interpret and, if necessary, rewrite a request message before - - - -Berners-Lee, et al Informational [Page 5] - -RFC 1945 HTTP/1.0 May 1996 - - - forwarding it. Proxies are often used as client-side portals - through network firewalls and as helper applications for - handling requests via protocols not implemented by the user - agent. - - gateway - - A server which acts as an intermediary for some other server. - Unlike a proxy, a gateway receives requests as if it were the - origin server for the requested resource; the requesting client - may not be aware that it is communicating with a gateway. - Gateways are often used as server-side portals through network - firewalls and as protocol translators for access to resources - stored on non-HTTP systems. - - tunnel - - A tunnel is an intermediary program which is acting as a blind - relay between two connections. Once active, a tunnel is not - considered a party to the HTTP communication, though the tunnel - may have been initiated by an HTTP request. The tunnel ceases to - exist when both ends of the relayed connections are closed. - Tunnels are used when a portal is necessary and the intermediary - cannot, or should not, interpret the relayed communication. - - cache - - A program's local store of response messages and the subsystem - that controls its message storage, retrieval, and deletion. A - cache stores cachable responses in order to reduce the response - time and network bandwidth consumption on future, equivalent - requests. Any client or server may include a cache, though a - cache cannot be used by a server while it is acting as a tunnel. - - Any given program may be capable of being both a client and a server; - our use of these terms refers only to the role being performed by the - program for a particular connection, rather than to the program's - capabilities in general. Likewise, any server may act as an origin - server, proxy, gateway, or tunnel, switching behavior based on the - nature of each request. - -1.3 Overall Operation - - The HTTP protocol is based on a request/response paradigm. A client - establishes a connection with a server and sends a request to the - server in the form of a request method, URI, and protocol version, - followed by a MIME-like message containing request modifiers, client - information, and possible body content. The server responds with a - - - -Berners-Lee, et al Informational [Page 6] - -RFC 1945 HTTP/1.0 May 1996 - - - status line, including the message's protocol version and a success - or error code, followed by a MIME-like message containing server - information, entity metainformation, and possible body content. - - Most HTTP communication is initiated by a user agent and consists of - a request to be applied to a resource on some origin server. In the - simplest case, this may be accomplished via a single connection (v) - between the user agent (UA) and the origin server (O). - - request chain ------------------------> - UA -------------------v------------------- O - <----------------------- response chain - - A more complicated situation occurs when one or more intermediaries - are present in the request/response chain. There are three common - forms of intermediary: proxy, gateway, and tunnel. A proxy is a - forwarding agent, receiving requests for a URI in its absolute form, - rewriting all or parts of the message, and forwarding the reformatted - request toward the server identified by the URI. A gateway is a - receiving agent, acting as a layer above some other server(s) and, if - necessary, translating the requests to the underlying server's - protocol. A tunnel acts as a relay point between two connections - without changing the messages; tunnels are used when the - communication needs to pass through an intermediary (such as a - firewall) even when the intermediary cannot understand the contents - of the messages. - - request chain --------------------------------------> - UA -----v----- A -----v----- B -----v----- C -----v----- O - <------------------------------------- response chain - - The figure above shows three intermediaries (A, B, and C) between the - user agent and origin server. A request or response message that - travels the whole chain must pass through four separate connections. - This distinction is important because some HTTP communication options - may apply only to the connection with the nearest, non-tunnel - neighbor, only to the end-points of the chain, or to all connections - along the chain. Although the diagram is linear, each participant may - be engaged in multiple, simultaneous communications. For example, B - may be receiving requests from many clients other than A, and/or - forwarding requests to servers other than C, at the same time that it - is handling A's request. - - Any party to the communication which is not acting as a tunnel may - employ an internal cache for handling requests. The effect of a cache - is that the request/response chain is shortened if one of the - participants along the chain has a cached response applicable to that - request. The following illustrates the resulting chain if B has a - - - -Berners-Lee, et al Informational [Page 7] - -RFC 1945 HTTP/1.0 May 1996 - - - cached copy of an earlier response from O (via C) for a request which - has not been cached by UA or A. - - request chain ----------> - UA -----v----- A -----v----- B - - - - - - C - - - - - - O - <--------- response chain - - Not all responses are cachable, and some requests may contain - modifiers which place special requirements on cache behavior. Some - HTTP/1.0 applications use heuristics to describe what is or is not a - "cachable" response, but these rules are not standardized. - - On the Internet, HTTP communication generally takes place over TCP/IP - connections. The default port is TCP 80 [15], but other ports can be - used. This does not preclude HTTP from being implemented on top of - any other protocol on the Internet, or on other networks. HTTP only - presumes a reliable transport; any protocol that provides such - guarantees can be used, and the mapping of the HTTP/1.0 request and - response structures onto the transport data units of the protocol in - question is outside the scope of this specification. - - Except for experimental applications, current practice requires that - the connection be established by the client prior to each request and - closed by the server after sending the response. Both clients and - servers should be aware that either party may close the connection - prematurely, due to user action, automated time-out, or program - failure, and should handle such closing in a predictable fashion. In - any case, the closing of the connection by either or both parties - always terminates the current request, regardless of its status. - -1.4 HTTP and MIME - - HTTP/1.0 uses many of the constructs defined for MIME, as defined in - RFC 1521 [5]. Appendix C describes the ways in which the context of - HTTP allows for different use of Internet Media Types than is - typically found in Internet mail, and gives the rationale for those - differences. - -2. Notational Conventions and Generic Grammar - -2.1 Augmented BNF - - All of the mechanisms specified in this document are described in - both prose and an augmented Backus-Naur Form (BNF) similar to that - used by RFC 822 [7]. Implementors will need to be familiar with the - notation in order to understand this specification. The augmented BNF - includes the following constructs: - - - - -Berners-Lee, et al Informational [Page 8] - -RFC 1945 HTTP/1.0 May 1996 - - - name = definition - - The name of a rule is simply the name itself (without any - enclosing "<" and ">") and is separated from its definition by - the equal character "=". Whitespace is only significant in that - indentation of continuation lines is used to indicate a rule - definition that spans more than one line. Certain basic rules - are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. - Angle brackets are used within definitions whenever their - presence will facilitate discerning the use of rule names. - - "literal" - - Quotation marks surround literal text. Unless stated otherwise, - the text is case-insensitive. - - rule1 | rule2 - - Elements separated by a bar ("I") are alternatives, - e.g., "yes | no" will accept yes or no. - - (rule1 rule2) - - Elements enclosed in parentheses are treated as a single - element. Thus, "(elem (foo | bar) elem)" allows the token - sequences "elem foo elem" and "elem bar elem". - - *rule - - The character "*" preceding an element indicates repetition. The - full form is "<n>*<m>element" indicating at least <n> and at - most <m> occurrences of element. Default values are 0 and - infinity so that "*(element)" allows any number, including zero; - "1*element" requires at least one; and "1*2element" allows one - or two. - - [rule] - - Square brackets enclose optional elements; "[foo bar]" is - equivalent to "*1(foo bar)". - - N rule - - Specific repetition: "<n>(element)" is equivalent to - "<n>*<n>(element)"; that is, exactly <n> occurrences of - (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a - string of three alphabetic characters. - - - - -Berners-Lee, et al Informational [Page 9] - -RFC 1945 HTTP/1.0 May 1996 - - - #rule - - A construct "#" is defined, similar to "*", for defining lists - of elements. The full form is "<n>#<m>element" indicating at - least <n> and at most <m> elements, each separated by one or - more commas (",") and optional linear whitespace (LWS). This - makes the usual form of lists very easy; a rule such as - "( *LWS element *( *LWS "," *LWS element ))" can be shown as - "1#element". Wherever this construct is used, null elements are - allowed, but do not contribute to the count of elements present. - That is, "(element), , (element)" is permitted, but counts as - only two elements. Therefore, where at least one element is - required, at least one non-null element must be present. Default - values are 0 and infinity so that "#(element)" allows any - number, including zero; "1#element" requires at least one; and - "1#2element" allows one or two. - - ; comment - - A semi-colon, set off some distance to the right of rule text, - starts a comment that continues to the end of line. This is a - simple way of including useful notes in parallel with the - specifications. - - implied *LWS - - The grammar described by this specification is word-based. - Except where noted otherwise, linear whitespace (LWS) can be - included between any two adjacent words (token or - quoted-string), and between adjacent tokens and delimiters - (tspecials), without changing the interpretation of a field. At - least one delimiter (tspecials) must exist between any two - tokens, since they would otherwise be interpreted as a single - token. However, applications should attempt to follow "common - form" when generating HTTP constructs, since there exist some - implementations that fail to accept anything beyond the common - forms. - -2.2 Basic Rules - - The following rules are used throughout this specification to - describe basic parsing constructs. The US-ASCII coded character set - is defined by [17]. - - OCTET = <any 8-bit sequence of data> - CHAR = <any US-ASCII character (octets 0 - 127)> - UPALPHA = <any US-ASCII uppercase letter "A".."Z"> - LOALPHA = <any US-ASCII lowercase letter "a".."z"> - - - -Berners-Lee, et al Informational [Page 10] - -RFC 1945 HTTP/1.0 May 1996 - - - ALPHA = UPALPHA | LOALPHA - DIGIT = <any US-ASCII digit "0".."9"> - CTL = <any US-ASCII control character - (octets 0 - 31) and DEL (127)> - CR = <US-ASCII CR, carriage return (13)> - LF = <US-ASCII LF, linefeed (10)> - SP = <US-ASCII SP, space (32)> - HT = <US-ASCII HT, horizontal-tab (9)> - <"> = <US-ASCII double-quote mark (34)> - - HTTP/1.0 defines the octet sequence CR LF as the end-of-line marker - for all protocol elements except the Entity-Body (see Appendix B for - tolerant applications). The end-of-line marker within an Entity-Body - is defined by its associated media type, as described in Section 3.6. - - CRLF = CR LF - - HTTP/1.0 headers may be folded onto multiple lines if each - continuation line begins with a space or horizontal tab. All linear - whitespace, including folding, has the same semantics as SP. - - LWS = [CRLF] 1*( SP | HT ) - - However, folding of header lines is not expected by some - applications, and should not be generated by HTTP/1.0 applications. - - The TEXT rule is only used for descriptive field contents and values - that are not intended to be interpreted by the message parser. Words - of *TEXT may contain octets from character sets other than US-ASCII. - - TEXT = <any OCTET except CTLs, - but including LWS> - - Recipients of header field TEXT containing octets outside the US- - ASCII character set may assume that they represent ISO-8859-1 - characters. - - Hexadecimal numeric characters are used in several protocol elements. - - HEX = "A" | "B" | "C" | "D" | "E" | "F" - | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT - - Many HTTP/1.0 header field values consist of words separated by LWS - or special characters. These special characters must be in a quoted - string to be used within a parameter value. - - word = token | quoted-string - - - - -Berners-Lee, et al Informational [Page 11] - -RFC 1945 HTTP/1.0 May 1996 - - - token = 1*<any CHAR except CTLs or tspecials> - - tspecials = "(" | ")" | "<" | ">" | "@" - | "," | ";" | ":" | "\" | <"> - | "/" | "[" | "]" | "?" | "=" - | "{" | "}" | SP | HT - - Comments may be included in some HTTP header fields by surrounding - the comment text with parentheses. Comments are only allowed in - fields containing "comment" as part of their field value definition. - In all other fields, parentheses are considered part of the field - value. - - comment = "(" *( ctext | comment ) ")" - ctext = <any TEXT excluding "(" and ")"> - - A string of text is parsed as a single word if it is quoted using - double-quote marks. - - quoted-string = ( <"> *(qdtext) <"> ) - - qdtext = <any CHAR except <"> and CTLs, - but including LWS> - - Single-character quoting using the backslash ("\") character is not - permitted in HTTP/1.0. - -3. Protocol Parameters - -3.1 HTTP Version - - HTTP uses a "<major>.<minor>" numbering scheme to indicate versions - of the protocol. The protocol versioning policy is intended to allow - the sender to indicate the format of a message and its capacity for - understanding further HTTP communication, rather than the features - obtained via that communication. No change is made to the version - number for the addition of message components which do not affect - communication behavior or which only add to extensible field values. - The <minor> number is incremented when the changes made to the - protocol add features which do not change the general message parsing - algorithm, but which may add to the message semantics and imply - additional capabilities of the sender. The <major> number is - incremented when the format of a message within the protocol is - changed. - - The version of an HTTP message is indicated by an HTTP-Version field - in the first line of the message. If the protocol version is not - specified, the recipient must assume that the message is in the - - - -Berners-Lee, et al Informational [Page 12] - -RFC 1945 HTTP/1.0 May 1996 - - - simple HTTP/0.9 format. - - HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT - - Note that the major and minor numbers should be treated as separate - integers and that each may be incremented higher than a single digit. - Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is - lower than HTTP/12.3. Leading zeros should be ignored by recipients - and never generated by senders. - - This document defines both the 0.9 and 1.0 versions of the HTTP - protocol. Applications sending Full-Request or Full-Response - messages, as defined by this specification, must include an HTTP- - Version of "HTTP/1.0". - - HTTP/1.0 servers must: - - o recognize the format of the Request-Line for HTTP/0.9 and - HTTP/1.0 requests; - - o understand any valid request in the format of HTTP/0.9 or - HTTP/1.0; - - o respond appropriately with a message in the same protocol - version used by the client. - - HTTP/1.0 clients must: - - o recognize the format of the Status-Line for HTTP/1.0 responses; - - o understand any valid response in the format of HTTP/0.9 or - HTTP/1.0. - - Proxy and gateway applications must be careful in forwarding requests - that are received in a format different than that of the - application's native HTTP version. Since the protocol version - indicates the protocol capability of the sender, a proxy/gateway must - never send a message with a version indicator which is greater than - its native version; if a higher version request is received, the - proxy/gateway must either downgrade the request version or respond - with an error. Requests with a version lower than that of the - application's native format may be upgraded before being forwarded; - the proxy/gateway's response to that request must follow the server - requirements listed above. - - - - - - - -Berners-Lee, et al Informational [Page 13] - -RFC 1945 HTTP/1.0 May 1996 - - -3.2 Uniform Resource Identifiers - - URIs have been known by many names: WWW addresses, Universal Document - Identifiers, Universal Resource Identifiers [2], and finally the - combination of Uniform Resource Locators (URL) [4] and Names (URN) - [16]. As far as HTTP is concerned, Uniform Resource Identifiers are - simply formatted strings which identify--via name, location, or any - other characteristic--a network resource. - -3.2.1 General Syntax - - URIs in HTTP can be represented in absolute form or relative to some - known base URI [9], depending upon the context of their use. The two - forms are differentiated by the fact that absolute URIs always begin - with a scheme name followed by a colon. - - URI = ( absoluteURI | relativeURI ) [ "#" fragment ] - - absoluteURI = scheme ":" *( uchar | reserved ) - - relativeURI = net_path | abs_path | rel_path - - net_path = "//" net_loc [ abs_path ] - abs_path = "/" rel_path - rel_path = [ path ] [ ";" params ] [ "?" query ] - - path = fsegment *( "/" segment ) - fsegment = 1*pchar - segment = *pchar - - params = param *( ";" param ) - param = *( pchar | "/" ) - - scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." ) - net_loc = *( pchar | ";" | "?" ) - query = *( uchar | reserved ) - fragment = *( uchar | reserved ) - - pchar = uchar | ":" | "@" | "&" | "=" | "+" - uchar = unreserved | escape - unreserved = ALPHA | DIGIT | safe | extra | national - - escape = "%" HEX HEX - reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" - extra = "!" | "*" | "'" | "(" | ")" | "," - safe = "$" | "-" | "_" | "." - unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">" - national = <any OCTET excluding ALPHA, DIGIT, - - - -Berners-Lee, et al Informational [Page 14] - -RFC 1945 HTTP/1.0 May 1996 - - - reserved, extra, safe, and unsafe> - - For definitive information on URL syntax and semantics, see RFC 1738 - [4] and RFC 1808 [9]. The BNF above includes national characters not - allowed in valid URLs as specified by RFC 1738, since HTTP servers - are not restricted in the set of unreserved characters allowed to - represent the rel_path part of addresses, and HTTP proxies may - receive requests for URIs not defined by RFC 1738. - -3.2.2 http URL - - The "http" scheme is used to locate network resources via the HTTP - protocol. This section defines the scheme-specific syntax and - semantics for http URLs. - - http_URL = "http:" "//" host [ ":" port ] [ abs_path ] - - host = <A legal Internet host domain name - or IP address (in dotted-decimal form), - as defined by Section 2.1 of RFC 1123> - - port = *DIGIT - - If the port is empty or not given, port 80 is assumed. The semantics - are that the identified resource is located at the server listening - for TCP connections on that port of that host, and the Request-URI - for the resource is abs_path. If the abs_path is not present in the - URL, it must be given as "/" when used as a Request-URI (Section - 5.1.2). - - Note: Although the HTTP protocol is independent of the transport - layer protocol, the http URL only identifies resources by their - TCP location, and thus non-TCP resources must be identified by - some other URI scheme. - - The canonical form for "http" URLs is obtained by converting any - UPALPHA characters in host to their LOALPHA equivalent (hostnames are - case-insensitive), eliding the [ ":" port ] if the port is 80, and - replacing an empty abs_path with "/". - -3.3 Date/Time Formats - - HTTP/1.0 applications have historically allowed three different - formats for the representation of date/time stamps: - - Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 - Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 - Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format - - - -Berners-Lee, et al Informational [Page 15] - -RFC 1945 HTTP/1.0 May 1996 - - - The first format is preferred as an Internet standard and represents - a fixed-length subset of that defined by RFC 1123 [6] (an update to - RFC 822 [7]). The second format is in common use, but is based on the - obsolete RFC 850 [10] date format and lacks a four-digit year. - HTTP/1.0 clients and servers that parse the date value should accept - all three formats, though they must never generate the third - (asctime) format. - - Note: Recipients of date values are encouraged to be robust in - accepting date values that may have been generated by non-HTTP - applications, as is sometimes the case when retrieving or posting - messages via proxies/gateways to SMTP or NNTP. - - All HTTP/1.0 date/time stamps must be represented in Universal Time - (UT), also known as Greenwich Mean Time (GMT), without exception. - This is indicated in the first two formats by the inclusion of "GMT" - as the three-letter abbreviation for time zone, and should be assumed - when reading the asctime format. - - HTTP-date = rfc1123-date | rfc850-date | asctime-date - - rfc1123-date = wkday "," SP date1 SP time SP "GMT" - rfc850-date = weekday "," SP date2 SP time SP "GMT" - asctime-date = wkday SP date3 SP time SP 4DIGIT - - date1 = 2DIGIT SP month SP 4DIGIT - ; day month year (e.g., 02 Jun 1982) - date2 = 2DIGIT "-" month "-" 2DIGIT - ; day-month-year (e.g., 02-Jun-82) - date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) - ; month day (e.g., Jun 2) - - time = 2DIGIT ":" 2DIGIT ":" 2DIGIT - ; 00:00:00 - 23:59:59 - - wkday = "Mon" | "Tue" | "Wed" - | "Thu" | "Fri" | "Sat" | "Sun" - - weekday = "Monday" | "Tuesday" | "Wednesday" - | "Thursday" | "Friday" | "Saturday" | "Sunday" - - month = "Jan" | "Feb" | "Mar" | "Apr" - | "May" | "Jun" | "Jul" | "Aug" - | "Sep" | "Oct" | "Nov" | "Dec" - - Note: HTTP requirements for the date/time stamp format apply - only to their usage within the protocol stream. Clients and - servers are not required to use these formats for user - - - -Berners-Lee, et al Informational [Page 16] - -RFC 1945 HTTP/1.0 May 1996 - - - presentation, request logging, etc. - -3.4 Character Sets - - HTTP uses the same definition of the term "character set" as that - described for MIME: - - The term "character set" is used in this document to refer to a - method used with one or more tables to convert a sequence of - octets into a sequence of characters. Note that unconditional - conversion in the other direction is not required, in that not all - characters may be available in a given character set and a - character set may provide more than one sequence of octets to - represent a particular character. This definition is intended to - allow various kinds of character encodings, from simple single- - table mappings such as US-ASCII to complex table switching methods - such as those that use ISO 2022's techniques. However, the - definition associated with a MIME character set name must fully - specify the mapping to be performed from octets to characters. In - particular, use of external profiling information to determine the - exact mapping is not permitted. - - Note: This use of the term "character set" is more commonly - referred to as a "character encoding." However, since HTTP and - MIME share the same registry, it is important that the terminology - also be shared. - - HTTP character sets are identified by case-insensitive tokens. The - complete set of tokens are defined by the IANA Character Set registry - [15]. However, because that registry does not define a single, - consistent token for each character set, we define here the preferred - names for those character sets most likely to be used with HTTP - entities. These character sets include those registered by RFC 1521 - [5] -- the US-ASCII [17] and ISO-8859 [18] character sets -- and - other names specifically recommended for use within MIME charset - parameters. - - charset = "US-ASCII" - | "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3" - | "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6" - | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9" - | "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR" - | "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8" - | token - - Although HTTP allows an arbitrary token to be used as a charset - value, any token that has a predefined value within the IANA - Character Set registry [15] must represent the character set defined - - - -Berners-Lee, et al Informational [Page 17] - -RFC 1945 HTTP/1.0 May 1996 - - - by that registry. Applications should limit their use of character - sets to those defined by the IANA registry. - - The character set of an entity body should be labelled as the lowest - common denominator of the character codes used within that body, with - the exception that no label is preferred over the labels US-ASCII or - ISO-8859-1. - -3.5 Content Codings - - Content coding values are used to indicate an encoding transformation - that has been applied to a resource. Content codings are primarily - used to allow a document to be compressed or encrypted without losing - the identity of its underlying media type. Typically, the resource is - stored in this encoding and only decoded before rendering or - analogous usage. - - content-coding = "x-gzip" | "x-compress" | token - - Note: For future compatibility, HTTP/1.0 applications should - consider "gzip" and "compress" to be equivalent to "x-gzip" - and "x-compress", respectively. - - All content-coding values are case-insensitive. HTTP/1.0 uses - content-coding values in the Content-Encoding (Section 10.3) header - field. Although the value describes the content-coding, what is more - important is that it indicates what decoding mechanism will be - required to remove the encoding. Note that a single program may be - capable of decoding multiple content-coding formats. Two values are - defined by this specification: - - x-gzip - An encoding format produced by the file compression program - "gzip" (GNU zip) developed by Jean-loup Gailly. This format is - typically a Lempel-Ziv coding (LZ77) with a 32 bit CRC. - - x-compress - The encoding format produced by the file compression program - "compress". This format is an adaptive Lempel-Ziv-Welch coding - (LZW). - - Note: Use of program names for the identification of - encoding formats is not desirable and should be discouraged - for future encodings. Their use here is representative of - historical practice, not good design. - - - - - - -Berners-Lee, et al Informational [Page 18] - -RFC 1945 HTTP/1.0 May 1996 - - -3.6 Media Types - - HTTP uses Internet Media Types [13] in the Content-Type header field - (Section 10.5) in order to provide open and extensible data typing. - - media-type = type "/" subtype *( ";" parameter ) - type = token - subtype = token - - Parameters may follow the type/subtype in the form of attribute/value - pairs. - - parameter = attribute "=" value - attribute = token - value = token | quoted-string - - The type, subtype, and parameter attribute names are case- - insensitive. Parameter values may or may not be case-sensitive, - depending on the semantics of the parameter name. LWS must not be - generated between the type and subtype, nor between an attribute and - its value. Upon receipt of a media type with an unrecognized - parameter, a user agent should treat the media type as if the - unrecognized parameter and its value were not present. - - Some older HTTP applications do not recognize media type parameters. - HTTP/1.0 applications should only use media type parameters when they - are necessary to define the content of a message. - - Media-type values are registered with the Internet Assigned Number - Authority (IANA [15]). The media type registration process is - outlined in RFC 1590 [13]. Use of non-registered media types is - discouraged. - -3.6.1 Canonicalization and Text Defaults - - Internet media types are registered with a canonical form. In - general, an Entity-Body transferred via HTTP must be represented in - the appropriate canonical form prior to its transmission. If the body - has been encoded with a Content-Encoding, the underlying data should - be in canonical form prior to being encoded. - - Media subtypes of the "text" type use CRLF as the text line break - when in canonical form. However, HTTP allows the transport of text - media with plain CR or LF alone representing a line break when used - consistently within the Entity-Body. HTTP applications must accept - CRLF, bare CR, and bare LF as being representative of a line break in - text media received via HTTP. - - - - -Berners-Lee, et al Informational [Page 19] - -RFC 1945 HTTP/1.0 May 1996 - - - In addition, if the text media is represented in a character set that - does not use octets 13 and 10 for CR and LF respectively, as is the - case for some multi-byte character sets, HTTP allows the use of - whatever octet sequences are defined by that character set to - represent the equivalent of CR and LF for line breaks. This - flexibility regarding line breaks applies only to text media in the - Entity-Body; a bare CR or LF should not be substituted for CRLF - within any of the HTTP control structures (such as header fields and - multipart boundaries). - - The "charset" parameter is used with some media types to define the - character set (Section 3.4) of the data. When no explicit charset - parameter is provided by the sender, media subtypes of the "text" - type are defined to have a default charset value of "ISO-8859-1" when - received via HTTP. Data in character sets other than "ISO-8859-1" or - its subsets must be labelled with an appropriate charset value in - order to be consistently interpreted by the recipient. - - Note: Many current HTTP servers provide data using charsets other - than "ISO-8859-1" without proper labelling. This situation reduces - interoperability and is not recommended. To compensate for this, - some HTTP user agents provide a configuration option to allow the - user to change the default interpretation of the media type - character set when no charset parameter is given. - -3.6.2 Multipart Types - - MIME provides for a number of "multipart" types -- encapsulations of - several entities within a single message's Entity-Body. The multipart - types registered by IANA [15] do not have any special meaning for - HTTP/1.0, though user agents may need to understand each type in - order to correctly interpret the purpose of each body-part. An HTTP - user agent should follow the same or similar behavior as a MIME user - agent does upon receipt of a multipart type. HTTP servers should not - assume that all HTTP clients are prepared to handle multipart types. - - All multipart types share a common syntax and must include a boundary - parameter as part of the media type value. The message body is itself - a protocol element and must therefore use only CRLF to represent line - breaks between body-parts. Multipart body-parts may contain HTTP - header fields which are significant to the meaning of that part. - -3.7 Product Tokens - - Product tokens are used to allow communicating applications to - identify themselves via a simple product token, with an optional - slash and version designator. Most fields using product tokens also - allow subproducts which form a significant part of the application to - - - -Berners-Lee, et al Informational [Page 20] - -RFC 1945 HTTP/1.0 May 1996 - - - be listed, separated by whitespace. By convention, the products are - listed in order of their significance for identifying the - application. - - product = token ["/" product-version] - product-version = token - - Examples: - - User-Agent: CERN-LineMode/2.15 libwww/2.17b3 - - Server: Apache/0.8.4 - - Product tokens should be short and to the point -- use of them for - advertizing or other non-essential information is explicitly - forbidden. Although any token character may appear in a product- - version, this token should only be used for a version identifier - (i.e., successive versions of the same product should only differ in - the product-version portion of the product value). - -4. HTTP Message - -4.1 Message Types - - HTTP messages consist of requests from client to server and responses - from server to client. - - HTTP-message = Simple-Request ; HTTP/0.9 messages - | Simple-Response - | Full-Request ; HTTP/1.0 messages - | Full-Response - - Full-Request and Full-Response use the generic message format of RFC - 822 [7] for transferring entities. Both messages may include optional - header fields (also known as "headers") and an entity body. The - entity body is separated from the headers by a null line (i.e., a - line with nothing preceding the CRLF). - - Full-Request = Request-Line ; Section 5.1 - *( General-Header ; Section 4.3 - | Request-Header ; Section 5.2 - | Entity-Header ) ; Section 7.1 - CRLF - [ Entity-Body ] ; Section 7.2 - - Full-Response = Status-Line ; Section 6.1 - *( General-Header ; Section 4.3 - | Response-Header ; Section 6.2 - - - -Berners-Lee, et al Informational [Page 21] - -RFC 1945 HTTP/1.0 May 1996 - - - | Entity-Header ) ; Section 7.1 - CRLF - [ Entity-Body ] ; Section 7.2 - - Simple-Request and Simple-Response do not allow the use of any header - information and are limited to a single request method (GET). - - Simple-Request = "GET" SP Request-URI CRLF - - Simple-Response = [ Entity-Body ] - - Use of the Simple-Request format is discouraged because it prevents - the server from identifying the media type of the returned entity. - -4.2 Message Headers - - HTTP header fields, which include General-Header (Section 4.3), - Request-Header (Section 5.2), Response-Header (Section 6.2), and - Entity-Header (Section 7.1) fields, follow the same generic format as - that given in Section 3.1 of RFC 822 [7]. Each header field consists - of a name followed immediately by a colon (":"), a single space (SP) - character, and the field value. Field names are case-insensitive. - Header fields can be extended over multiple lines by preceding each - extra line with at least one SP or HT, though this is not - recommended. - - HTTP-header = field-name ":" [ field-value ] CRLF - - field-name = token - field-value = *( field-content | LWS ) - - field-content = <the OCTETs making up the field-value - and consisting of either *TEXT or combinations - of token, tspecials, and quoted-string> - - The order in which header fields are received is not significant. - However, it is "good practice" to send General-Header fields first, - followed by Request-Header or Response-Header fields prior to the - Entity-Header fields. - - Multiple HTTP-header fields with the same field-name may be present - in a message if and only if the entire field-value for that header - field is defined as a comma-separated list [i.e., #(values)]. It must - be possible to combine the multiple header fields into one "field- - name: field-value" pair, without changing the semantics of the - message, by appending each subsequent field-value to the first, each - separated by a comma. - - - - -Berners-Lee, et al Informational [Page 22] - -RFC 1945 HTTP/1.0 May 1996 - - -4.3 General Header Fields - - There are a few header fields which have general applicability for - both request and response messages, but which do not apply to the - entity being transferred. These headers apply only to the message - being transmitted. - - General-Header = Date ; Section 10.6 - | Pragma ; Section 10.12 - - General header field names can be extended reliably only in - combination with a change in the protocol version. However, new or - experimental header fields may be given the semantics of general - header fields if all parties in the communication recognize them to - be general header fields. Unrecognized header fields are treated as - Entity-Header fields. - -5. Request - - A request message from a client to a server includes, within the - first line of that message, the method to be applied to the resource, - the identifier of the resource, and the protocol version in use. For - backwards compatibility with the more limited HTTP/0.9 protocol, - there are two valid formats for an HTTP request: - - Request = Simple-Request | Full-Request - - Simple-Request = "GET" SP Request-URI CRLF - - Full-Request = Request-Line ; Section 5.1 - *( General-Header ; Section 4.3 - | Request-Header ; Section 5.2 - | Entity-Header ) ; Section 7.1 - CRLF - [ Entity-Body ] ; Section 7.2 - - If an HTTP/1.0 server receives a Simple-Request, it must respond with - an HTTP/0.9 Simple-Response. An HTTP/1.0 client capable of receiving - a Full-Response should never generate a Simple-Request. - -5.1 Request-Line - - The Request-Line begins with a method token, followed by the - Request-URI and the protocol version, and ending with CRLF. The - elements are separated by SP characters. No CR or LF are allowed - except in the final CRLF sequence. - - Request-Line = Method SP Request-URI SP HTTP-Version CRLF - - - -Berners-Lee, et al Informational [Page 23] - -RFC 1945 HTTP/1.0 May 1996 - - - Note that the difference between a Simple-Request and the Request- - Line of a Full-Request is the presence of the HTTP-Version field and - the availability of methods other than GET. - -5.1.1 Method - - The Method token indicates the method to be performed on the resource - identified by the Request-URI. The method is case-sensitive. - - Method = "GET" ; Section 8.1 - | "HEAD" ; Section 8.2 - | "POST" ; Section 8.3 - | extension-method - - extension-method = token - - The list of methods acceptable by a specific resource can change - dynamically; the client is notified through the return code of the - response if a method is not allowed on a resource. Servers should - return the status code 501 (not implemented) if the method is - unrecognized or not implemented. - - The methods commonly used by HTTP/1.0 applications are fully defined - in Section 8. - -5.1.2 Request-URI - - The Request-URI is a Uniform Resource Identifier (Section 3.2) and - identifies the resource upon which to apply the request. - - Request-URI = absoluteURI | abs_path - - The two options for Request-URI are dependent on the nature of the - request. - - The absoluteURI form is only allowed when the request is being made - to a proxy. The proxy is requested to forward the request and return - the response. If the request is GET or HEAD and a prior response is - cached, the proxy may use the cached message if it passes any - restrictions in the Expires header field. Note that the proxy may - forward the request on to another proxy or directly to the server - specified by the absoluteURI. In order to avoid request loops, a - proxy must be able to recognize all of its server names, including - any aliases, local variations, and the numeric IP address. An example - Request-Line would be: - - GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0 - - - - -Berners-Lee, et al Informational [Page 24] - -RFC 1945 HTTP/1.0 May 1996 - - - The most common form of Request-URI is that used to identify a - resource on an origin server or gateway. In this case, only the - absolute path of the URI is transmitted (see Section 3.2.1, - abs_path). For example, a client wishing to retrieve the resource - above directly from the origin server would create a TCP connection - to port 80 of the host "www.w3.org" and send the line: - - GET /pub/WWW/TheProject.html HTTP/1.0 - - followed by the remainder of the Full-Request. Note that the absolute - path cannot be empty; if none is present in the original URI, it must - be given as "/" (the server root). - - The Request-URI is transmitted as an encoded string, where some - characters may be escaped using the "% HEX HEX" encoding defined by - RFC 1738 [4]. The origin server must decode the Request-URI in order - to properly interpret the request. - -5.2 Request Header Fields - - The request header fields allow the client to pass additional - information about the request, and about the client itself, to the - server. These fields act as request modifiers, with semantics - equivalent to the parameters on a programming language method - (procedure) invocation. - - Request-Header = Authorization ; Section 10.2 - | From ; Section 10.8 - | If-Modified-Since ; Section 10.9 - | Referer ; Section 10.13 - | User-Agent ; Section 10.15 - - Request-Header field names can be extended reliably only in - combination with a change in the protocol version. However, new or - experimental header fields may be given the semantics of request - header fields if all parties in the communication recognize them to - be request header fields. Unrecognized header fields are treated as - Entity-Header fields. - -6. Response - - After receiving and interpreting a request message, a server responds - in the form of an HTTP response message. - - Response = Simple-Response | Full-Response - - Simple-Response = [ Entity-Body ] - - - - -Berners-Lee, et al Informational [Page 25] - -RFC 1945 HTTP/1.0 May 1996 - - - Full-Response = Status-Line ; Section 6.1 - *( General-Header ; Section 4.3 - | Response-Header ; Section 6.2 - | Entity-Header ) ; Section 7.1 - CRLF - [ Entity-Body ] ; Section 7.2 - - A Simple-Response should only be sent in response to an HTTP/0.9 - Simple-Request or if the server only supports the more limited - HTTP/0.9 protocol. If a client sends an HTTP/1.0 Full-Request and - receives a response that does not begin with a Status-Line, it should - assume that the response is a Simple-Response and parse it - accordingly. Note that the Simple-Response consists only of the - entity body and is terminated by the server closing the connection. - -6.1 Status-Line - - The first line of a Full-Response message is the Status-Line, - consisting of the protocol version followed by a numeric status code - and its associated textual phrase, with each element separated by SP - characters. No CR or LF is allowed except in the final CRLF sequence. - - Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF - - Since a status line always begins with the protocol version and - status code - - "HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP - - (e.g., "HTTP/1.0 200 "), the presence of that expression is - sufficient to differentiate a Full-Response from a Simple-Response. - Although the Simple-Response format may allow such an expression to - occur at the beginning of an entity body, and thus cause a - misinterpretation of the message if it was given in response to a - Full-Request, most HTTP/0.9 servers are limited to responses of type - "text/html" and therefore would never generate such a response. - -6.1.1 Status Code and Reason Phrase - - The Status-Code element is a 3-digit integer result code of the - attempt to understand and satisfy the request. The Reason-Phrase is - intended to give a short textual description of the Status-Code. The - Status-Code is intended for use by automata and the Reason-Phrase is - intended for the human user. The client is not required to examine or - display the Reason-Phrase. - - - - - - -Berners-Lee, et al Informational [Page 26] - -RFC 1945 HTTP/1.0 May 1996 - - - The first digit of the Status-Code defines the class of response. The - last two digits do not have any categorization role. There are 5 - values for the first digit: - - o 1xx: Informational - Not used, but reserved for future use - - o 2xx: Success - The action was successfully received, - understood, and accepted. - - o 3xx: Redirection - Further action must be taken in order to - complete the request - - o 4xx: Client Error - The request contains bad syntax or cannot - be fulfilled - - o 5xx: Server Error - The server failed to fulfill an apparently - valid request - - The individual values of the numeric status codes defined for - HTTP/1.0, and an example set of corresponding Reason-Phrase's, are - presented below. The reason phrases listed here are only recommended - -- they may be replaced by local equivalents without affecting the - protocol. These codes are fully defined in Section 9. - - Status-Code = "200" ; OK - | "201" ; Created - | "202" ; Accepted - | "204" ; No Content - | "301" ; Moved Permanently - | "302" ; Moved Temporarily - | "304" ; Not Modified - | "400" ; Bad Request - | "401" ; Unauthorized - | "403" ; Forbidden - | "404" ; Not Found - | "500" ; Internal Server Error - | "501" ; Not Implemented - | "502" ; Bad Gateway - | "503" ; Service Unavailable - | extension-code - - extension-code = 3DIGIT - - Reason-Phrase = *<TEXT, excluding CR, LF> - - HTTP status codes are extensible, but the above codes are the only - ones generally recognized in current practice. HTTP applications are - not required to understand the meaning of all registered status - - - -Berners-Lee, et al Informational [Page 27] - -RFC 1945 HTTP/1.0 May 1996 - - - codes, though such understanding is obviously desirable. However, - applications must understand the class of any status code, as - indicated by the first digit, and treat any unrecognized response as - being equivalent to the x00 status code of that class, with the - exception that an unrecognized response must not be cached. For - example, if an unrecognized status code of 431 is received by the - client, it can safely assume that there was something wrong with its - request and treat the response as if it had received a 400 status - code. In such cases, user agents should present to the user the - entity returned with the response, since that entity is likely to - include human-readable information which will explain the unusual - status. - -6.2 Response Header Fields - - The response header fields allow the server to pass additional - information about the response which cannot be placed in the Status- - Line. These header fields give information about the server and about - further access to the resource identified by the Request-URI. - - Response-Header = Location ; Section 10.11 - | Server ; Section 10.14 - | WWW-Authenticate ; Section 10.16 - - Response-Header field names can be extended reliably only in - combination with a change in the protocol version. However, new or - experimental header fields may be given the semantics of response - header fields if all parties in the communication recognize them to - be response header fields. Unrecognized header fields are treated as - Entity-Header fields. - -7. Entity - - Full-Request and Full-Response messages may transfer an entity within - some requests and responses. An entity consists of Entity-Header - fields and (usually) an Entity-Body. In this section, both sender and - recipient refer to either the client or the server, depending on who - sends and who receives the entity. - - - - - - - - - - - - - -Berners-Lee, et al Informational [Page 28] - -RFC 1945 HTTP/1.0 May 1996 - - -7.1 Entity Header Fields - - Entity-Header fields define optional metainformation about the - Entity-Body or, if no body is present, about the resource identified - by the request. - - Entity-Header = Allow ; Section 10.1 - | Content-Encoding ; Section 10.3 - | Content-Length ; Section 10.4 - | Content-Type ; Section 10.5 - | Expires ; Section 10.7 - | Last-Modified ; Section 10.10 - | extension-header - - extension-header = HTTP-header - - The extension-header mechanism allows additional Entity-Header fields - to be defined without changing the protocol, but these fields cannot - be assumed to be recognizable by the recipient. Unrecognized header - fields should be ignored by the recipient and forwarded by proxies. - -7.2 Entity Body - - The entity body (if any) sent with an HTTP request or response is in - a format and encoding defined by the Entity-Header fields. - - Entity-Body = *OCTET - - An entity body is included with a request message only when the - request method calls for one. The presence of an entity body in a - request is signaled by the inclusion of a Content-Length header field - in the request message headers. HTTP/1.0 requests containing an - entity body must include a valid Content-Length header field. - - For response messages, whether or not an entity body is included with - a message is dependent on both the request method and the response - code. All responses to the HEAD request method must not include a - body, even though the presence of entity header fields may lead one - to believe they do. All 1xx (informational), 204 (no content), and - 304 (not modified) responses must not include a body. All other - responses must include an entity body or a Content-Length header - field defined with a value of zero (0). - -7.2.1 Type - - When an Entity-Body is included with a message, the data type of that - body is determined via the header fields Content-Type and Content- - Encoding. These define a two-layer, ordered encoding model: - - - -Berners-Lee, et al Informational [Page 29] - -RFC 1945 HTTP/1.0 May 1996 - - - entity-body := Content-Encoding( Content-Type( data ) ) - - A Content-Type specifies the media type of the underlying data. A - Content-Encoding may be used to indicate any additional content - coding applied to the type, usually for the purpose of data - compression, that is a property of the resource requested. The - default for the content encoding is none (i.e., the identity - function). - - Any HTTP/1.0 message containing an entity body should include a - Content-Type header field defining the media type of that body. If - and only if the media type is not given by a Content-Type header, as - is the case for Simple-Response messages, the recipient may attempt - to guess the media type via inspection of its content and/or the name - extension(s) of the URL used to identify the resource. If the media - type remains unknown, the recipient should treat it as type - "application/octet-stream". - -7.2.2 Length - - When an Entity-Body is included with a message, the length of that - body may be determined in one of two ways. If a Content-Length header - field is present, its value in bytes represents the length of the - Entity-Body. Otherwise, the body length is determined by the closing - of the connection by the server. - - Closing the connection cannot be used to indicate the end of a - request body, since it leaves no possibility for the server to send - back a response. Therefore, HTTP/1.0 requests containing an entity - body must include a valid Content-Length header field. If a request - contains an entity body and Content-Length is not specified, and the - server does not recognize or cannot calculate the length from other - fields, then the server should send a 400 (bad request) response. - - Note: Some older servers supply an invalid Content-Length when - sending a document that contains server-side includes dynamically - inserted into the data stream. It must be emphasized that this - will not be tolerated by future versions of HTTP. Unless the - client knows that it is receiving a response from a compliant - server, it should not depend on the Content-Length value being - correct. - -8. Method Definitions - - The set of common methods for HTTP/1.0 is defined below. Although - this set can be expanded, additional methods cannot be assumed to - share the same semantics for separately extended clients and servers. - - - - -Berners-Lee, et al Informational [Page 30] - -RFC 1945 HTTP/1.0 May 1996 - - -8.1 GET - - The GET method means retrieve whatever information (in the form of an - entity) is identified by the Request-URI. If the Request-URI refers - to a data-producing process, it is the produced data which shall be - returned as the entity in the response and not the source text of the - process, unless that text happens to be the output of the process. - - The semantics of the GET method changes to a "conditional GET" if the - request message includes an If-Modified-Since header field. A - conditional GET method requests that the identified resource be - transferred only if it has been modified since the date given by the - If-Modified-Since header, as described in Section 10.9. The - conditional GET method is intended to reduce network usage by - allowing cached entities to be refreshed without requiring multiple - requests or transferring unnecessary data. - -8.2 HEAD - - The HEAD method is identical to GET except that the server must not - return any Entity-Body in the response. The metainformation contained - in the HTTP headers in response to a HEAD request should be identical - to the information sent in response to a GET request. This method can - be used for obtaining metainformation about the resource identified - by the Request-URI without transferring the Entity-Body itself. This - method is often used for testing hypertext links for validity, - accessibility, and recent modification. - - There is no "conditional HEAD" request analogous to the conditional - GET. If an If-Modified-Since header field is included with a HEAD - request, it should be ignored. - -8.3 POST - - The POST method is used to request that the destination server accept - the entity enclosed in the request as a new subordinate of the - resource identified by the Request-URI in the Request-Line. POST is - designed to allow a uniform method to cover the following functions: - - o Annotation of existing resources; - - o Posting a message to a bulletin board, newsgroup, mailing list, - or similar group of articles; - - o Providing a block of data, such as the result of submitting a - form [3], to a data-handling process; - - o Extending a database through an append operation. - - - -Berners-Lee, et al Informational [Page 31] - -RFC 1945 HTTP/1.0 May 1996 - - - The actual function performed by the POST method is determined by the - server and is usually dependent on the Request-URI. The posted entity - is subordinate to that URI in the same way that a file is subordinate - to a directory containing it, a news article is subordinate to a - newsgroup to which it is posted, or a record is subordinate to a - database. - - A successful POST does not require that the entity be created as a - resource on the origin server or made accessible for future - reference. That is, the action performed by the POST method might not - result in a resource that can be identified by a URI. In this case, - either 200 (ok) or 204 (no content) is the appropriate response - status, depending on whether or not the response includes an entity - that describes the result. - - If a resource has been created on the origin server, the response - should be 201 (created) and contain an entity (preferably of type - "text/html") which describes the status of the request and refers to - the new resource. - - A valid Content-Length is required on all HTTP/1.0 POST requests. An - HTTP/1.0 server should respond with a 400 (bad request) message if it - cannot determine the length of the request message's content. - - Applications must not cache responses to a POST request because the - application has no way of knowing that the server would return an - equivalent response on some future request. - -9. Status Code Definitions - - Each Status-Code is described below, including a description of which - method(s) it can follow and any metainformation required in the - response. - -9.1 Informational 1xx - - This class of status code indicates a provisional response, - consisting only of the Status-Line and optional headers, and is - terminated by an empty line. HTTP/1.0 does not define any 1xx status - codes and they are not a valid response to a HTTP/1.0 request. - However, they may be useful for experimental applications which are - outside the scope of this specification. - -9.2 Successful 2xx - - This class of status code indicates that the client's request was - successfully received, understood, and accepted. - - - - -Berners-Lee, et al Informational [Page 32] - -RFC 1945 HTTP/1.0 May 1996 - - - 200 OK - - The request has succeeded. The information returned with the - response is dependent on the method used in the request, as follows: - - GET an entity corresponding to the requested resource is sent - in the response; - - HEAD the response must only contain the header information and - no Entity-Body; - - POST an entity describing or containing the result of the action. - - 201 Created - - The request has been fulfilled and resulted in a new resource being - created. The newly created resource can be referenced by the URI(s) - returned in the entity of the response. The origin server should - create the resource before using this Status-Code. If the action - cannot be carried out immediately, the server must include in the - response body a description of when the resource will be available; - otherwise, the server should respond with 202 (accepted). - - Of the methods defined by this specification, only POST can create a - resource. - - 202 Accepted - - The request has been accepted for processing, but the processing - has not been completed. The request may or may not eventually be - acted upon, as it may be disallowed when processing actually takes - place. There is no facility for re-sending a status code from an - asynchronous operation such as this. - - The 202 response is intentionally non-committal. Its purpose is to - allow a server to accept a request for some other process (perhaps - a batch-oriented process that is only run once per day) without - requiring that the user agent's connection to the server persist - until the process is completed. The entity returned with this - response should include an indication of the request's current - status and either a pointer to a status monitor or some estimate of - when the user can expect the request to be fulfilled. - - 204 No Content - - The server has fulfilled the request but there is no new - information to send back. If the client is a user agent, it should - not change its document view from that which caused the request to - - - -Berners-Lee, et al Informational [Page 33] - -RFC 1945 HTTP/1.0 May 1996 - - - be generated. This response is primarily intended to allow input - for scripts or other actions to take place without causing a change - to the user agent's active document view. The response may include - new metainformation in the form of entity headers, which should - apply to the document currently in the user agent's active view. - -9.3 Redirection 3xx - - This class of status code indicates that further action needs to be - taken by the user agent in order to fulfill the request. The action - required may be carried out by the user agent without interaction - with the user if and only if the method used in the subsequent - request is GET or HEAD. A user agent should never automatically - redirect a request more than 5 times, since such redirections usually - indicate an infinite loop. - - 300 Multiple Choices - - This response code is not directly used by HTTP/1.0 applications, - but serves as the default for interpreting the 3xx class of - responses. - - The requested resource is available at one or more locations. - Unless it was a HEAD request, the response should include an entity - containing a list of resource characteristics and locations from - which the user or user agent can choose the one most appropriate. - If the server has a preferred choice, it should include the URL in - a Location field; user agents may use this field value for - automatic redirection. - - 301 Moved Permanently - - The requested resource has been assigned a new permanent URL and - any future references to this resource should be done using that - URL. Clients with link editing capabilities should automatically - relink references to the Request-URI to the new reference returned - by the server, where possible. - - The new URL must be given by the Location field in the response. - Unless it was a HEAD request, the Entity-Body of the response - should contain a short note with a hyperlink to the new URL. - - If the 301 status code is received in response to a request using - the POST method, the user agent must not automatically redirect the - request unless it can be confirmed by the user, since this might - change the conditions under which the request was issued. - - - - - -Berners-Lee, et al Informational [Page 34] - -RFC 1945 HTTP/1.0 May 1996 - - - Note: When automatically redirecting a POST request after - receiving a 301 status code, some existing user agents will - erroneously change it into a GET request. - - 302 Moved Temporarily - - The requested resource resides temporarily under a different URL. - Since the redirection may be altered on occasion, the client should - continue to use the Request-URI for future requests. - - The URL must be given by the Location field in the response. Unless - it was a HEAD request, the Entity-Body of the response should - contain a short note with a hyperlink to the new URI(s). - - If the 302 status code is received in response to a request using - the POST method, the user agent must not automatically redirect the - request unless it can be confirmed by the user, since this might - change the conditions under which the request was issued. - - Note: When automatically redirecting a POST request after - receiving a 302 status code, some existing user agents will - erroneously change it into a GET request. - - 304 Not Modified - - If the client has performed a conditional GET request and access is - allowed, but the document has not been modified since the date and - time specified in the If-Modified-Since field, the server must - respond with this status code and not send an Entity-Body to the - client. Header fields contained in the response should only include - information which is relevant to cache managers or which may have - changed independently of the entity's Last-Modified date. Examples - of relevant header fields include: Date, Server, and Expires. A - cache should update its cached entity to reflect any new field - values given in the 304 response. - -9.4 Client Error 4xx - - The 4xx class of status code is intended for cases in which the - client seems to have erred. If the client has not completed the - request when a 4xx code is received, it should immediately cease - sending data to the server. Except when responding to a HEAD request, - the server should include an entity containing an explanation of the - error situation, and whether it is a temporary or permanent - condition. These status codes are applicable to any request method. - - - - - - -Berners-Lee, et al Informational [Page 35] - -RFC 1945 HTTP/1.0 May 1996 - - - Note: If the client is sending data, server implementations on TCP - should be careful to ensure that the client acknowledges receipt - of the packet(s) containing the response prior to closing the - input connection. If the client continues sending data to the - server after the close, the server's controller will send a reset - packet to the client, which may erase the client's unacknowledged - input buffers before they can be read and interpreted by the HTTP - application. - - 400 Bad Request - - The request could not be understood by the server due to malformed - syntax. The client should not repeat the request without - modifications. - - 401 Unauthorized - - The request requires user authentication. The response must include - a WWW-Authenticate header field (Section 10.16) containing a - challenge applicable to the requested resource. The client may - repeat the request with a suitable Authorization header field - (Section 10.2). If the request already included Authorization - credentials, then the 401 response indicates that authorization has - been refused for those credentials. If the 401 response contains - the same challenge as the prior response, and the user agent has - already attempted authentication at least once, then the user - should be presented the entity that was given in the response, - since that entity may include relevant diagnostic information. HTTP - access authentication is explained in Section 11. - - 403 Forbidden - - The server understood the request, but is refusing to fulfill it. - Authorization will not help and the request should not be repeated. - If the request method was not HEAD and the server wishes to make - public why the request has not been fulfilled, it should describe - the reason for the refusal in the entity body. This status code is - commonly used when the server does not wish to reveal exactly why - the request has been refused, or when no other response is - applicable. - - 404 Not Found - - The server has not found anything matching the Request-URI. No - indication is given of whether the condition is temporary or - permanent. If the server does not wish to make this information - available to the client, the status code 403 (forbidden) can be - used instead. - - - -Berners-Lee, et al Informational [Page 36] - -RFC 1945 HTTP/1.0 May 1996 - - -9.5 Server Error 5xx - - Response status codes beginning with the digit "5" indicate cases in - which the server is aware that it has erred or is incapable of - performing the request. If the client has not completed the request - when a 5xx code is received, it should immediately cease sending data - to the server. Except when responding to a HEAD request, the server - should include an entity containing an explanation of the error - situation, and whether it is a temporary or permanent condition. - These response codes are applicable to any request method and there - are no required header fields. - - 500 Internal Server Error - - The server encountered an unexpected condition which prevented it - from fulfilling the request. - - 501 Not Implemented - - The server does not support the functionality required to fulfill - the request. This is the appropriate response when the server does - not recognize the request method and is not capable of supporting - it for any resource. - - 502 Bad Gateway - - The server, while acting as a gateway or proxy, received an invalid - response from the upstream server it accessed in attempting to - fulfill the request. - - 503 Service Unavailable - - The server is currently unable to handle the request due to a - temporary overloading or maintenance of the server. The implication - is that this is a temporary condition which will be alleviated - after some delay. - - Note: The existence of the 503 status code does not imply - that a server must use it when becoming overloaded. Some - servers may wish to simply refuse the connection. - -10. Header Field Definitions - - This section defines the syntax and semantics of all commonly used - HTTP/1.0 header fields. For general and entity header fields, both - sender and recipient refer to either the client or the server, - depending on who sends and who receives the message. - - - - -Berners-Lee, et al Informational [Page 37] - -RFC 1945 HTTP/1.0 May 1996 - - -10.1 Allow - - The Allow entity-header field lists the set of methods supported by - the resource identified by the Request-URI. The purpose of this field - is strictly to inform the recipient of valid methods associated with - the resource. The Allow header field is not permitted in a request - using the POST method, and thus should be ignored if it is received - as part of a POST entity. - - Allow = "Allow" ":" 1#method - - Example of use: - - Allow: GET, HEAD - - This field cannot prevent a client from trying other methods. - However, the indications given by the Allow header field value should - be followed. The actual set of allowed methods is defined by the - origin server at the time of each request. - - A proxy must not modify the Allow header field even if it does not - understand all the methods specified, since the user agent may have - other means of communicating with the origin server. - - The Allow header field does not indicate what methods are implemented - by the server. - -10.2 Authorization - - A user agent that wishes to authenticate itself with a server-- - usually, but not necessarily, after receiving a 401 response--may do - so by including an Authorization request-header field with the - request. The Authorization field value consists of credentials - containing the authentication information of the user agent for the - realm of the resource being requested. - - Authorization = "Authorization" ":" credentials - - HTTP access authentication is described in Section 11. If a request - is authenticated and a realm specified, the same credentials should - be valid for all other requests within this realm. - - Responses to requests containing an Authorization field are not - cachable. - - - - - - - -Berners-Lee, et al Informational [Page 38] - -RFC 1945 HTTP/1.0 May 1996 - - -10.3 Content-Encoding - - The Content-Encoding entity-header field is used as a modifier to the - media-type. When present, its value indicates what additional content - coding has been applied to the resource, and thus what decoding - mechanism must be applied in order to obtain the media-type - referenced by the Content-Type header field. The Content-Encoding is - primarily used to allow a document to be compressed without losing - the identity of its underlying media type. - - Content-Encoding = "Content-Encoding" ":" content-coding - - Content codings are defined in Section 3.5. An example of its use is - - Content-Encoding: x-gzip - - The Content-Encoding is a characteristic of the resource identified - by the Request-URI. Typically, the resource is stored with this - encoding and is only decoded before rendering or analogous usage. - -10.4 Content-Length - - The Content-Length entity-header field indicates the size of the - Entity-Body, in decimal number of octets, sent to the recipient or, - in the case of the HEAD method, the size of the Entity-Body that - would have been sent had the request been a GET. - - Content-Length = "Content-Length" ":" 1*DIGIT - - An example is - - Content-Length: 3495 - - Applications should use this field to indicate the size of the - Entity-Body to be transferred, regardless of the media type of the - entity. A valid Content-Length field value is required on all - HTTP/1.0 request messages containing an entity body. - - Any Content-Length greater than or equal to zero is a valid value. - Section 7.2.2 describes how to determine the length of a response - entity body if a Content-Length is not given. - - Note: The meaning of this field is significantly different from - the corresponding definition in MIME, where it is an optional - field used within the "message/external-body" content-type. In - HTTP, it should be used whenever the entity's length can be - determined prior to being transferred. - - - - -Berners-Lee, et al Informational [Page 39] - -RFC 1945 HTTP/1.0 May 1996 - - -10.5 Content-Type - - The Content-Type entity-header field indicates the media type of the - Entity-Body sent to the recipient or, in the case of the HEAD method, - the media type that would have been sent had the request been a GET. - - Content-Type = "Content-Type" ":" media-type - - Media types are defined in Section 3.6. An example of the field is - - Content-Type: text/html - - Further discussion of methods for identifying the media type of an - entity is provided in Section 7.2.1. - -10.6 Date - - The Date general-header field represents the date and time at which - the message was originated, having the same semantics as orig-date in - RFC 822. The field value is an HTTP-date, as described in Section - 3.3. - - Date = "Date" ":" HTTP-date - - An example is - - Date: Tue, 15 Nov 1994 08:12:31 GMT - - If a message is received via direct connection with the user agent - (in the case of requests) or the origin server (in the case of - responses), then the date can be assumed to be the current date at - the receiving end. However, since the date--as it is believed by the - origin--is important for evaluating cached responses, origin servers - should always include a Date header. Clients should only send a Date - header field in messages that include an entity body, as in the case - of the POST request, and even then it is optional. A received message - which does not have a Date header field should be assigned one by the - recipient if the message will be cached by that recipient or - gatewayed via a protocol which requires a Date. - - In theory, the date should represent the moment just before the - entity is generated. In practice, the date can be generated at any - time during the message origination without affecting its semantic - value. - - Note: An earlier version of this document incorrectly specified - that this field should contain the creation date of the enclosed - Entity-Body. This has been changed to reflect actual (and proper) - - - -Berners-Lee, et al Informational [Page 40] - -RFC 1945 HTTP/1.0 May 1996 - - - usage. - -10.7 Expires - - The Expires entity-header field gives the date/time after which the - entity should be considered stale. This allows information providers - to suggest the volatility of the resource, or a date after which the - information may no longer be valid. Applications must not cache this - entity beyond the date given. The presence of an Expires field does - not imply that the original resource will change or cease to exist - at, before, or after that time. However, information providers that - know or even suspect that a resource will change by a certain date - should include an Expires header with that date. The format is an - absolute date and time as defined by HTTP-date in Section 3.3. - - Expires = "Expires" ":" HTTP-date - - An example of its use is - - Expires: Thu, 01 Dec 1994 16:00:00 GMT - - If the date given is equal to or earlier than the value of the Date - header, the recipient must not cache the enclosed entity. If a - resource is dynamic by nature, as is the case with many data- - producing processes, entities from that resource should be given an - appropriate Expires value which reflects that dynamism. - - The Expires field cannot be used to force a user agent to refresh its - display or reload a resource; its semantics apply only to caching - mechanisms, and such mechanisms need only check a resource's - expiration status when a new request for that resource is initiated. - - User agents often have history mechanisms, such as "Back" buttons and - history lists, which can be used to redisplay an entity retrieved - earlier in a session. By default, the Expires field does not apply to - history mechanisms. If the entity is still in storage, a history - mechanism should display it even if the entity has expired, unless - the user has specifically configured the agent to refresh expired - history documents. - - Note: Applications are encouraged to be tolerant of bad or - misinformed implementations of the Expires header. A value of zero - (0) or an invalid date format should be considered equivalent to - an "expires immediately." Although these values are not legitimate - for HTTP/1.0, a robust implementation is always desirable. - - - - - - -Berners-Lee, et al Informational [Page 41] - -RFC 1945 HTTP/1.0 May 1996 - - -10.8 From - - The From request-header field, if given, should contain an Internet - e-mail address for the human user who controls the requesting user - agent. The address should be machine-usable, as defined by mailbox in - RFC 822 [7] (as updated by RFC 1123 [6]): - - From = "From" ":" mailbox - - An example is: - - From: webmaster@w3.org - - This header field may be used for logging purposes and as a means for - identifying the source of invalid or unwanted requests. It should not - be used as an insecure form of access protection. The interpretation - of this field is that the request is being performed on behalf of the - person given, who accepts responsibility for the method performed. In - particular, robot agents should include this header so that the - person responsible for running the robot can be contacted if problems - occur on the receiving end. - - The Internet e-mail address in this field may be separate from the - Internet host which issued the request. For example, when a request - is passed through a proxy, the original issuer's address should be - used. - - Note: The client should not send the From header field without the - user's approval, as it may conflict with the user's privacy - interests or their site's security policy. It is strongly - recommended that the user be able to disable, enable, and modify - the value of this field at any time prior to a request. - -10.9 If-Modified-Since - - The If-Modified-Since request-header field is used with the GET - method to make it conditional: if the requested resource has not been - modified since the time specified in this field, a copy of the - resource will not be returned from the server; instead, a 304 (not - modified) response will be returned without any Entity-Body. - - If-Modified-Since = "If-Modified-Since" ":" HTTP-date - - An example of the field is: - - If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT - - - - - -Berners-Lee, et al Informational [Page 42] - -RFC 1945 HTTP/1.0 May 1996 - - - A conditional GET method requests that the identified resource be - transferred only if it has been modified since the date given by the - If-Modified-Since header. The algorithm for determining this includes - the following cases: - - a) If the request would normally result in anything other than - a 200 (ok) status, or if the passed If-Modified-Since date - is invalid, the response is exactly the same as for a - normal GET. A date which is later than the server's current - time is invalid. - - b) If the resource has been modified since the - If-Modified-Since date, the response is exactly the same as - for a normal GET. - - c) If the resource has not been modified since a valid - If-Modified-Since date, the server shall return a 304 (not - modified) response. - - The purpose of this feature is to allow efficient updates of cached - information with a minimum amount of transaction overhead. - -10.10 Last-Modified - - The Last-Modified entity-header field indicates the date and time at - which the sender believes the resource was last modified. The exact - semantics of this field are defined in terms of how the recipient - should interpret it: if the recipient has a copy of this resource - which is older than the date given by the Last-Modified field, that - copy should be considered stale. - - Last-Modified = "Last-Modified" ":" HTTP-date - - An example of its use is - - Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT - - The exact meaning of this header field depends on the implementation - of the sender and the nature of the original resource. For files, it - may be just the file system last-modified time. For entities with - dynamically included parts, it may be the most recent of the set of - last-modify times for its component parts. For database gateways, it - may be the last-update timestamp of the record. For virtual objects, - it may be the last time the internal state changed. - - An origin server must not send a Last-Modified date which is later - than the server's time of message origination. In such cases, where - the resource's last modification would indicate some time in the - - - -Berners-Lee, et al Informational [Page 43] - -RFC 1945 HTTP/1.0 May 1996 - - - future, the server must replace that date with the message - origination date. - -10.11 Location - - The Location response-header field defines the exact location of the - resource that was identified by the Request-URI. For 3xx responses, - the location must indicate the server's preferred URL for automatic - redirection to the resource. Only one absolute URL is allowed. - - Location = "Location" ":" absoluteURI - - An example is - - Location: http://www.w3.org/hypertext/WWW/NewLocation.html - -10.12 Pragma - - The Pragma general-header field is used to include implementation- - specific directives that may apply to any recipient along the - request/response chain. All pragma directives specify optional - behavior from the viewpoint of the protocol; however, some systems - may require that behavior be consistent with the directives. - - Pragma = "Pragma" ":" 1#pragma-directive - - pragma-directive = "no-cache" | extension-pragma - extension-pragma = token [ "=" word ] - - When the "no-cache" directive is present in a request message, an - application should forward the request toward the origin server even - if it has a cached copy of what is being requested. This allows a - client to insist upon receiving an authoritative response to its - request. It also allows a client to refresh a cached copy which is - known to be corrupted or stale. - - Pragma directives must be passed through by a proxy or gateway - application, regardless of their significance to that application, - since the directives may be applicable to all recipients along the - request/response chain. It is not possible to specify a pragma for a - specific recipient; however, any pragma directive not relevant to a - recipient should be ignored by that recipient. - -10.13 Referer - - The Referer request-header field allows the client to specify, for - the server's benefit, the address (URI) of the resource from which - the Request-URI was obtained. This allows a server to generate lists - - - -Berners-Lee, et al Informational [Page 44] - -RFC 1945 HTTP/1.0 May 1996 - - - of back-links to resources for interest, logging, optimized caching, - etc. It also allows obsolete or mistyped links to be traced for - maintenance. The Referer field must not be sent if the Request-URI - was obtained from a source that does not have its own URI, such as - input from the user keyboard. - - Referer = "Referer" ":" ( absoluteURI | relativeURI ) - - Example: - - Referer: http://www.w3.org/hypertext/DataSources/Overview.html - - If a partial URI is given, it should be interpreted relative to the - Request-URI. The URI must not include a fragment. - - Note: Because the source of a link may be private information or - may reveal an otherwise private information source, it is strongly - recommended that the user be able to select whether or not the - Referer field is sent. For example, a browser client could have a - toggle switch for browsing openly/anonymously, which would - respectively enable/disable the sending of Referer and From - information. - -10.14 Server - - The Server response-header field contains information about the - software used by the origin server to handle the request. The field - can contain multiple product tokens (Section 3.7) and comments - identifying the server and any significant subproducts. By - convention, the product tokens are listed in order of their - significance for identifying the application. - - Server = "Server" ":" 1*( product | comment ) - - Example: - - Server: CERN/3.0 libwww/2.17 - - If the response is being forwarded through a proxy, the proxy - application must not add its data to the product list. - - Note: Revealing the specific software version of the server may - allow the server machine to become more vulnerable to attacks - against software that is known to contain security holes. Server - implementors are encouraged to make this field a configurable - option. - - - - - -Berners-Lee, et al Informational [Page 45] - -RFC 1945 HTTP/1.0 May 1996 - - - Note: Some existing servers fail to restrict themselves to the - product token syntax within the Server field. - -10.15 User-Agent - - The User-Agent request-header field contains information about the - user agent originating the request. This is for statistical purposes, - the tracing of protocol violations, and automated recognition of user - agents for the sake of tailoring responses to avoid particular user - agent limitations. Although it is not required, user agents should - include this field with requests. The field can contain multiple - product tokens (Section 3.7) and comments identifying the agent and - any subproducts which form a significant part of the user agent. By - convention, the product tokens are listed in order of their - significance for identifying the application. - - User-Agent = "User-Agent" ":" 1*( product | comment ) - - Example: - - User-Agent: CERN-LineMode/2.15 libwww/2.17b3 - - Note: Some current proxy applications append their product - information to the list in the User-Agent field. This is not - recommended, since it makes machine interpretation of these - fields ambiguous. - - Note: Some existing clients fail to restrict themselves to - the product token syntax within the User-Agent field. - -10.16 WWW-Authenticate - - The WWW-Authenticate response-header field must be included in 401 - (unauthorized) response messages. The field value consists of at - least one challenge that indicates the authentication scheme(s) and - parameters applicable to the Request-URI. - - WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge - - The HTTP access authentication process is described in Section 11. - User agents must take special care in parsing the WWW-Authenticate - field value if it contains more than one challenge, or if more than - one WWW-Authenticate header field is provided, since the contents of - a challenge may itself contain a comma-separated list of - authentication parameters. - - - - - - -Berners-Lee, et al Informational [Page 46] - -RFC 1945 HTTP/1.0 May 1996 - - -11. Access Authentication - - HTTP provides a simple challenge-response authentication mechanism - which may be used by a server to challenge a client request and by a - client to provide authentication information. It uses an extensible, - case-insensitive token to identify the authentication scheme, - followed by a comma-separated list of attribute-value pairs which - carry the parameters necessary for achieving authentication via that - scheme. - - auth-scheme = token - - auth-param = token "=" quoted-string - - The 401 (unauthorized) response message is used by an origin server - to challenge the authorization of a user agent. This response must - include a WWW-Authenticate header field containing at least one - challenge applicable to the requested resource. - - challenge = auth-scheme 1*SP realm *( "," auth-param ) - - realm = "realm" "=" realm-value - realm-value = quoted-string - - The realm attribute (case-insensitive) is required for all - authentication schemes which issue a challenge. The realm value - (case-sensitive), in combination with the canonical root URL of the - server being accessed, defines the protection space. These realms - allow the protected resources on a server to be partitioned into a - set of protection spaces, each with its own authentication scheme - and/or authorization database. The realm value is a string, generally - assigned by the origin server, which may have additional semantics - specific to the authentication scheme. - - A user agent that wishes to authenticate itself with a server-- - usually, but not necessarily, after receiving a 401 response--may do - so by including an Authorization header field with the request. The - Authorization field value consists of credentials containing the - authentication information of the user agent for the realm of the - resource being requested. - - credentials = basic-credentials - | ( auth-scheme #auth-param ) - - The domain over which credentials can be automatically applied by a - user agent is determined by the protection space. If a prior request - has been authorized, the same credentials may be reused for all other - requests within that protection space for a period of time determined - - - -Berners-Lee, et al Informational [Page 47] - -RFC 1945 HTTP/1.0 May 1996 - - - by the authentication scheme, parameters, and/or user preference. - Unless otherwise defined by the authentication scheme, a single - protection space cannot extend outside the scope of its server. - - If the server does not wish to accept the credentials sent with a - request, it should return a 403 (forbidden) response. - - The HTTP protocol does not restrict applications to this simple - challenge-response mechanism for access authentication. Additional - mechanisms may be used, such as encryption at the transport level or - via message encapsulation, and with additional header fields - specifying authentication information. However, these additional - mechanisms are not defined by this specification. - - Proxies must be completely transparent regarding user agent - authentication. That is, they must forward the WWW-Authenticate and - Authorization headers untouched, and must not cache the response to a - request containing Authorization. HTTP/1.0 does not provide a means - for a client to be authenticated with a proxy. - -11.1 Basic Authentication Scheme - - The "basic" authentication scheme is based on the model that the user - agent must authenticate itself with a user-ID and a password for each - realm. The realm value should be considered an opaque string which - can only be compared for equality with other realms on that server. - The server will authorize the request only if it can validate the - user-ID and password for the protection space of the Request-URI. - There are no optional authentication parameters. - - Upon receipt of an unauthorized request for a URI within the - protection space, the server should respond with a challenge like the - following: - - WWW-Authenticate: Basic realm="WallyWorld" - - where "WallyWorld" is the string assigned by the server to identify - the protection space of the Request-URI. - - To receive authorization, the client sends the user-ID and password, - separated by a single colon (":") character, within a base64 [5] - encoded string in the credentials. - - basic-credentials = "Basic" SP basic-cookie - - basic-cookie = <base64 [5] encoding of userid-password, - except not limited to 76 char/line> - - - - -Berners-Lee, et al Informational [Page 48] - -RFC 1945 HTTP/1.0 May 1996 - - - userid-password = [ token ] ":" *TEXT - - If the user agent wishes to send the user-ID "Aladdin" and password - "open sesame", it would use the following header field: - - Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== - - The basic authentication scheme is a non-secure method of filtering - unauthorized access to resources on an HTTP server. It is based on - the assumption that the connection between the client and the server - can be regarded as a trusted carrier. As this is not generally true - on an open network, the basic authentication scheme should be used - accordingly. In spite of this, clients should implement the scheme in - order to communicate with servers that use it. - -12. Security Considerations - - This section is meant to inform application developers, information - providers, and users of the security limitations in HTTP/1.0 as - described by this document. The discussion does not include - definitive solutions to the problems revealed, though it does make - some suggestions for reducing security risks. - -12.1 Authentication of Clients - - As mentioned in Section 11.1, the Basic authentication scheme is not - a secure method of user authentication, nor does it prevent the - Entity-Body from being transmitted in clear text across the physical - network used as the carrier. HTTP/1.0 does not prevent additional - authentication schemes and encryption mechanisms from being employed - to increase security. - -12.2 Safe Methods - - The writers of client software should be aware that the software - represents the user in their interactions over the Internet, and - should be careful to allow the user to be aware of any actions they - may take which may have an unexpected significance to themselves or - others. - - In particular, the convention has been established that the GET and - HEAD methods should never have the significance of taking an action - other than retrieval. These methods should be considered "safe." This - allows user agents to represent other methods, such as POST, in a - special way, so that the user is made aware of the fact that a - possibly unsafe action is being requested. - - - - - -Berners-Lee, et al Informational [Page 49] - -RFC 1945 HTTP/1.0 May 1996 - - - Naturally, it is not possible to ensure that the server does not - generate side-effects as a result of performing a GET request; in - fact, some dynamic resources consider that a feature. The important - distinction here is that the user did not request the side-effects, - so therefore cannot be held accountable for them. - -12.3 Abuse of Server Log Information - - A server is in the position to save personal data about a user's - requests which may identify their reading patterns or subjects of - interest. This information is clearly confidential in nature and its - handling may be constrained by law in certain countries. People using - the HTTP protocol to provide data are responsible for ensuring that - such material is not distributed without the permission of any - individuals that are identifiable by the published results. - -12.4 Transfer of Sensitive Information - - Like any generic data transfer protocol, HTTP cannot regulate the - content of the data that is transferred, nor is there any a priori - method of determining the sensitivity of any particular piece of - information within the context of any given request. Therefore, - applications should supply as much control over this information as - possible to the provider of that information. Three header fields are - worth special mention in this context: Server, Referer and From. - - Revealing the specific software version of the server may allow the - server machine to become more vulnerable to attacks against software - that is known to contain security holes. Implementors should make the - Server header field a configurable option. - - The Referer field allows reading patterns to be studied and reverse - links drawn. Although it can be very useful, its power can be abused - if user details are not separated from the information contained in - the Referer. Even when the personal information has been removed, the - Referer field may indicate a private document's URI whose publication - would be inappropriate. - - The information sent in the From field might conflict with the user's - privacy interests or their site's security policy, and hence it - should not be transmitted without the user being able to disable, - enable, and modify the contents of the field. The user must be able - to set the contents of this field within a user preference or - application defaults configuration. - - We suggest, though do not require, that a convenient toggle interface - be provided for the user to enable or disable the sending of From and - Referer information. - - - -Berners-Lee, et al Informational [Page 50] - -RFC 1945 HTTP/1.0 May 1996 - - -12.5 Attacks Based On File and Path Names - - Implementations of HTTP origin servers should be careful to restrict - the documents returned by HTTP requests to be only those that were - intended by the server administrators. If an HTTP server translates - HTTP URIs directly into file system calls, the server must take - special care not to serve files that were not intended to be - delivered to HTTP clients. For example, Unix, Microsoft Windows, and - other operating systems use ".." as a path component to indicate a - directory level above the current one. On such a system, an HTTP - server must disallow any such construct in the Request-URI if it - would otherwise allow access to a resource outside those intended to - be accessible via the HTTP server. Similarly, files intended for - reference only internally to the server (such as access control - files, configuration files, and script code) must be protected from - inappropriate retrieval, since they might contain sensitive - information. Experience has shown that minor bugs in such HTTP server - implementations have turned into security risks. - -13. Acknowledgments - - This specification makes heavy use of the augmented BNF and generic - constructs defined by David H. Crocker for RFC 822 [7]. Similarly, it - reuses many of the definitions provided by Nathaniel Borenstein and - Ned Freed for MIME [5]. We hope that their inclusion in this - specification will help reduce past confusion over the relationship - between HTTP/1.0 and Internet mail message formats. - - The HTTP protocol has evolved considerably over the past four years. - It has benefited from a large and active developer community--the - many people who have participated on the www-talk mailing list--and - it is that community which has been most responsible for the success - of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert - Cailliau, Daniel W. Connolly, Bob Denny, Jean-Francois Groff, Phillip - M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou - Montulli, Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve - special recognition for their efforts in defining aspects of the - protocol for early versions of this specification. - - Paul Hoffman contributed sections regarding the informational status - of this document and Appendices C and D. - - - - - - - - - - -Berners-Lee, et al Informational [Page 51] - -RFC 1945 HTTP/1.0 May 1996 - - - This document has benefited greatly from the comments of all those - participating in the HTTP-WG. In addition to those already mentioned, - the following individuals have contributed to this specification: - - Gary Adams Harald Tveit Alvestrand - Keith Ball Brian Behlendorf - Paul Burchard Maurizio Codogno - Mike Cowlishaw Roman Czyborra - Michael A. Dolan John Franks - Jim Gettys Marc Hedlund - Koen Holtman Alex Hopmann - Bob Jernigan Shel Kaphan - Martijn Koster Dave Kristol - Daniel LaLiberte Paul Leach - Albert Lunde John C. Mallery - Larry Masinter Mitra - Jeffrey Mogul Gavin Nicol - Bill Perry Jeffrey Perry - Owen Rees Luigi Rizzo - David Robinson Marc Salomon - Rich Salz Jim Seidman - Chuck Shotton Eric W. Sink - Simon E. Spero Robert S. Thau - Francois Yergeau Mary Ellen Zurko - Jean-Philippe Martin-Flatin - -14. References - - [1] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., - Torrey, D., and B. Alberti, "The Internet Gopher Protocol: A - Distributed Document Search and Retrieval Protocol", RFC 1436, - University of Minnesota, March 1993. - - [2] Berners-Lee, T., "Universal Resource Identifiers in WWW: A - Unifying Syntax for the Expression of Names and Addresses of - Objects on the Network as used in the World-Wide Web", - RFC 1630, CERN, June 1994. - - [3] Berners-Lee, T., and D. Connolly, "Hypertext Markup Language - - 2.0", RFC 1866, MIT/W3C, November 1995. - - [4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform - Resource Locators (URL)", RFC 1738, CERN, Xerox PARC, - University of Minnesota, December 1994. - - - - - - - -Berners-Lee, et al Informational [Page 52] - -RFC 1945 HTTP/1.0 May 1996 - - - [5] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail - Extensions) Part One: Mechanisms for Specifying and Describing - the Format of Internet Message Bodies", RFC 1521, Bellcore, - Innosoft, September 1993. - - [6] Braden, R., "Requirements for Internet hosts - Application and - Support", STD 3, RFC 1123, IETF, October 1989. - - [7] Crocker, D., "Standard for the Format of ARPA Internet Text - Messages", STD 11, RFC 822, UDEL, August 1982. - - [8] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang, - J. Sui, and M. Grinbaum. "WAIS Interface Protocol Prototype - Functional Specification." (v1.5), Thinking Machines - Corporation, April 1990. - - [9] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, - UC Irvine, June 1995. - - [10] Horton, M., and R. Adams, "Standard for interchange of USENET - Messages", RFC 1036 (Obsoletes RFC 850), AT&T Bell - Laboratories, Center for Seismic Studies, December 1987. - - [11] Kantor, B., and P. Lapsley, "Network News Transfer Protocol: - A Proposed Standard for the Stream-Based Transmission of News", - RFC 977, UC San Diego, UC Berkeley, February 1986. - - [12] Postel, J., "Simple Mail Transfer Protocol." STD 10, RFC 821, - USC/ISI, August 1982. - - [13] Postel, J., "Media Type Registration Procedure." RFC 1590, - USC/ISI, March 1994. - - [14] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", - STD 9, RFC 959, USC/ISI, October 1985. - - [15] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC - 1700, USC/ISI, October 1994. - - [16] Sollins, K., and L. Masinter, "Functional Requirements for - Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation, - December 1994. - - [17] US-ASCII. Coded Character Set - 7-Bit American Standard Code - for Information Interchange. Standard ANSI X3.4-1986, ANSI, - 1986. - - - - - -Berners-Lee, et al Informational [Page 53] - -RFC 1945 HTTP/1.0 May 1996 - - - [18] ISO-8859. International Standard -- Information Processing -- - 8-bit Single-Byte Coded Graphic Character Sets -- - Part 1: Latin alphabet No. 1, ISO 8859-1:1987. - Part 2: Latin alphabet No. 2, ISO 8859-2, 1987. - Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. - Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. - Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. - Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987. - Part 7: Latin/Greek alphabet, ISO 8859-7, 1987. - Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. - Part 9: Latin alphabet No. 5, ISO 8859-9, 1990. - -15. Authors' Addresses - - Tim Berners-Lee - Director, W3 Consortium - MIT Laboratory for Computer Science - 545 Technology Square - Cambridge, MA 02139, U.S.A. - - Fax: +1 (617) 258 8682 - EMail: timbl@w3.org - - - Roy T. Fielding - Department of Information and Computer Science - University of California - Irvine, CA 92717-3425, U.S.A. - - Fax: +1 (714) 824-4056 - EMail: fielding@ics.uci.edu - - - Henrik Frystyk Nielsen - W3 Consortium - MIT Laboratory for Computer Science - 545 Technology Square - Cambridge, MA 02139, U.S.A. - - Fax: +1 (617) 258 8682 - EMail: frystyk@w3.org - - - - - - - - - - -Berners-Lee, et al Informational [Page 54] - -RFC 1945 HTTP/1.0 May 1996 - - -Appendices - - These appendices are provided for informational reasons only -- they - do not form a part of the HTTP/1.0 specification. - -A. Internet Media Type message/http - - In addition to defining the HTTP/1.0 protocol, this document serves - as the specification for the Internet media type "message/http". The - following is to be registered with IANA [13]. - - Media Type name: message - - Media subtype name: http - - Required parameters: none - - Optional parameters: version, msgtype - - version: The HTTP-Version number of the enclosed message - (e.g., "1.0"). If not present, the version can be - determined from the first line of the body. - - msgtype: The message type -- "request" or "response". If - not present, the type can be determined from the - first line of the body. - - Encoding considerations: only "7bit", "8bit", or "binary" are - permitted - - Security considerations: none - -B. Tolerant Applications - - Although this document specifies the requirements for the generation - of HTTP/1.0 messages, not all applications will be correct in their - implementation. We therefore recommend that operational applications - be tolerant of deviations whenever those deviations can be - interpreted unambiguously. - - Clients should be tolerant in parsing the Status-Line and servers - tolerant when parsing the Request-Line. In particular, they should - accept any amount of SP or HT characters between fields, even though - only a single SP is required. - - The line terminator for HTTP-header fields is the sequence CRLF. - However, we recommend that applications, when parsing such headers, - recognize a single LF as a line terminator and ignore the leading CR. - - - -Berners-Lee, et al Informational [Page 55] - -RFC 1945 HTTP/1.0 May 1996 - - -C. Relationship to MIME - - HTTP/1.0 uses many of the constructs defined for Internet Mail (RFC - 822 [7]) and the Multipurpose Internet Mail Extensions (MIME [5]) to - allow entities to be transmitted in an open variety of - representations and with extensible mechanisms. However, RFC 1521 - discusses mail, and HTTP has a few features that are different than - those described in RFC 1521. These differences were carefully chosen - to optimize performance over binary connections, to allow greater - freedom in the use of new media types, to make date comparisons - easier, and to acknowledge the practice of some early HTTP servers - and clients. - - At the time of this writing, it is expected that RFC 1521 will be - revised. The revisions may include some of the practices found in - HTTP/1.0 but not in RFC 1521. - - This appendix describes specific areas where HTTP differs from RFC - 1521. Proxies and gateways to strict MIME environments should be - aware of these differences and provide the appropriate conversions - where necessary. Proxies and gateways from MIME environments to HTTP - also need to be aware of the differences because some conversions may - be required. - -C.1 Conversion to Canonical Form - - RFC 1521 requires that an Internet mail entity be converted to - canonical form prior to being transferred, as described in Appendix G - of RFC 1521 [5]. Section 3.6.1 of this document describes the forms - allowed for subtypes of the "text" media type when transmitted over - HTTP. - - RFC 1521 requires that content with a Content-Type of "text" - represent line breaks as CRLF and forbids the use of CR or LF outside - of line break sequences. HTTP allows CRLF, bare CR, and bare LF to - indicate a line break within text content when a message is - transmitted over HTTP. - - Where it is possible, a proxy or gateway from HTTP to a strict RFC - 1521 environment should translate all line breaks within the text - media types described in Section 3.6.1 of this document to the RFC - 1521 canonical form of CRLF. Note, however, that this may be - complicated by the presence of a Content-Encoding and by the fact - that HTTP allows the use of some character sets which do not use - octets 13 and 10 to represent CR and LF, as is the case for some - multi-byte character sets. - - - - - -Berners-Lee, et al Informational [Page 56] - -RFC 1945 HTTP/1.0 May 1996 - - -C.2 Conversion of Date Formats - - HTTP/1.0 uses a restricted set of date formats (Section 3.3) to - simplify the process of date comparison. Proxies and gateways from - other protocols should ensure that any Date header field present in a - message conforms to one of the HTTP/1.0 formats and rewrite the date - if necessary. - -C.3 Introduction of Content-Encoding - - RFC 1521 does not include any concept equivalent to HTTP/1.0's - Content-Encoding header field. Since this acts as a modifier on the - media type, proxies and gateways from HTTP to MIME-compliant - protocols must either change the value of the Content-Type header - field or decode the Entity-Body before forwarding the message. (Some - experimental applications of Content-Type for Internet mail have used - a media-type parameter of ";conversions=<content-coding>" to perform - an equivalent function as Content-Encoding. However, this parameter - is not part of RFC 1521.) - -C.4 No Content-Transfer-Encoding - - HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC - 1521. Proxies and gateways from MIME-compliant protocols to HTTP must - remove any non-identity CTE ("quoted-printable" or "base64") encoding - prior to delivering the response message to an HTTP client. - - Proxies and gateways from HTTP to MIME-compliant protocols are - responsible for ensuring that the message is in the correct format - and encoding for safe transport on that protocol, where "safe - transport" is defined by the limitations of the protocol being used. - Such a proxy or gateway should label the data with an appropriate - Content-Transfer-Encoding if doing so will improve the likelihood of - safe transport over the destination protocol. - -C.5 HTTP Header Fields in Multipart Body-Parts - - In RFC 1521, most header fields in multipart body-parts are generally - ignored unless the field name begins with "Content-". In HTTP/1.0, - multipart body-parts may contain any HTTP header fields which are - significant to the meaning of that part. - -D. Additional Features - - This appendix documents protocol elements used by some existing HTTP - implementations, but not consistently and correctly across most - HTTP/1.0 applications. Implementors should be aware of these - features, but cannot rely upon their presence in, or interoperability - - - -Berners-Lee, et al Informational [Page 57] - -RFC 1945 HTTP/1.0 May 1996 - - - with, other HTTP/1.0 applications. - -D.1 Additional Request Methods - -D.1.1 PUT - - The PUT method requests that the enclosed entity be stored under the - supplied Request-URI. If the Request-URI refers to an already - existing resource, the enclosed entity should be considered as a - modified version of the one residing on the origin server. If the - Request-URI does not point to an existing resource, and that URI is - capable of being defined as a new resource by the requesting user - agent, the origin server can create the resource with that URI. - - The fundamental difference between the POST and PUT requests is - reflected in the different meaning of the Request-URI. The URI in a - POST request identifies the resource that will handle the enclosed - entity as data to be processed. That resource may be a data-accepting - process, a gateway to some other protocol, or a separate entity that - accepts annotations. In contrast, the URI in a PUT request identifies - the entity enclosed with the request -- the user agent knows what URI - is intended and the server should not apply the request to some other - resource. - -D.1.2 DELETE - - The DELETE method requests that the origin server delete the resource - identified by the Request-URI. - -D.1.3 LINK - - The LINK method establishes one or more Link relationships between - the existing resource identified by the Request-URI and other - existing resources. - -D.1.4 UNLINK - - The UNLINK method removes one or more Link relationships from the - existing resource identified by the Request-URI. - -D.2 Additional Header Field Definitions - -D.2.1 Accept - - The Accept request-header field can be used to indicate a list of - media ranges which are acceptable as a response to the request. The - asterisk "*" character is used to group media types into ranges, with - "*/*" indicating all media types and "type/*" indicating all subtypes - - - -Berners-Lee, et al Informational [Page 58] - -RFC 1945 HTTP/1.0 May 1996 - - - of that type. The set of ranges given by the client should represent - what types are acceptable given the context of the request. - -D.2.2 Accept-Charset - - The Accept-Charset request-header field can be used to indicate a - list of preferred character sets other than the default US-ASCII and - ISO-8859-1. This field allows clients capable of understanding more - comprehensive or special-purpose character sets to signal that - capability to a server which is capable of representing documents in - those character sets. - -D.2.3 Accept-Encoding - - The Accept-Encoding request-header field is similar to Accept, but - restricts the content-coding values which are acceptable in the - response. - -D.2.4 Accept-Language - - The Accept-Language request-header field is similar to Accept, but - restricts the set of natural languages that are preferred as a - response to the request. - -D.2.5 Content-Language - - The Content-Language entity-header field describes the natural - language(s) of the intended audience for the enclosed entity. Note - that this may not be equivalent to all the languages used within the - entity. - -D.2.6 Link - - The Link entity-header field provides a means for describing a - relationship between the entity and some other resource. An entity - may include multiple Link values. Links at the metainformation level - typically indicate relationships like hierarchical structure and - navigation paths. - -D.2.7 MIME-Version - - HTTP messages may include a single MIME-Version general-header field - to indicate what version of the MIME protocol was used to construct - the message. Use of the MIME-Version header field, as defined by RFC - 1521 [5], should indicate that the message is MIME-conformant. - Unfortunately, some older HTTP/1.0 servers send it indiscriminately, - and thus this field should be ignored. - - - - -Berners-Lee, et al Informational [Page 59] - -RFC 1945 HTTP/1.0 May 1996 - - -D.2.8 Retry-After - - The Retry-After response-header field can be used with a 503 (service - unavailable) response to indicate how long the service is expected to - be unavailable to the requesting client. The value of this field can - be either an HTTP-date or an integer number of seconds (in decimal) - after the time of the response. - -D.2.9 Title - - The Title entity-header field indicates the title of the entity. - -D.2.10 URI - - The URI entity-header field may contain some or all of the Uniform - Resource Identifiers (Section 3.2) by which the Request-URI resource - can be identified. There is no guarantee that the resource can be - accessed using the URI(s) specified. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Berners-Lee, et al Informational [Page 60] - |