diff options
Diffstat (limited to 'lib/inets/doc/archive/rfc1945.html')
| -rw-r--r-- | lib/inets/doc/archive/rfc1945.html | 3035 |
1 files changed, 3035 insertions, 0 deletions
diff --git a/lib/inets/doc/archive/rfc1945.html b/lib/inets/doc/archive/rfc1945.html new file mode 100644 index 0000000000..cf88f53319 --- /dev/null +++ b/lib/inets/doc/archive/rfc1945.html @@ -0,0 +1,3035 @@ +<!-- + ``The contents of this file are subject to the Erlang Public License, + Version 1.1, (the "License"); you may not use this file except in + compliance with the License. You should have received a copy of the + Erlang Public License along with this software. If not, it can be + retrieved via the world wide web at http://www.erlang.org/. + + Software distributed under the License is distributed on an "AS IS" + basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See + the License for the specific language governing rights and limitations + under the License. + + The Initial Developer of the Original Code is Ericsson Utvecklings AB. + Portions created by Ericsson are Copyright 1999, Ericsson Utvecklings + AB. All Rights Reserved.'' + + $Id$ +--> +<HTML><HEAD> +<TITLE>Hypertext Transfer Protocol -- HTTP/1.0</TITLE> +</HEAD><BODY> +<PRE> +Network Working Group T. Berners-Lee, MIT/LCS +Request for Comments: 1945 R. Fielding, UC Irvine +Category: Informational H. Frystyk, MIT/LCS + May 1996 +</PRE> + +<H1 ALIGN=CENTER>Hypertext Transfer Protocol -- HTTP/1.0</H1> + +<H2><A NAME="Status">Status of this Memo</A></H2> + + 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. + +<H2>IESG Note:</H2> + + The IESG has concerns about this protocol, and expects this document + to be replaced relatively soon by a standards track document. + +<H2><A NAME="Abstract">Abstract</A></H2> + + 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. +<P> + + 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". +<P> + +<H2><A NAME="Contents">Table of Contents</A></H2> + +<PRE> +1. <A HREF="#Introduction">Introduction</A> + 1.1 <A HREF="#Purpose">Purpose</A> + 1.2 <A HREF="#Terminology">Terminology</A> + 1.3 <A HREF="#Operation">Overall Operation</A> + 1.4 <A HREF="#HTTP-and-MIME">HTTP and MIME</A> + +2. <A HREF="#Grammar">Notational Conventions and Generic Grammar</A> + 2.1 <A HREF="#Augmented-BNF">Augmented BNF</A> + 2.2 <A HREF="#Basic-Rules">Basic Rules</A> + +3. <A HREF="#Protocol-Parameters">Protocol Parameters</A> + 3.1 <A HREF="#HTTP-Version">HTTP Version</A> + 3.2 <A HREF="#URI">Uniform Resource Identifiers</A> + 3.2.1 <A HREF="#URI-syntax">General Syntax</A> + 3.2.2 <A HREF="#http-URL">http URL</A> + 3.3 <A HREF="#DateFormats">Date/Time Formats</A> + 3.4 <A HREF="#Charset">Character Sets</A> + 3.5 <A HREF="#Content-Codings">Content Codings</A> + 3.6 <A HREF="#Media-Types">Media Types</A> + 3.6.1 <A HREF="#TextCanonicalization">Canonicalization and Text Defaults</A> + 3.6.2 <A HREF="#Multipart">Multipart Types</A> + 3.7 <A HREF="#Product">Product Tokens</A> + +4. <A HREF="#Message">HTTP Message</A> + 4.1 <A HREF="#Message-Types">Message Types</A> + 4.2 <A HREF="#Message-Headers">Message Headers</A> + 4.3 <A HREF="#General-Header">General Header Fields</A> + +5. <A HREF="#Request">Request</A> + 5.1 <A HREF="#Request-Line">Request-Line</A> + 5.1.1 <A HREF="#Method">Method</A> + 5.1.2 <A HREF="#Request-URI">Request-URI</A> + 5.2 <A HREF="#Request-Header">Request Header Fields</A> + +6. <A HREF="#Response">Response</A> + 6.1 <A HREF="#Status-Line">Status-Line</A> + 6.1.1 <A HREF="#Status-Code">Status Code and Reason Phrase</A> + 6.2 <A HREF="#Response-Header">Response Header Fields</A> + +7. <A HREF="#Entity">Entity</A> + 7.1 <A HREF="#Entity-Header">Entity Header Fields</A> + 7.2 <A HREF="#Entity-Body">Entity Body</A> + 7.2.1 <A HREF="#BodyType">Type</A> + 7.2.2 <A HREF="#BodyLength">Length</A> + +8. <A HREF="#Methods">Method Definitions</A> + 8.1 <A HREF="#GET">GET</A> + 8.2 <A HREF="#HEAD">HEAD</A> + 8.3 <A HREF="#POST">POST</A> + +9. <A HREF="#Status-Codes">Status Code Definitions</A> + 9.1 <A HREF="#Code1xx">Informational 1xx</A> + 9.2 <A HREF="#Code2xx">Successful 2xx</A> + <A HREF="#Code200">200 OK</A> + <A HREF="#Code201">201 Created</A> + <A HREF="#Code202">202 Accepted</A> + <A HREF="#Code204">204 No Content</A> + 9.3 <A HREF="#Code3xx">Redirection 3xx</A> + <A HREF="#Code300">300 Multiple Choices</A> + <A HREF="#Code301">301 Moved Permanently</A> + <A HREF="#Code302">302 Moved Temporarily</A> + <A HREF="#Code304">304 Not Modified</A> + 9.4 <A HREF="#Code4xx">Client Error 4xx</A> + <A HREF="#Code400">400 Bad Request</A> + <A HREF="#Code401">401 Unauthorized</A> + <A HREF="#Code403">403 Forbidden</A> + <A HREF="#Code404">404 Not Found</A> + 9.5 <A HREF="#Code5xx">Server Error 5xx</A> + <A HREF="#Code500">500 Internal Server Error</A> + <A HREF="#Code501">501 Not Implemented</A> + <A HREF="#Code502">502 Bad Gateway</A> + <A HREF="#Code503">503 Service Unavailable</A> + +10. <A HREF="#HeaderFields">Header Field Definitions</A> + 10.1 <A HREF="#Allow">Allow</A> + 10.2 <A HREF="#Authorization">Authorization</A> + 10.3 <A HREF="#Content-Encoding">Content-Encoding</A> + 10.4 <A HREF="#Content-Length">Content-Length</A> + 10.5 <A HREF="#Content-Type">Content-Type</A> + 10.6 <A HREF="#Date">Date</A> + 10.7 <A HREF="#Expires">Expires</A> + 10.8 <A HREF="#From">From</A> + 10.9 <A HREF="#If-Modified-Since">If-Modified-Since</A> + 10.10 <A HREF="#Last-Modified">Last-Modified</A> + 10.11 <A HREF="#Location">Location</A> + 10.12 <A HREF="#Pragma">Pragma</A> + 10.13 <A HREF="#Referer">Referer</A> + 10.14 <A HREF="#Server">Server</A> + 10.15 <A HREF="#User-Agent">User-Agent</A> + 10.16 <A HREF="#WWW-Authenticate">WWW-Authenticate</A> + +11. <A HREF="#AA">Access Authentication</A> + 11.1 <A HREF="#BasicAA">Basic Authentication Scheme</A> + +12. <A HREF="#Security">Security Considerations</A> + 12.1 <A HREF="#AuthSecurity">Authentication of Clients</A> + 12.2 <A HREF="#SafeMethods">Safe Methods</A> + 12.3 <A HREF="#LogAbuse">Abuse of Server Log Information</A> + 12.4 <A HREF="#Sensitive">Transfer of Sensitive Information</A> + 12.5 <A HREF="#PathNameSecurity">Attacks Based On File and Path Names</A> + +13. <A HREF="#Acknowledgments">Acknowledgments</A> + +14. <A HREF="#References">References</A> + +15. <A HREF="#Authors">Authors' Addresses</A> + +Appendix A. <A HREF="#message_http">Internet Media Type message/http</A> + +Appendix B. <A HREF="#Tolerant">Tolerant Applications</A> + +Appendix C. <A HREF="#MIME">Relationship to MIME</A> + C.1 <A HREF="#MIME-Canonical">Conversion to Canonical Form</A> + C.2 <A HREF="#MIME-Date">Conversion of Date Formats</A> + C.3 <A HREF="#MIME-CE">Introduction of Content-Encoding</A> + C.4 <A HREF="#MIME-CTE">No Content-Transfer-Encoding</A> + C.5 <A HREF="#MIME-parts">HTTP Header Fields in Multipart Body-Parts</A> + +Appendix D. <A HREF="#Additional">Additional Features</A> + D.1 <A HREF="#Additional-Methods">Additional Request Methods</A> + D.1.1 <A HREF="#PUT">PUT</A> + D.1.2 <A HREF="#DELETE">DELETE</A> + D.1.3 <A HREF="#LINK">LINK</A> + D.1.4 <A HREF="#UNLINK">UNLINK</A> + D.2 <A HREF="#Additional-Headers">Additional Header Field Definitions</A> + D.2.1 <A HREF="#Accept">Accept</A> + D.2.2 <A HREF="#Accept-Charset">Accept-Charset</A> + D.2.3 <A HREF="#Accept-Encoding">Accept-Encoding</A> + D.2.4 <A HREF="#Accept-Language">Accept-Language</A> + D.2.5 <A HREF="#Content-Language">Content-Language</A> + D.2.6 <A HREF="#Link">Link</A> + D.2.7 <A HREF="#MIME-Version">MIME-Version</A> + D.2.8 <A HREF="#Retry-After">Retry-After</A> + D.2.9 <A HREF="#Title">Title</A> + D.2.10 <A HREF="#URI-header">URI</A> + + +</PRE> + +<H2>1. <A NAME="Introduction">Introduction</A></H2> + +<H3>1.1 <A NAME="Purpose">Purpose</A></H3> + + 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 to 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 <A HREF="#Additional">Appendix D</A>. +<P> + + 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)<A HREF="#RefURI"> [2]</A>, as a location (URL)<A HREF="#RefURL"> [4]</A> or name (URN)<A HREF="#RefURN"> [16]</A>, 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<A HREF="#RefSTD11"> [7]</A> and the Multipurpose Internet Mail Extensions + (MIME)<A HREF="#RefMIME1"> [5]</A>. +<P> + + HTTP is also used as a generic protocol for communication between user agents and + proxies/gateways to other Internet protocols, such as SMTP<A HREF="#RefSMTP"> [12]</A>, NNTP<A HREF="#RefNNTP"> [11]</A>, FTP<A HREF="#RefFTP"> [14]</A>, + Gopher<A HREF="#RefGopher"> [1]</A>, and WAIS<A HREF="#RefWAIS"> [8]</A>, allowing basic hypermedia access to resources available from + diverse applications and simplifying the implementation of user agents. +<P> + +<H3>1.2 <A NAME="Terminology">Terminology</A></H3> + + This specification uses a number of terms to refer to the roles played by participants in, and + objects of, the HTTP communication. +<P> + +<DL> +<DT>connection +<DD>A transport layer virtual circuit established between two application programs for the + purpose of communication. + +<P> +<DT>message +<DD>The basic unit of HTTP communication, consisting of a structured sequence of octets + matching the syntax defined in <A HREF="#Message">Section 4</A> and transmitted via the connection. + +<P> +<DT>request +<DD>An HTTP request message (as defined in <A HREF="#Request">Section 5</A>). + +<P> +<DT>response +<DD>An HTTP response message (as defined in <A HREF="#Response">Section 6</A>). + +<P> +<DT>resource +<DD>A network data object or service which can be identified by a URI (<A HREF="#URI">Section 3.2</A>). + +<P> +<DT>entity +<DD>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. + +<P> +<DT>client +<DD>An application program that establishes connections for the purpose of sending requests. + +<P> +<DT>user agent +<DD>The client which initiates a request. These are often browsers, editors, spiders + (web-traversing robots), or other end user tools. + +<P> +<DT>server +<DD>An application program that accepts connections in order to service requests by sending + back responses. + +<P> +<DT>origin server +<DD>The server on which a given resource resides or is to be created. + +<P> +<DT>proxy +<DD>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 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. + +<P> +<DT>gateway +<DD>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. + +<P> +<DT>tunnel +<DD>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. + +<P> +<DT>cache +<DD>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. +</DL> + + 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. +<P> + +<H3>1.3 <A NAME="Operation">Overall Operation</A></H3> + + 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 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. +<P> + + 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). +<P> + +<PRE> + request chain ------------------------> + UA -------------------v------------------- O + <----------------------- response chain +</PRE> + + 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. +<P> + +<PRE> + request chain --------------------------------------> + UA -----v----- A -----v----- B -----v----- C -----v----- O + <------------------------------------- response chain +</PRE> + + 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. +<P> + + 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 cached copy of an earlier response from O + (via C) for a request which has not been cached by UA or A. +<P> + +<PRE> + request chain ----------> + UA -----v----- A -----v----- B - - - - - - C - - - - - - O + <--------- response chain +</PRE> + + 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. +<P> + + On the Internet, HTTP communication generally takes place over TCP/IP connections. The + default port is TCP 80<A HREF="#RefIANA"> [15]</A>, 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. +<P> + + 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. +<P> + +<H3>1.4 <A NAME="HTTP-and-MIME">HTTP and MIME</A></H3> + + HTTP/1.0 uses many of the constructs defined for MIME, as defined in RFC 1521<A HREF="#RefMIME1"> [5]</A>. + <A HREF="#MIME">Appendix C</A> 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. +<P> + +<H2>2. <A NAME="Grammar">Notational Conventions and Generic Grammar</A></H2> + +<H3>2.1 <A NAME="Augmented-BNF">Augmented BNF</A></H3> + + 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<A HREF="#RefSTD11"> [7]</A>. Implementors will need to be + familiar with the notation in order to understand this specification. The augmented BNF + includes the following constructs: +<P> + +<DL> +<DT><CODE>name = definition</CODE> +<DD>The name of a rule is simply the name itself (without any enclosing <CODE>"<"</CODE> and <CODE>">"</CODE>) and is + separated from its definition by the equal character <CODE>"="</CODE>. 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 <CODE>SP</CODE>, <CODE>LWS</CODE>, <CODE>HT</CODE>, <CODE>CRLF</CODE>, <CODE>DIGIT</CODE>, + <CODE>ALPHA</CODE>, etc. Angle brackets are used within definitions whenever their presence will + facilitate discerning the use of rule names. + +<P> +<DT><CODE>"literal"</CODE> +<DD>Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive. + +<P> +<DT><CODE>rule1 | rule2</CODE> +<DD>Elements separated by a bar (<CODE>"I"</CODE>) are alternatives, e.g., <CODE>"yes | no"</CODE> will accept <CODE>yes</CODE> or <CODE>no</CODE>. + +<P> +<DT><CODE>(rule1 rule2)</CODE> +<DD>Elements enclosed in parentheses are treated as a single element. Thus, + <CODE>"(elem (foo | bar) elem)"</CODE> allows the token sequences <CODE>"elem foo elem"</CODE> and <CODE>"elem bar elem"</CODE>. + +<P> +<DT><CODE>*rule</CODE> +<DD>The character <CODE>"*"</CODE> preceding an element indicates repetition. The full form is + <CODE>"<n>*<m>element"</CODE> indicating at least <CODE><n></CODE> and at most <CODE><m></CODE> occurrences of <CODE>element</CODE>. Default + values are <CODE>0</CODE> and infinity so that <CODE>"*(element)"</CODE> allows any number, including zero; <CODE>"1*element"</CODE> + requires at least one; and <CODE>"1*2element"</CODE> allows one or two. + +<P> +<DT><CODE>[rule]</CODE> +<DD>Square brackets enclose optional elements; <CODE>"[foo bar]"</CODE> is equivalent to <CODE>"*1(foo bar)"</CODE>. + +<P> +<DT><EM>N</EM> <CODE>rule</CODE> +<DD>Specific repetition: <CODE>"<n>(element)"</CODE> is equivalent to <CODE>"<n>*<n>(element)"</CODE>; that is, exactly <CODE><n></CODE> + occurrences of <CODE>(element)</CODE>. Thus <CODE>2DIGIT</CODE> is a 2-digit number, and <CODE>3ALPHA</CODE> is a string of three + alphabetic characters. + +<P> +<DT><CODE>#rule</CODE> +<DD>A construct <CODE>"#"</CODE> is defined, similar to <CODE>"*"</CODE>, for defining lists of elements. The full form is + <CODE>"<n>#<m>element"</CODE> indicating at least <CODE><n></CODE> and at most <CODE><m></CODE> elements, each separated by one + or more commas (<CODE>","</CODE>) and optional linear whitespace (LWS). This makes the usual form of + lists very easy; a rule such as <CODE>"( *LWS element *( *LWS "," *LWS element ))</CODE>" can be shown as + <CODE>"1#element"</CODE>. Wherever this construct is used, null elements are allowed, but do not + contribute to the count of elements present. That is, <CODE>"(element), , (element)"</CODE> 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 <CODE>0</CODE> and infinity so that <CODE>"#(element)"</CODE> + allows any number, including zero; <CODE>"1#element"</CODE> requires at least one; and <CODE>"1#2element"</CODE> + allows one or two. + +<P> +<DT><CODE>; comment</CODE> +<DD>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. + +<P> +<DT><CODE>implied *LWS</CODE> +<DD>The grammar described by this specification is word-based. Except where noted otherwise, + linear whitespace (<CODE>LWS</CODE>) can be included between any two adjacent words (<CODE>token</CODE> or + <CODE>quoted-string</CODE>), and between adjacent tokens and delimiters (<CODE>tspecials</CODE>), without changing the + interpretation of a field. At least one delimiter (<CODE>tspecials</CODE>) 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. +</DL> + +<H3>2.2 <A NAME="Basic-Rules">Basic Rules</A></H3> + + The following rules are used throughout this specification to describe basic parsing constructs. + The US-ASCII coded character set is defined by<A HREF="#RefASCII"> [17]</A>. +<P> + +<PRE> + 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"> + 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)> +</PRE> + + HTTP/1.0 defines the octet sequence <CODE>CR LF</CODE> as the end-of-line marker for all protocol elements + except the <CODE>Entity-Body</CODE> (see <A HREF="#Tolerant">Appendix B</A> for tolerant applications). The end-of-line marker + within an <CODE>Entity-Body</CODE> is defined by its associated media type, as described in <A HREF="#Media-Types">Section 3.6</A>. +<P> + +<PRE> + CRLF = CR LF +</PRE> + + 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 <CODE>SP</CODE>. +<P> + +<PRE> + LWS = [CRLF] 1*( SP | HT ) +</PRE> + + However, folding of header lines is not expected by some applications, and should not be + generated by HTTP/1.0 applications. +<P> + + The <CODE>TEXT</CODE> rule is only used for descriptive field contents and values that are not intended to be + interpreted by the message parser. Words of <CODE>*TEXT</CODE> may contain octets from character sets other + than US-ASCII. +<P> + +<PRE> + TEXT = <any OCTET except CTLs, + but including LWS> +</PRE> + + Recipients of header field <CODE>TEXT</CODE> containing octets outside the US-ASCII character set may + assume that they represent ISO-8859-1 characters. +<P> + + Hexadecimal numeric characters are used in several protocol elements. +<P> + +<PRE> + HEX = "A" | "B" | "C" | "D" | "E" | "F" + | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT +</PRE> + + Many HTTP/1.0 header field values consist of words separated by <CODE>LWS</CODE> or special characters. + These special characters must be in a quoted string to be used within a parameter value. +<P> + +<PRE> + word = token | quoted-string +</PRE> + +<PRE> + token = 1*<any CHAR except CTLs or tspecials> +</PRE> + +<PRE> + tspecials = "(" | ")" | "<" | ">" | "@" + | "," | ";" | ":" | "\" | <"> + | "/" | "[" | "]" | "?" | "=" + | "{" | "}" | SP | HT +</PRE> + + Comments may be included in some HTTP header fields by surrounding the comment text with + parentheses. Comments are only allowed in fields containing "<CODE>comment</CODE>" as part of their field + value definition. In all other fields, parentheses are considered part of the field value. +<P> + +<PRE> + comment = "(" *( ctext | comment ) ")" + ctext = <any TEXT excluding "(" and ")"> +</PRE> + + A string of text is parsed as a single word if it is quoted using double-quote marks. +<P> + +<PRE> + quoted-string = ( <"> *(qdtext) <"> ) +</PRE> + +<PRE> + qdtext = <any CHAR except <"> and CTLs, + but including LWS> +</PRE> + + Single-character quoting using the backslash ("\") character is not permitted in HTTP/1.0. +<P> + +<H2>3. <A NAME="Protocol-Parameters">Protocol Parameters</A></H2> + +<H3>3.1 <A NAME="HTTP-Version">HTTP Version</A></H3> + + 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. +<P> + + The version of an HTTP message is indicated by an <CODE>HTTP-Version</CODE> 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 simple HTTP/0.9 format. +<P> + +<PRE> + HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT +</PRE> + + 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. +<P> + + This document defines both the 0.9 and 1.0 versions of the HTTP protocol. Applications + sending <CODE>Full-Request</CODE> or <CODE>Full-Response</CODE> messages, as defined by this specification, must include + an <CODE>HTTP-Version</CODE> of "<CODE>HTTP/1.0</CODE>". +<P> + +HTTP/1.0 servers must: +<UL> +<LI>recognize the format of the <CODE>Request-Line</CODE> for HTTP/0.9 and HTTP/1.0 requests; +<LI>understand any valid request in the format of HTTP/0.9 or HTTP/1.0; +<LI>respond appropriately with a message in the same protocol version used by the client. +</UL> + +HTTP/1.0 clients must: +<UL> +<LI>recognize the format of the <CODE>Status-Line</CODE> for HTTP/1.0 responses; +<LI>understand any valid response in the format of HTTP/0.9 or HTTP/1.0. +</UL> + + 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. +<P> + +<H3>3.2 <A NAME="URI">Uniform Resource Identifiers</A></H3> + + URIs have been known by many names: WWW addresses, Universal Document Identifiers, + Universal Resource Identifiers<A HREF="#RefURI"> [2]</A>, and finally the combination of Uniform Resource Locators + (URL)<A HREF="#RefURL"> [4]</A> and Names (URN)<A HREF="#RefURN"> [16]</A>. 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. +<P> + +<H4>3.2.1 <A NAME="URI-syntax">General Syntax</A></H4> + + URIs in HTTP can be represented in absolute form or relative to some known base URI<A HREF="#RefRelURL"> [9]</A>, + 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. +<P> + +<PRE> + URI = ( absoluteURI | relativeURI ) [ "#" fragment ] +</PRE> + +<PRE> + absoluteURI = scheme ":" *( uchar | reserved ) +</PRE> + +<PRE> + relativeURI = net_path | abs_path | rel_path +</PRE> + +<PRE> + net_path = "//" net_loc [ abs_path ] + abs_path = "/" rel_path + rel_path = [ path ] [ ";" params ] [ "?" query ] +</PRE> + +<PRE> + path = fsegment *( "/" segment ) + fsegment = 1*pchar + segment = *pchar +</PRE> + +<PRE> + params = param *( ";" param ) + param = *( pchar | "/" ) +</PRE> + +<PRE> + scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." ) + net_loc = *( pchar | ";" | "?" ) + query = *( uchar | reserved ) + fragment = *( uchar | reserved ) +</PRE> + +<PRE> + pchar = uchar | ":" | "@" | "&" | "=" | "+" + uchar = unreserved | escape + unreserved = ALPHA | DIGIT | safe | extra | national +</PRE> + +<PRE> + escape = "%" HEX HEX + reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" + extra = "!" | "*" | "'" | "(" | ")" | "," + safe = "$" | "-" | "_" | "." + unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">" + national = <any OCTET excluding ALPHA, DIGIT, + reserved, extra, safe, and unsafe> +</PRE> + + For definitive information on URL syntax and semantics, see RFC 1738<A HREF="#RefURL"> [4]</A> and RFC 1808<A HREF="#RefRelURL"> [9]</A>. + The BNF above includes <CODE>national</CODE> characters not allowed in valid URLs as specified by + RFC 1738, since HTTP servers are not restricted in the set of <CODE>unreserved</CODE> characters allowed to + represent the <CODE>rel_path</CODE> part of addresses, and HTTP proxies may receive requests for URIs not + defined by RFC 1738. +<P> + +<H4>3.2.2 <A NAME="http-URL">http URL</A></H4> + + 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. +<P> + +<PRE> + http_URL = "http:" "//" host [ ":" port ] [ abs_path ] +</PRE> + +<PRE> + host = <A legal Internet host domain name + or IP address (in dotted-decimal form), + as defined by Section 2.1 of RFC 1123> +</PRE> + +<PRE> + port = *DIGIT +</PRE> + + If the <CODE>port</CODE> 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 <CODE>port</CODE> of that <CODE>host</CODE>, and the + <CODE>Request-URI</CODE> for the resource is <CODE>abs_path</CODE>. If the <CODE>abs_path</CODE> is not present in the URL, it must be + given as "/" when used as a <CODE>Request-URI</CODE> (<A HREF="#Request-URI">Section 5.1.2</A>). +<P> + +<BLOCKQUOTE> + 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. +</BLOCKQUOTE> + + The canonical form for "http" URLs is obtained by converting any <CODE>UPALPHA</CODE> characters in <CODE>host</CODE> + to their <CODE>LOALPHA</CODE> equivalent (hostnames are case-insensitive), eliding the <CODE>[ ":" port ]</CODE> if the port + is 80, and replacing an empty <CODE>abs_path</CODE> with "/". +<P> + +<H3>3.3 <A NAME="DateFormats">Date/Time Formats</A></H3> + + HTTP/1.0 applications have historically allowed three different formats for the representation + of date/time stamps: +<P> + +<PRE> + 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 +</PRE> + + The first format is preferred as an Internet standard and represents a fixed-length subset of that + defined by RFC 1123<A HREF="#RefSTD3"> [6]</A> (an update to RFC 822<A HREF="#RefSTD11"> [7]</A>). The second format is in common use, but + is based on the obsolete RFC 850<A HREF="#RefUSENET"> [10]</A> 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. +<P> + +<BLOCKQUOTE> + 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. +</BLOCKQUOTE> + + 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. +<P> + +<PRE> + HTTP-date = rfc1123-date | rfc850-date | asctime-date +</PRE> + +<PRE> + 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 +</PRE> + +<PRE> + 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) +</PRE> + +<PRE> + time = 2DIGIT ":" 2DIGIT ":" 2DIGIT + ; 00:00:00 - 23:59:59 +</PRE> + +<PRE> + wkday = "Mon" | "Tue" | "Wed" + | "Thu" | "Fri" | "Sat" | "Sun" +</PRE> + +<PRE> + weekday = "Monday" | "Tuesday" | "Wednesday" + | "Thursday" | "Friday" | "Saturday" | "Sunday" +</PRE> + +<PRE> + month = "Jan" | "Feb" | "Mar" | "Apr" + | "May" | "Jun" | "Jul" | "Aug" + | "Sep" | "Oct" | "Nov" | "Dec" +</PRE> + +<BLOCKQUOTE> + 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 presentation, request logging, etc. +</BLOCKQUOTE> + +<H3>3.4 <A NAME="Charset">Character Sets</A></H3> + + HTTP uses the same definition of the term "character set" as that described for MIME: +<P> + +<BLOCKQUOTE> + 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. +</BLOCKQUOTE> + +<BLOCKQUOTE> + 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. +</BLOCKQUOTE> + + HTTP character sets are identified by case-insensitive tokens. The complete set of tokens are + defined by the IANA Character Set registry<A HREF="#RefIANA"> [15]</A>. 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<A HREF="#RefMIME1"> [5]</A> -- the US-ASCII<A HREF="#RefASCII"> [17]</A> + and ISO-8859<A HREF="#RefISO8859"> [18]</A> character sets -- + and other names specifically recommended for use within MIME charset parameters. +<P> + +<PRE> + 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 +</PRE> + + 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<A HREF="#RefIANA"> [15]</A> must represent the character set + defined by that registry. Applications should limit their use of character sets to those defined by + the IANA registry. +<P> + + 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. +<P> + +<H3>3.5 <A NAME="Content-Codings">Content Codings</A></H3> + + 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. +<P> + +<PRE> + content-coding = "x-gzip" | "x-compress" | token +</PRE> + +<BLOCKQUOTE> + Note: For future compatibility, HTTP/1.0 applications should consider "gzip" and + "compress" to be equivalent to "x-gzip" and "x-compress", respectively. +</BLOCKQUOTE> + + All <CODE>content-coding</CODE> values are case-insensitive. HTTP/1.0 uses <CODE>content-coding</CODE> values in the + <CODE>Content-Encoding</CODE> (<A HREF="#Content-Encoding">Section 10.3</A>) 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: +<P> + +<DL> +<DT><CODE>x-gzip</CODE> +<DD>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. + +<P> +<DT><CODE>x-compress</CODE> +<DD>The encoding format produced by the file compression program "compress". This format + is an adaptive Lempel-Ziv-Welch coding (LZW). +</DL> + +<BLOCKQUOTE> + 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. +</BLOCKQUOTE> + +<H3>3.6 <A NAME="Media-Types">Media Types</A></H3> + + HTTP uses Internet Media Types<A HREF="#RefMediaType"> [13]</A> in the <CODE>Content-Type</CODE> header field (<A HREF="#Content-Type">Section 10.5</A>) in order + to provide open and extensible data typing. +<P> + +<PRE> + media-type = type "/" subtype *( ";" parameter ) + type = token + subtype = token +</PRE> + + Parameters may follow the type/subtype in the form of attribute/value pairs. +<P> + +<PRE> + parameter = attribute "=" value + attribute = token + value = token | quoted-string +</PRE> + + 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. <CODE>LWS</CODE> 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. +<P> + + 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. +<P> + + Media-type values are registered with the Internet Assigned Number Authority (IANA<A HREF="#RefIANA"> [15]</A>). + The media type registration process is outlined in RFC 1590<A HREF="#RefMediaType"> [13]</A>. Use of non-registered media + types is discouraged. +<P> + +<H4>3.6.1 <A NAME="TextCanonicalization">Canonicalization and Text Defaults</A></H4> + + Internet media types are registered with a canonical form. In general, an <CODE>Entity-Body</CODE> transferred + via HTTP must be represented in the appropriate canonical form prior to its transmission. If the + body has been encoded with a <CODE>Content-Encoding</CODE>, the underlying data should be in canonical + form prior to being encoded. +<P> + + Media subtypes of the "text" type use <CODE>CRLF</CODE> as the text line break when in canonical form. + However, HTTP allows the transport of text media with plain <CODE>CR</CODE> or <CODE>LF</CODE> alone representing a line + break when used consistently within the <CODE>Entity-Body</CODE>. HTTP applications must accept <CODE>CRLF</CODE>, bare + <CODE>CR</CODE>, and bare <CODE>LF</CODE> as being representative of a line break in text media received via HTTP. +<P> + + In addition, if the text media is represented in a character set that does not use octets 13 and 10 + for <CODE>CR</CODE> and <CODE>LF</CODE> 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 + <CODE>CR</CODE> and <CODE>LF</CODE> for line breaks. This flexibility regarding line breaks applies only to text media in + the <CODE>Entity-Body</CODE>; a bare <CODE>CR</CODE> or <CODE>LF</CODE> should not be substituted for <CODE>CRLF</CODE> within any of the HTTP + control structures (such as header fields and multipart boundaries). +<P> + + The "charset" parameter is used with some media types to define the character set (<A HREF="#Charset">Section 3.4</A>) + 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. +<P> + +<BLOCKQUOTE> + 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. +</BLOCKQUOTE> + +<H4>3.6.2 <A NAME="Multipart">Multipart Types</A></H4> + + MIME provides for a number of "multipart" types -- encapsulations of several entities within + a single message's <CODE>Entity-Body</CODE>. The multipart types registered by IANA<A HREF="#RefIANA"> [15]</A> 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. +<P> + + 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 + <CODE>CRLF</CODE> to represent line breaks between body-parts. Multipart body-parts may contain HTTP + header fields which are significant to the meaning of that part. +<P> + +<H3>3.7 <A NAME="Product">Product Tokens</A></H3> + + 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 be listed, + separated by whitespace. By convention, the products are listed in order of their significance + for identifying the application. +<P> + +<PRE> + product = token ["/" product-version] + product-version = token +</PRE> + + Examples: +<P> + +<PRE> + User-Agent: CERN-LineMode/2.15 libwww/2.17b3 + + Server: Apache/0.8.4 +</PRE> + + 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 <CODE>product-version</CODE>, this token should only be used for a version identifier (i.e., successive versions + of the same product should only differ in the <CODE>product-version</CODE> portion of the <CODE>product</CODE> value). +<P> + +<H2>4. <A NAME="Message">HTTP Message</A></H2> + +<H3>4.1 <A NAME="Message-Types">Message Types</A></H3> + + HTTP messages consist of requests from client to server and responses from server to client. +<P> + +<PRE> + HTTP-message = Simple-Request ; HTTP/0.9 messages + | Simple-Response + | Full-Request ; HTTP/1.0 messages + | Full-Response +</PRE> + + <CODE>Full-Request</CODE> and <CODE>Full-Response</CODE> use the generic message format of RFC 822<A HREF="#RefSTD11"> [7]</A> 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 <CODE>CRLF</CODE>). +<P> + +<PRE> + Full-Request = Request-Line ; <A HREF="#Request-Line">Section 5.1</A> + *( General-Header ; <A HREF="#General-Header">Section 4.3</A> + | Request-Header ; <A HREF="#Request-Header">Section 5.2</A> + | Entity-Header ) ; <A HREF="#Entity-Header">Section 7.1</A> + CRLF + [ Entity-Body ] ; <A HREF="#Entity-Body">Section 7.2</A> +</PRE> + +<PRE> + Full-Response = Status-Line ; <A HREF="#Status-Line">Section 6.1</A> + *( General-Header ; <A HREF="#General-Header">Section 4.3</A> + | Response-Header ; <A HREF="#Response-Header">Section 6.2</A> + | Entity-Header ) ; <A HREF="#Entity-Header">Section 7.1</A> + CRLF + [ Entity-Body ] ; <A HREF="#Entity-Body">Section 7.2</A> +</PRE> + + <CODE>Simple-Request</CODE> and <CODE>Simple-Response</CODE> do not allow the use of any header information and are + limited to a single request method (<CODE>GET</CODE>). +<P> + +<PRE> + Simple-Request = "GET" SP Request-URI CRLF +</PRE> + +<PRE> + Simple-Response = [ Entity-Body ] +</PRE> + + Use of the <CODE>Simple-Request</CODE> format is discouraged because it prevents the server from identifying + the media type of the returned entity. +<P> + +<H3>4.2 <A NAME="Message-Headers">Message Headers</A></H3> + + HTTP header fields, which include <CODE>General-Header</CODE> (<A HREF="#General-Header">Section 4.3</A>), <CODE>Request-Header</CODE> (<A HREF="#Request-Header">Section 5.2</A>), + <CODE>Response-Header</CODE> (<A HREF="#Response-Header">Section 6.2</A>), and <CODE>Entity-Header</CODE> (<A HREF="#Entity-Header">Section 7.1</A>) fields, follow the same generic + format as that given in Section 3.1 of RFC 822<A HREF="#RefSTD11"> [7]</A>. Each header field consists of a name + followed immediately by a colon (<CODE>":"</CODE>), a single space (<CODE>SP</CODE>) 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 <CODE>SP</CODE> or <CODE>HT</CODE>, though this is not recommended. +<P> + +<PRE> + HTTP-header = field-name ":" [ field-value ] CRLF +</PRE> + +<PRE> + field-name = token + field-value = *( field-content | LWS ) +</PRE> + +<PRE> + field-content = <the OCTETs making up the field-value + and consisting of either *TEXT or combinations + of token, tspecials, and quoted-string> +</PRE> + + The order in which header fields are received is not significant. However, it is "good practice" + to send <CODE>General-Header</CODE> fields first, followed by <CODE>Request-Header</CODE> or <CODE>Response-Header</CODE> fields prior + to the <CODE>Entity-Header</CODE> fields. +<P> + + Multiple <CODE>HTTP-header</CODE> fields with the same <CODE>field-name</CODE> may be present in a message if and only + if the entire <CODE>field-value</CODE> for that header field is defined as a comma-separated list [i.e., <CODE>#(values)</CODE>]. + 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. +<P> + +<H3>4.3 <A NAME="General-Header">General Header Fields</A></H3> + + 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. +<P> + +<PRE> + General-Header = Date ; <A HREF="#Date">Section 10.6</A> + | Pragma ; <A HREF="#Pragma">Section 10.12</A> +</PRE> + + 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 <CODE>Entity-Header</CODE> fields. +<P> + +<H2>5. <A NAME="Request">Request</A></H2> + + 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: +<P> + +<PRE> + Request = Simple-Request | Full-Request +</PRE> + +<PRE> + Simple-Request = "GET" SP Request-URI CRLF +</PRE> + +<PRE> + Full-Request = Request-Line ; <A HREF="#Request-Line">Section 5.1</A> + *( General-Header ; <A HREF="#General-Header">Section 4.3</A> + | Request-Header ; <A HREF="#Request-Header">Section 5.2</A> + | Entity-Header ) ; <A HREF="#Entity-Header">Section 7.1</A> + CRLF + [ Entity-Body ] ; <A HREF="#Entity-Body">Section 7.2</A> +</PRE> + + If an HTTP/1.0 server receives a <CODE>Simple-Request</CODE>, it must respond with an HTTP/0.9 + <CODE>Simple-Response</CODE>. An HTTP/1.0 client capable of receiving a <CODE>Full-Response</CODE> should never + generate a <CODE>Simple-Request</CODE>. +<P> + +<H3>5.1 <A NAME="Request-Line">Request-Line</A></H3> + + The <CODE>Request-Line</CODE> begins with a method token, followed by the <CODE>Request-URI</CODE> and the protocol + version, and ending with <CODE>CRLF</CODE>. The elements are separated by <CODE>SP</CODE> characters. + No <CODE>CR</CODE> or <CODE>LF</CODE> are allowed except in the final <CODE>CRLF</CODE> sequence. +<P> + +<PRE> + Request-Line = Method SP Request-URI SP HTTP-Version CRLF +</PRE> + + Note that the difference between a <CODE>Simple-Request</CODE> and the <CODE>Request-Line</CODE> of a <CODE>Full-Request</CODE> is the + presence of the <CODE>HTTP-Version</CODE> field and the availability of methods other than <CODE>GET</CODE>. +<P> + +<H4>5.1.1 <A NAME="Method">Method</A></H4> + + The <CODE>Method</CODE> token indicates the method to be performed on the resource identified by the + <CODE>Request-URI</CODE>. The method is case-sensitive. +<P> + +<PRE> + Method = "GET" ; <A HREF="#GET">Section 8.1</A> + | "HEAD" ; <A HREF="#HEAD">Section 8.2</A> + | "POST" ; <A HREF="#POST">Section 8.3</A> + | extension-method +</PRE> + +<PRE> + extension-method = token +</PRE> + + 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. +<P> + + The methods commonly used by HTTP/1.0 applications are fully defined in <A HREF="#Methods">Section 8</A>. +<P> + +<H4>5.1.2 <A NAME="Request-URI">Request-URI</A></H4> + + The <CODE>Request-URI</CODE> is a Uniform Resource Identifier (<A HREF="#URI">Section 3.2</A>) and identifies the resource upon + which to apply the request. +<P> + +<PRE> + Request-URI = absoluteURI | abs_path +</PRE> + + The two options for <CODE>Request-URI</CODE> are dependent on the nature of the request. +<P> + + The <CODE>absoluteURI</CODE> 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 <CODE>GET</CODE> or <CODE>HEAD</CODE> and a + prior response is cached, the proxy may use the cached message if it passes any restrictions in + the <CODE>Expires</CODE> header field. Note that the proxy may forward the request on to another proxy or + directly to the server specified by the <CODE>absoluteURI</CODE>. 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 <CODE>Request-Line</CODE> would be: +<P> + +<PRE> + GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0 +</PRE> + + The most common form of <CODE>Request-URI</CODE> 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 <A HREF="#URI-syntax">Section 3.2.1</A>, + <CODE>abs_path</CODE>). 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: +<P> + +<PRE> + GET /pub/WWW/TheProject.html HTTP/1.0 +</PRE> + + followed by the remainder of the <CODE>Full-Request</CODE>. Note that the absolute path cannot be empty; if + none is present in the original URI, it must be given as "/" (the server root). +<P> + + The <CODE>Request-URI</CODE> is transmitted as an encoded string, where some characters may be escaped + using the "% HEX HEX" encoding defined by RFC 1738<A HREF="#RefURL"> [4]</A>. The origin server must decode + the <CODE>Request-URI</CODE> in order to properly interpret the request. +<P> + +<H3>5.2 <A NAME="Request-Header">Request Header Fields</A></H3> + + 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. +<P> + +<PRE> + Request-Header = Authorization ; <A HREF="#Authorization">Section 10.2</A> + | From ; <A HREF="#From">Section 10.8</A> + | If-Modified-Since ; <A HREF="#If-Modified-Since">Section 10.9</A> + | Referer ; <A HREF="#Referer">Section 10.13</A> + | User-Agent ; <A HREF="#User-Agent">Section 10.15</A> +</PRE> + + <CODE>Request-Header</CODE> 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 <CODE>Entity-Header</CODE> fields. +<P> + +<H2>6. <A NAME="Response">Response</A></H2> + + After receiving and interpreting a request message, a server responds in the form of an HTTP + response message. +<P> + +<PRE> + Response = Simple-Response | Full-Response +</PRE> + +<PRE> + Simple-Response = [ Entity-Body ] +</PRE> + +<PRE> + Full-Response = Status-Line ; <A HREF="#Status-Line">Section 6.1</A> + *( General-Header ; <A HREF="#General-Header">Section 4.3</A> + | Response-Header ; <A HREF="#Response-Header">Section 6.2</A> + | Entity-Header ) ; <A HREF="#Entity-Header">Section 7.1</A> + CRLF + [ Entity-Body ] ; <A HREF="#Entity-Body">Section 7.2</A> +</PRE> + + A <CODE>Simple-Response</CODE> should only be sent in response to an HTTP/0.9 <CODE>Simple-Request</CODE> or if the + server only supports the more limited HTTP/0.9 protocol. If a client sends an HTTP/1.0 + <CODE>Full-Request</CODE> and receives a response that does not begin with a <CODE>Status-Line</CODE>, it should assume that + the response is a <CODE>Simple-Response</CODE> and parse it accordingly. Note that the <CODE>Simple-Response</CODE> + consists only of the entity body and is terminated by the server closing the connection. +<P> + +<H3>6.1 <A NAME="Status-Line">Status-Line</A></H3> + + The first line of a <CODE>Full-Response</CODE> message is the <CODE>Status-Line</CODE>, consisting of the protocol version + followed by a numeric status code and its associated textual phrase, with each element + separated by <CODE>SP</CODE> characters. No <CODE>CR</CODE> or <CODE>LF</CODE> is allowed except in the final <CODE>CRLF</CODE> sequence. +<P> + +<PRE> + Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF +</PRE> + + Since a status line always begins with the protocol version and status code +<P> + +<PRE> + "HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP +</PRE> + + (e.g., <CODE>"HTTP/1.0 200 "</CODE>), the presence of that expression is sufficient to differentiate a + <CODE>Full-Response</CODE> from a <CODE>Simple-Response</CODE>. Although the <CODE>Simple-Response</CODE> 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 <CODE>Full-Request</CODE>, most HTTP/0.9 servers are limited to + responses of type "text/html" and therefore would never generate such a response. +<P> + +<H4>6.1.1 <A NAME="Status-Code">Status Code and Reason Phrase</A></H4> + + The <CODE>Status-Code</CODE> element is a 3-digit integer result code of the attempt to understand and satisfy + the request. The <CODE>Reason-Phrase</CODE> is intended to give a short textual description of the <CODE>Status-Code</CODE>. + The <CODE>Status-Code</CODE> is intended for use by automata and the <CODE>Reason-Phrase</CODE> is intended for the + human user. The client is not required to examine or display the <CODE>Reason-Phrase</CODE>. +<P> + + The first digit of the <CODE>Status-Code</CODE> defines the class of response. The last two digits do not have + any categorization role. There are 5 values for the first digit: +<P> + +<UL> +<LI>1xx: Informational - Not used, but reserved for future use +<LI>2xx: Success - The action was successfully received, understood, and accepted. +<LI>3xx: Redirection - Further action must be taken in order to complete the request +<LI>4xx: Client Error - The request contains bad syntax or cannot be fulfilled +<LI>5xx: Server Error - The server failed to fulfill an apparently valid request +</UL> + + The individual values of the numeric status codes defined for HTTP/1.0, and an example set of + corresponding <CODE>Reason-Phrase</CODE>'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 <A HREF="#Status-Codes">Section 9</A>. +<P> + +<PRE> + 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 +</PRE> + +<PRE> + extension-code = 3DIGIT +</PRE> + +<PRE> + Reason-Phrase = *<TEXT, excluding CR, LF> +</PRE> + + 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 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. +<P> + +<H3>6.2 <A NAME="Response-Header">Response Header Fields</A></H3> + + The response header fields allow the server to pass additional information about the response + which cannot be placed in the <CODE>Status-Line</CODE>. These header fields give information about the server + and about further access to the resource identified by the <CODE>Request-URI</CODE>. +<P> + +<PRE> + Response-Header = Location ; <A HREF="#Location">Section 10.11</A> + | Server ; <A HREF="#Server">Section 10.14</A> + | WWW-Authenticate ; <A HREF="#WWW-Authenticate">Section 10.16</A> +</PRE> + + <CODE>Response-Header</CODE> 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 <CODE>Entity-Header</CODE> fields. +<P> + +<H2>7. <A NAME="Entity">Entity</A></H2> + + <CODE>Full-Request</CODE> and <CODE>Full-Response</CODE> messages may transfer an entity within some requests and + responses. An entity consists of <CODE>Entity-Header</CODE> fields and (usually) an <CODE>Entity-Body</CODE>. In this section, + both <EM>sender</EM> and <EM>recipient</EM> refer to either the client or the server, depending on who sends and + who receives the entity. +<P> + +<H3>7.1 <A NAME="Entity-Header">Entity Header Fields</A></H3> + + <CODE>Entity-Header</CODE> fields define optional metainformation about the <CODE>Entity-Body</CODE> or, if no body is + present, about the resource identified by the request. +<P> + +<PRE> + Entity-Header = Allow ; <A HREF="#Allow">Section 10.1</A> + | Content-Encoding ; <A HREF="#Content-Encoding">Section 10.3</A> + | Content-Length ; <A HREF="#Content-Length">Section 10.4</A> + | Content-Type ; <A HREF="#Content-Type">Section 10.5</A> + | Expires ; <A HREF="#Expires">Section 10.7</A> + | Last-Modified ; <A HREF="#Last-Modified">Section 10.10</A> + | extension-header +</PRE> + +<PRE> + extension-header = HTTP-header +</PRE> + + The <CODE>extension-header</CODE> mechanism allows additional <CODE>Entity-Header</CODE> 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. +<P> + +<H3>7.2 <A NAME="Entity-Body">Entity Body</A></H3> + + The entity body (if any) sent with an HTTP request or response is in a format and encoding + defined by the <CODE>Entity-Header</CODE> fields. +<P> + +<PRE> + Entity-Body = *OCTET +</PRE> + + 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 <CODE>Content-Length</CODE> + header field in the request message headers. HTTP/1.0 requests containing an entity body must + include a valid <CODE>Content-Length</CODE> header field. +<P> + + 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 <CODE>HEAD</CODE> 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 <CODE>Content-Length</CODE> + header field defined with a value of zero (0). +<P> + +<H4>7.2.1 <A NAME="BodyType">Type</A></H4> + + When an <CODE>Entity-Body</CODE> is included with a message, the data type of that body is determined via + the header fields <CODE>Content-Type</CODE> and <CODE>Content-Encoding</CODE>. These define a two-layer, ordered + encoding model: +<P> + +<PRE> + entity-body := Content-Encoding( Content-Type( data ) ) +</PRE> + + A <CODE>Content-Type</CODE> specifies the media type of the underlying data. A <CODE>Content-Encoding</CODE> 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). +<P> + + Any HTTP/1.0 message containing an entity body should include a <CODE>Content-Type</CODE> header field + defining the media type of that body. If and <STRONG>only if</STRONG> the media type is not given by a <CODE>Content-Type</CODE> + header, as is the case for <CODE>Simple-Response</CODE> 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 + "<CODE>application/octet-stream</CODE>". +<P> + +<H4>7.2.2 <A NAME="BodyLength">Length</A></H4> + + When an <CODE>Entity-Body</CODE> is included with a message, the length of that body may be determined in + one of two ways. If a <CODE>Content-Length</CODE> header field is present, its value in bytes represents the + length of the <CODE>Entity-Body</CODE>. Otherwise, the body length is determined by the closing of the + connection by the server. +<P> + + 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 <CODE>Content-Length</CODE> header field. If a request contains an entity body + and <CODE>Content-Length</CODE> 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. + +<BLOCKQUOTE> + 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. +</BLOCKQUOTE> + +<H2>8. <A NAME="Methods">Method Definitions</A></H2> + + 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. +<P> + +<H3>8.1 <A NAME="GET">GET</A></H3> + + The <CODE>GET</CODE> method means retrieve whatever information (in the form of an entity) is identified by + the <CODE>Request-URI</CODE>. If the <CODE>Request-URI</CODE> 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. +<P> + + The semantics of the <CODE>GET</CODE> method changes to a "conditional <CODE>GET</CODE>" if the request message + includes an <CODE>If-Modified-Since</CODE> header field. A conditional <CODE>GET</CODE> method requests that the identified + resource be transferred only if it has been modified since the date given by the <CODE>If-Modified-Since</CODE> + header, as described in <A HREF="#If-Modified-Since">Section 10.9</A>. The conditional <CODE>GET</CODE> method is intended to reduce + network usage by allowing cached entities to be refreshed without requiring multiple requests + or transferring unnecessary data. +<P> + +<H3>8.2 <A NAME="HEAD">HEAD</A></H3> + + The <CODE>HEAD</CODE> method is identical to <CODE>GET</CODE> except that the server must not return any <CODE>Entity-Body</CODE> in + the response. The metainformation contained in the HTTP headers in response to a <CODE>HEAD</CODE> + request should be identical to the information sent in response to a <CODE>GET</CODE> request. This method + can be used for obtaining metainformation about the resource identified by the <CODE>Request-URI</CODE> + without transferring the <CODE>Entity-Body</CODE> itself. This method is often used for testing hypertext links + for validity, accessibility, and recent modification. +<P> + + There is no "conditional <CODE>HEAD</CODE>" request analogous to the conditional <CODE>GET</CODE>. If an <CODE>If-Modified-Since</CODE> + header field is included with a <CODE>HEAD</CODE> request, it should be ignored. +<P> + +<H3>8.3 <A NAME="POST">POST</A></H3> + + The <CODE>POST</CODE> 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 <CODE>Request-URI</CODE> in the <CODE>Request-Line</CODE>. + <CODE>POST</CODE> is designed to allow a uniform method to cover the following functions: +<P> + +<UL> +<LI>Annotation of existing resources; +<LI>Posting a message to a bulletin board, newsgroup, mailing list, or similar group of + articles; +<LI>Providing a block of data, such as the result of submitting a form<A HREF="#RefHTML"> [3]</A>, to a data-handling + process; +<LI>Extending a database through an append operation. +</UL> + + The actual function performed by the <CODE>POST</CODE> method is determined by the server and is usually + dependent on the <CODE>Request-URI</CODE>. 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. +<P> + + A successful <CODE>POST</CODE> 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 <CODE>POST</CODE> 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. +<P> + + 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. +<P> + + A valid <CODE>Content-Length</CODE> is required on all HTTP/1.0 <CODE>POST</CODE> 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. +<P> + + 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. +<P> + +<H2>9. <A NAME="Status-Codes">Status Code Definitions</A></H2> + + Each <CODE>Status-Code</CODE> is described below, including a description of which <CODE>method</CODE>(s) it can follow + and any metainformation required in the response. +<P> + +<H3>9.1 <A NAME="Code1xx">Informational 1xx</A></H3> + + This class of status code indicates a provisional response, consisting only of the <CODE>Status-Line</CODE> 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. +<P> + +<H3>9.2 <A NAME="Code2xx">Successful 2xx</A></H3> + + This class of status code indicates that the client's request was successfully received, + understood, and accepted. +<P> + +<H4> <A NAME="Code200">200 OK</A></H4> + + The request has succeeded. The information returned with the response is dependent on the + method used in the request, as follows: +<P> + +<DL COMPACT> +<DT><CODE>GET</CODE> +<DD>an entity corresponding to the requested resource is sent in the response; + +<DT><CODE>HEAD</CODE> +<DD>the response must only contain the header information and no <CODE>Entity-Body</CODE>; + +<DT><CODE>POST</CODE> +<DD>an entity describing or containing the result of the action. +</DL> + +<H4> <A NAME="Code201">201 Created</A></H4> + + 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 <CODE>Status-Code</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). +<P> + + Of the methods defined by this specification, only <CODE>POST</CODE> can create a resource. +<P> + +<H4> <A NAME="Code202">202 Accepted</A></H4> + + 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. +<P> + + 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. +<P> + +<H4> <A NAME="Code204">204 No Content</A></H4> + + 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 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. +<P> + +<H3>9.3 <A NAME="Code3xx">Redirection 3xx</A></H3> + + 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 <CODE>GET</CODE> or + <CODE>HEAD</CODE>. A user agent should never automatically redirect a request more than 5 times, since such + redirections usually indicate an infinite loop. +<P> + +<H4> <A NAME="Code300">300 Multiple Choices</A></H4> + + This response code is not directly used by HTTP/1.0 applications, but serves as the default for + interpreting the 3xx class of responses. +<P> + + The requested resource is available at one or more locations. Unless it was a <CODE>HEAD</CODE> 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 <CODE>Location</CODE> field; user agents may use this field + value for automatic redirection. +<P> + +<H4> <A NAME="Code301">301 Moved Permanently</A></H4> + + 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 <CODE>Request-URI</CODE> to the new reference returned by the server, + where possible. +<P> + + The new URL must be given by the <CODE>Location</CODE> field in the response. Unless it was a <CODE>HEAD</CODE> request, + the <CODE>Entity-Body</CODE> of the response should contain a short note with a hyperlink to the new URL. +<P> + + If the 301 status code is received in response to a request using the <CODE>POST</CODE> 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. +<P> + +<BLOCKQUOTE> + 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. +</BLOCKQUOTE> + +<H4> <A NAME="Code302">302 Moved Temporarily</A></H4> + + The requested resource resides temporarily under a different URL. Since the redirection may + be altered on occasion, the client should continue to use the <CODE>Request-URI</CODE> for future requests. +<P> + + The URL must be given by the <CODE>Location</CODE> field in the response. Unless it was a <CODE>HEAD</CODE> request, the + <CODE>Entity-Body</CODE> of the response should contain a short note with a hyperlink to the new URI(s). +<P> + + If the 302 status code is received in response to a request using the <CODE>POST</CODE> 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. +<P> + +<BLOCKQUOTE> + 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. +</BLOCKQUOTE> + +<H4> <A NAME="Code304">304 Not Modified</A></H4> + + If the client has performed a conditional <CODE>GET</CODE> request and access is allowed, but the document + has not been modified since the date and time specified in the <CODE>If-Modified-Since</CODE> field, the server + must respond with this status code and not send an <CODE>Entity-Body</CODE> 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 <CODE>Last-Modified</CODE> date. Examples of + relevant header fields include: <CODE>Date</CODE>, <CODE>Server</CODE>, and <CODE>Expires</CODE>. A cache should update its cached entity + to reflect any new field values given in the 304 response. +<P> + +<H3>9.4 <A NAME="Code4xx">Client Error 4xx</A></H3> + + 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 <CODE>HEAD</CODE> 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. +<P> + +<BLOCKQUOTE> + 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. +</BLOCKQUOTE> + +<H4> <A NAME="Code400">400 Bad Request</A></H4> + + The request could not be understood by the server due to malformed syntax. The client should + not repeat the request without modifications. +<P> + +<H4> <A NAME="Code401">401 Unauthorized</A></H4> + + The request requires user authentication. The response must include a <CODE>WWW-Authenticate</CODE> + header field (<A HREF="#WWW-Authenticate">Section 10.16</A>) containing a <CODE>challenge</CODE> applicable to the requested resource. The + client may repeat the request with a suitable <CODE>Authorization</CODE> header field (<A HREF="#Authorization">Section 10.2</A>). 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 <A HREF="#AA">Section 11</A>. +<P> + +<H4> <A NAME="Code403">403 Forbidden</A></H4> + + 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 <CODE>HEAD</CODE> 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. +<P> + +<H4> <A NAME="Code404">404 Not Found</A></H4> + + The server has not found anything matching the <CODE>Request-URI</CODE>. 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. +<P> + +<H3>9.5 <A NAME="Code5xx">Server Error 5xx</A></H3> + + 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 <CODE>HEAD</CODE> 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. +<P> + +<H4> <A NAME="Code500">500 Internal Server Error</A></H4> + + The server encountered an unexpected condition which prevented it from fulfilling the request. +<P> + +<H4> <A NAME="Code501">501 Not Implemented</A></H4> + + 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. +<P> + +<H4> <A NAME="Code502">502 Bad Gateway</A></H4> + + 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. +<P> + +<H4> <A NAME="Code503">503 Service Unavailable</A></H4> + + 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. + +<BLOCKQUOTE> + 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. +</BLOCKQUOTE> + +<H2>10. <A NAME="HeaderFields">Header Field Definitions</A></H2> + + This section defines the syntax and semantics of all commonly used HTTP/1.0 header fields. + For general and entity header fields, both <EM>sender </EM>and<EM> recipient</EM> refer to either the client or the + server, depending on who sends and who receives the message. +<P> + +<H3>10.1 <A NAME="Allow">Allow</A></H3> + + The <CODE>Allow</CODE> entity-header field lists the set of methods supported by the resource identified by the + <CODE>Request-URI</CODE>. The purpose of this field is strictly to inform the recipient of valid methods + associated with the resource. The <CODE>Allow</CODE> header field is not permitted in a request using the <CODE>POST</CODE> + method, and thus should be ignored if it is received as part of a <CODE>POST</CODE> entity. +<P> + +<PRE> + Allow = "Allow" ":" 1#method +</PRE> + + Example of use: +<P> + +<PRE> + Allow: GET, HEAD +</PRE> + + This field cannot prevent a client from trying other methods. However, the indications given by + the <CODE>Allow</CODE> header field value should be followed. The actual set of allowed methods is defined + by the origin server at the time of each request. +<P> + + A proxy must not modify the <CODE>Allow</CODE> 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. +<P> + + The <CODE>Allow</CODE> header field does not indicate what methods are implemented by the server. +<P> + +<H3>10.2 <A NAME="Authorization">Authorization</A></H3> + + 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 <CODE>Authorization</CODE> request-header field with + the request. The <CODE>Authorization</CODE> field value consists of <CODE>credentials</CODE> containing the authentication + information of the user agent for the realm of the resource being requested. +<P> + +<PRE> + Authorization = "Authorization" ":" credentials +</PRE> + + HTTP access authentication is described in <A HREF="#AA">Section 11</A>. If a request is authenticated and a <CODE>realm</CODE> + specified, the same <CODE>credentials</CODE> should be valid for all other requests within this <CODE>realm</CODE>. +<P> + + Responses to requests containing an <CODE>Authorization</CODE> field are not cachable. +<P> + +<H3>10.3 <A NAME="Content-Encoding">Content-Encoding</A></H3> + + The <CODE>Content-Encoding</CODE> entity-header field is used as a modifier to the <CODE>media-type</CODE>. 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 <CODE>media-type</CODE> referenced by the + <CODE>Content-Type</CODE> header field. The <CODE>Content-Encoding</CODE> is primarily used to allow a document to be + compressed without losing the identity of its underlying media type. +<P> + +<PRE> + Content-Encoding = "Content-Encoding" ":" content-coding +</PRE> + + Content codings are defined in <A HREF="#Content-Codings">Section 3.5</A>. An example of its use is +<P> + +<PRE> + Content-Encoding: x-gzip +</PRE> + + The <CODE>Content-Encoding</CODE> is a characteristic of the resource identified by the <CODE>Request-URI</CODE>. Typically, + the resource is stored with this encoding and is only decoded before rendering or analogous + usage. +<P> + +<H3>10.4 <A NAME="Content-Length">Content-Length</A></H3> + + The <CODE>Content-Length</CODE> entity-header field indicates the size of the <CODE>Entity-Body</CODE>, in decimal number + of octets, sent to the recipient or, in the case of the <CODE>HEAD</CODE> method, the size of the <CODE>Entity-Body</CODE> that + would have been sent had the request been a <CODE>GET</CODE>. +<P> + +<PRE> + Content-Length = "Content-Length" ":" 1*DIGIT +</PRE> + + An example is +<P> + +<PRE> + Content-Length: 3495 +</PRE> + + Applications should use this field to indicate the size of the <CODE>Entity-Body</CODE> to be transferred, + regardless of the media type of the entity. A valid <CODE>Content-Length</CODE> field value is required on all + HTTP/1.0 request messages containing an entity body. +<P> + + Any <CODE>Content-Length</CODE> greater than or equal to zero is a valid value. <A HREF="#BodyLength">Section 7.2.2</A> describes how + to determine the length of a response entity body if a <CODE>Content-Length</CODE> is not given. +<P> + +<BLOCKQUOTE> + 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. +</BLOCKQUOTE> + +<H3>10.5 <A NAME="Content-Type">Content-Type</A></H3> + + The <CODE>Content-Type</CODE> entity-header field indicates the media type of the <CODE>Entity-Body</CODE> sent to the + recipient or, in the case of the <CODE>HEAD</CODE> method, the media type that would have been sent had the + request been a <CODE>GET</CODE>. +<P> + +<PRE> + Content-Type = "Content-Type" ":" media-type +</PRE> + + Media types are defined in <A HREF="#Media-Types">Section 3.6</A>. An example of the field is +<P> + +<PRE> + Content-Type: text/html +</PRE> + + Further discussion of methods for identifying the media type of an entity is provided in + <A HREF="#BodyType">Section 7.2.1</A>. +<P> + +<H3>10.6 <A NAME="Date">Date</A></H3> + + The <CODE>Date</CODE> general-header field represents the date and time at which the message was originated, + having the same semantics as <CODE>orig-date</CODE> in RFC 822. The field value is an <CODE>HTTP-date</CODE>, as + described in <A HREF="#DateFormats">Section 3.3</A>. +<P> + +<PRE> + Date = "Date" ":" HTTP-date +</PRE> + + An example is +<P> + +<PRE> + Date: Tue, 15 Nov 1994 08:12:31 GMT +</PRE> + + 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 <CODE>Date</CODE> header. Clients should + only send a <CODE>Date</CODE> header field in messages that include an entity body, as in the case of the <CODE>POST</CODE> + request, and even then it is optional. A received message which does not have a <CODE>Date</CODE> 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 <CODE>Date</CODE>. +<P> + + 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. +<P> + +<BLOCKQUOTE> + Note: An earlier version of this document incorrectly specified that this field should + contain the creation date of the enclosed <CODE>Entity-Body</CODE>. This has been changed to reflect + actual (and proper) usage. +</BLOCKQUOTE> + +<H3>10.7 <A NAME="Expires">Expires</A></H3> + + The <CODE>Expires</CODE> 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 <CODE>HTTP-date</CODE> in <A HREF="#DateFormats">Section 3.3</A>. +<P> + +<PRE> + Expires = "Expires" ":" HTTP-date +</PRE> + + An example of its use is +<P> + +<PRE> + Expires: Thu, 01 Dec 1994 16:00:00 GMT +</PRE> + + If the date given is equal to or earlier than the value of the <CODE>Date</CODE> 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. +<P> + + 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. +<P> + + 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 <CODE>Expires</CODE> 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. +<P> + +<BLOCKQUOTE> + 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. +</BLOCKQUOTE> + +<H3>10.8 <A NAME="From">From</A></H3> + + The <CODE>From</CODE> 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 <CODE>mailbox</CODE> in RFC 822<A HREF="#RefSTD11"> [7]</A> (as updated by RFC 1123<A HREF="#RefSTD3"> [6]</A>): +<P> + +<PRE> + From = "From" ":" mailbox +</PRE> + + An example is: +<P> + +<PRE> + From: [email protected] +</PRE> + + 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 <CODE>method</CODE> 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. +<P> + + 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. +<P> + +<BLOCKQUOTE> + Note: The client should not send the <CODE>From</CODE> 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. +</BLOCKQUOTE> + +<H3>10.9 <A NAME="If-Modified-Since">If-Modified-Since</A></H3> + + The <CODE>If-Modified-Since</CODE> request-header field is used with the <CODE>GET</CODE> 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 <CODE>Entity-Body</CODE>. +<P> + +<PRE> + If-Modified-Since = "If-Modified-Since" ":" HTTP-date +</PRE> + + An example of the field is: + +<PRE> + If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT +</PRE> + + A conditional <CODE>GET</CODE> method requests that the identified resource be transferred only if it has been + modified since the date given by the <CODE>If-Modified-Since</CODE> header. The algorithm for determining this + includes the following cases: +<P> + +<DL COMPACT> +<DT>a) +<DD>If the request would normally result in anything other than a 200 (ok) status, or if + the passed <CODE>If-Modified-Since</CODE> date is invalid, the response is exactly the same as for a + normal <CODE>GET</CODE>. A date which is later than the server's current time is invalid. + +<DT>b) +<DD>If the resource has been modified since the <CODE>If-Modified-Since</CODE> date, the response is + exactly the same as for a normal <CODE>GET</CODE>. + +<DT>c) +<DD>If the resource has not been modified since a valid <CODE>If-Modified-Since</CODE> date, the server + shall return a 304 (not modified) response. +</DL> + + The purpose of this feature is to allow efficient updates of cached information with a minimum + amount of transaction overhead. +<P> + +<H3>10.10 <A NAME="Last-Modified">Last-Modified</A></H3> + + The <CODE>Last-Modified</CODE> 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 <CODE>Last-Modified</CODE> field, that copy should be considered stale. +<P> + +<PRE> + Last-Modified = "Last-Modified" ":" HTTP-date +</PRE> + + An example of its use is +<P> + +<PRE> + Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT +</PRE> + + 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. +<P> + + 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 future, the server must replace that date with the message origination date. +<P> + +<H3>10.11 <A NAME="Location">Location</A></H3> + + The Location response-header field defines the exact location of the resource that was identified + by the <CODE>Request-URI</CODE>. For 3xx responses, the location must indicate the server's preferred URL + for automatic redirection to the resource. Only one absolute URL is allowed. +<P> + +<PRE> + Location = "Location" ":" absoluteURI +</PRE> + + An example is +<P> + +<PRE> + Location: http://www.w3.org/hypertext/WWW/NewLocation.html +</PRE> + +<H3>10.12 <A NAME="Pragma">Pragma</A></H3> + + The <CODE>Pragma</CODE> 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. +<P> + +<PRE> + Pragma = "Pragma" ":" 1#pragma-directive +</PRE> + +<PRE> + pragma-directive = "no-cache" | extension-pragma + extension-pragma = token [ "=" word ] +</PRE> + + When the "<CODE>no-cache</CODE>" 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. +<P> + + 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. +<P> + +<H3>10.13 <A NAME="Referer">Referer</A></H3> + + The <CODE>Referer</CODE> request-header field allows the client to specify, for the server's benefit, the address + (URI) of the resource from which the <CODE>Request-URI</CODE> was obtained. This allows a server to + generate lists of back-links to resources for interest, logging, optimized caching, etc. It also + allows obsolete or mistyped links to be traced for maintenance. The <CODE>Referer</CODE> field must not be + sent if the <CODE>Request-URI</CODE> was obtained from a source that does not have its own URI, such as input + from the user keyboard. +<P> + +<PRE> + Referer = "Referer" ":" ( absoluteURI | relativeURI ) +</PRE> + + Example: +<P> + +<PRE> + Referer: http://www.w3.org/hypertext/DataSources/Overview.html +</PRE> + + If a partial URI is given, it should be interpreted relative to the <CODE>Request-URI</CODE>. The URI must not + include a fragment. +<P> + +<BLOCKQUOTE> + 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 <CODE>Referer</CODE> 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 <CODE>Referer</CODE> and <CODE>From</CODE> information. +</BLOCKQUOTE> + +<H3>10.14 <A NAME="Server">Server</A></H3> + + The <CODE>Server</CODE> response-header field contains information about the software used by the origin + server to handle the request. The field can contain multiple product tokens (<A HREF="#Product">Section 3.7</A>) 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. +<P> + +<PRE> + Server = "Server" ":" 1*( product | comment ) +</PRE> + + Example: +<P> + +<PRE> + Server: CERN/3.0 libwww/2.17 +</PRE> + + If the response is being forwarded through a proxy, the proxy application must not add its data + to the product list. +<P> + +<BLOCKQUOTE> + 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. +</BLOCKQUOTE> + +<BLOCKQUOTE> + Note: Some existing servers fail to restrict themselves to the product token syntax + within the Server field. +</BLOCKQUOTE> + +<H3>10.15 <A NAME="User-Agent">User-Agent</A></H3> + + The <CODE>User-Agent</CODE> 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 (<A HREF="#Product">Section 3.7</A>) 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. +<P> + +<PRE> + User-Agent = "User-Agent" ":" 1*( product | comment ) +</PRE> + + Example: +<P> + +<PRE> + User-Agent: CERN-LineMode/2.15 libwww/2.17b3 +</PRE> + +<BLOCKQUOTE> + 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. +</BLOCKQUOTE> + +<BLOCKQUOTE> + Note: Some existing clients fail to restrict themselves to the product token syntax + within the User-Agent field. +</BLOCKQUOTE> + +<H3>10.16 <A NAME="WWW-Authenticate">WWW-Authenticate</A></H3> + + The <CODE>WWW-Authenticate</CODE> response-header field must be included in 401 (unauthorized) response + messages. The field value consists of at least one <CODE>challenge</CODE> that indicates the authentication + scheme(s) and parameters applicable to the <CODE>Request-URI</CODE>. +<P> + +<PRE> + WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge +</PRE> + + The HTTP access authentication process is described in <A HREF="#AA">Section 11</A>. User agents must take + special care in parsing the <CODE>WWW-Authenticate</CODE> field value if it contains more than one challenge, + or if more than one <CODE>WWW-Authenticate</CODE> header field is provided, since the contents of a challenge + may itself contain a comma-separated list of authentication parameters. +<P> + +<H2>11. <A NAME="AA">Access Authentication</A></H2> + + 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. +<P> + +<PRE> + auth-scheme = token +</PRE> + +<PRE> + auth-param = token "=" quoted-string +</PRE> + + The 401 (unauthorized) response message is used by an origin server to challenge the + authorization of a user agent. This response must include a <CODE>WWW-Authenticate</CODE> header field + containing at least one <CODE>challenge</CODE> applicable to the requested resource. +<P> + +<PRE> + challenge = auth-scheme 1*SP realm *( "," auth-param ) +</PRE> + +<PRE> + realm = "realm" "=" realm-value + realm-value = quoted-string +</PRE> + + 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. +<P> + + 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 <CODE>Authorization</CODE> header field with the + request. The <CODE>Authorization</CODE> field value consists of <CODE>credentials</CODE> containing the authentication + information of the user agent for the realm of the resource being requested. +<P> + +<PRE> + credentials = basic-credentials + | ( auth-scheme #auth-param ) +</PRE> + + 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 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. +<P> + + If the server does not wish to accept the credentials sent with a request, it should return a 403 + (forbidden) response. +<P> + + 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. +<P> + + Proxies must be completely transparent regarding user agent authentication. That is, they must + forward the <CODE>WWW-Authenticate</CODE> and <CODE>Authorization</CODE> headers untouched, and must not cache the + response to a request containing <CODE>Authorization</CODE>. HTTP/1.0 does not provide a means for a client + to be authenticated with a proxy. +<P> + +<H3>11.1 <A NAME="BasicAA">Basic Authentication Scheme</A></H3> + + 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 <CODE>Request-URI</CODE>. There are no optional authentication parameters. +<P> + + Upon receipt of an unauthorized request for a URI within the protection space, the server + should respond with a challenge like the following: +<P> + +<PRE> + WWW-Authenticate: Basic realm="WallyWorld" +</PRE> + + where "WallyWorld" is the string assigned by the server to identify the protection space of the + <CODE>Request-URI</CODE>. +<P> + + To receive authorization, the client sends the user-ID and password, separated by a single colon + (":") character, within a base64<A HREF="#RefMIME1"> [5]</A> encoded string in the <CODE>credentials</CODE>. +<P> + +<PRE> + basic-credentials = "Basic" SP basic-cookie +</PRE> + +<PRE> + basic-cookie = <base64<A HREF="#RefMIME1"> [5]</A> encoding of userid-password, + except not limited to 76 char/line> +</PRE> + +<PRE> + userid-password = [ token ] ":" *TEXT +</PRE> + + If the user agent wishes to send the user-ID "Aladdin" and password "open sesame", it would + use the following header field: +<P> + +<PRE> + Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== +</PRE> + + 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. +<P> + +<H2>12. <A NAME="Security">Security Considerations</A></H2> + + 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. +<P> + +<H3>12.1 <A NAME="AuthSecurity">Authentication of Clients</A></H3> + + As mentioned in <A HREF="#BasicAA">Section 11.1</A>, the Basic authentication scheme is not a secure method of user + authentication, nor does it prevent the <CODE>Entity-Body</CODE> 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. +<P> + +<H3>12.2 <A NAME="SafeMethods">Safe Methods</A></H3> + + 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. +<P> + + In particular, the convention has been established that the <CODE>GET</CODE> and <CODE>HEAD</CODE> 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 <CODE>POST</CODE>, in a + special way, so that the user is made aware of the fact that a possibly unsafe action is being + requested. +<P> + + Naturally, it is not possible to ensure that the server does not generate side-effects as a result of + performing a <CODE>GET</CODE> 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. +<P> + +<H3>12.3 <A NAME="LogAbuse">Abuse of Server Log Information</A></H3> + + 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. +<P> + +<H3>12.4 <A NAME="Sensitive">Transfer of Sensitive Information</A></H3> + + 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: <CODE>Server</CODE>, <CODE>Referer</CODE> and <CODE>From</CODE>. +<P> + + 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 <CODE>Server</CODE> header field a configurable option. +<P> + + The <CODE>Referer</CODE> 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 <CODE>Referer</CODE>. Even when the personal information has been removed, the <CODE>Referer</CODE> + field may indicate a private document's URI whose publication would be inappropriate. +<P> + + The information sent in the <CODE>From</CODE> 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. +<P> + + We suggest, though do not require, that a convenient toggle interface be provided for the user + to enable or disable the sending of <CODE>From</CODE> and <CODE>Referer</CODE> information. +<P> + +<H3>12.5 <A NAME="PathNameSecurity">Attacks Based On File and Path Names</A></H3> + + 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 <CODE>Request-URI</CODE> 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. +<P> + +<H2>13. <A NAME="Acknowledgments">Acknowledgments</A></H2> + + This specification makes heavy use of the augmented BNF and generic constructs defined by + David H. Crocker for RFC 822<A HREF="#RefSTD11"> [7]</A>. Similarly, it reuses many of the definitions provided by + Nathaniel Borenstein and Ned Freed for MIME<A HREF="#RefMIME1"> [5]</A>. 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. +<P> + + 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 + <EM>www-talk</EM> 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, Håkon 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. +<P> + + Paul Hoffman contributed sections regarding the informational status of this document and + Appendices C and D. +<P> + + 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: +<P> + +<PRE> + 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 + François Yergeau Mary Ellen Zurko + Jean-Philippe Martin-Flatin +</PRE> + +<H2>14. <A NAME="References">References</A></H2> + +<DL COMPACT> +<DT>[1] +<DD><A NAME="RefGopher">Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D., and B. Alberti</A>, + <A HREF="http://ds.internic.net/rfc/rfc1436.txt">"The Internet Gopher Protocol: + A distributed document search and retrieval protocol"</A>, + RFC 1436, University of Minnesota, March 1993. + +<DT>[2] +<DD><A NAME="RefURI">Berners-Lee, T.</A>, + <A HREF="http://ds.internic.net/rfc/rfc1630.txt">"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"</A>, RFC 1630, CERN, June 1994. + +<DT>[3] +<DD><A NAME="RefHTML">Berners-Lee, T., and D. Connolly</A>, + <A HREF="http://ds.internic.net/rfc/rfc1866.txt">"Hypertext Markup Language - 2.0"</A>, + RFC 1866, MIT/W3C, November 1995. + +<DT>[4] +<DD><A NAME="RefURL">Berners-Lee, T., Masinter, L., and M. McCahill</A>, + <A HREF="http://ds.internic.net/rfc/rfc1738.txt">"Uniform Resource Locators (URL)"</A>, + RFC 1738, CERN, Xerox PARC, University of Minnesota, December 1994. + +<DT>[5] +<DD><A NAME="RefMIME1">Borenstein, N., and N. Freed</A>, + <A HREF="http://ds.internic.net/rfc/rfc1521.ps">"MIME (Multipurpose Internet Mail Extensions) Part One: + Mechanisms for Specifying and Describing the Format of Internet Message Bodies"</A>, + RFC 1521, Bellcore, Innosoft, September 1993. + +<DT>[6] +<DD><A NAME="RefSTD3">Braden, R.</A>, + <A HREF="http://ds.internic.net/std/std3.txt">"Requirements for Internet hosts - application and support"</A>, + STD 3, RFC 1123, IETF, October 1989. + +<DT>[7] +<DD><A NAME="RefSTD11">Crocker, D.</A>, + <A HREF="http://ds.internic.net/std/std11.txt">"Standard for the Format of ARPA Internet Text Messages"</A>, + STD 11, RFC 822, UDEL, August 1982. + +<DT>[8] +<DD><A NAME="RefWAIS">F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang, J. Sui, and M. Grinbaum</A>. + "WAIS Interface Protocol Prototype Functional Specification." (v1.5), Thinking + Machines Corporation, April 1990. + +<DT>[9] +<DD><A NAME="RefRelURL">Fielding, R.</A>, + <A HREF="http://ds.internic.net/rfc/rfc1808.txt">"Relative Uniform Resource Locators"</A>, + RFC 1808, UC Irvine, June 1995. + +<DT>[10] +<DD><A NAME="RefUSENET">Horton, M., and R. Adams</A>, + <A HREF="http://ds.internic.net/rfc/rfc1036.txt">"Standard for interchange of USENET messages"</A>, + RFC 1036 (Obsoletes RFC 850), AT&T Bell Laboratories, Center for Seismic Studies, December 1987. + +<DT>[11] +<DD><A NAME="RefNNTP">Kantor, B., and P. Lapsley</A>, + <A HREF="http://ds.internic.net/rfc/rfc977.txt">"Network News Transfer Protocol: + A Proposed Standard for the Stream-Based Transmission of News"</A>, + RFC 977, UC San Diego, UC Berkeley, February 1986. + +<DT>[12] +<DD><A NAME="RefSMTP">Postel, J.</A>, + <A HREF="http://ds.internic.net/std/std10.txt">"Simple Mail Transfer Protocol"</A>, + STD 10, RFC 821, USC/ISI, August 1982. + +<DT>[13] +<DD><A NAME="RefMediaType">Postel, J.</A>, + <A HREF="http://ds.internic.net/rfc/rfc1590.txt">"Media Type Registration Procedure"</A>, + RFC 1590, USC/ISI, March 1994. + +<DT>[14] +<DD><A NAME="RefFTP">Postel, J., and J. Reynolds</A>, + <A HREF="http://ds.internic.net/std/std9.txt">"File Transfer Protocol (FTP)"</A>, + STD 9, RFC 959, USC/ISI, October 1985. + +<DT>[15] +<DD><A NAME="RefIANA">Reynolds, J., and J. Postel</A>, + <A HREF="http://ds.internic.net/std/std2.txt">"Assigned Numbers"</A>, + STD 2, RFC 1700, USC/ISI, October 1994. + +<DT>[16] +<DD><A NAME="RefURN">Sollins, K., and L. Masinter</A>, + <A HREF="http://ds.internic.net/rfc/rfc1737.txt">"Functional Requirements for Uniform Resource Names."</A> + RFC 1737, MIT/LCS, Xerox Corporation, December 1994. + +<DT>[17] +<DD><A NAME="RefASCII">US-ASCII</A>. + Coded Character Set - 7-Bit American Standard Code for Information + Interchange. Standard ANSI X3.4-1986, ANSI, 1986. + +<DT>[18] +<DD><A NAME="RefISO8859">ISO-8859</A>. + International Standard -- Information Processing --<BR> + 8-bit Single-Byte Coded Graphic Character Sets --<BR> + Part 1: Latin alphabet No. 1, ISO 8859-1:1987.<BR> + Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.<BR> + Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.<BR> + Part 4: Latin alphabet No. 4, ISO 8859-4, 1988.<BR> + Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.<BR> + Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.<BR> + Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.<BR> + Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.<BR> + Part 9: Latin alphabet No. 5, ISO 8859-9, 1990. +</DL> + +<H2>15. <A NAME="Authors">Authors' Addresses</A></H2> + + <STRONG>Tim Berners-Lee</STRONG><BR> + Director, W3 Consortium<BR> + MIT Laboratory for Computer Science<BR> + 545 Technology Square<BR> + Cambridge, MA 02139, U.S.A.<BR> +<BR> + Fax: +1 (617) 258 8682<BR> + EMail: [email protected] +<P> + <STRONG>Roy T. Fielding</STRONG><BR> + Department of Information and Computer Science<BR> + University of California<BR> + Irvine, CA 92717-3425, U.S.A.<BR> +<BR> + Fax: +1 (714) 824-4056<BR> + EMail: [email protected] +<P> + <STRONG>Henrik Frystyk Nielsen</STRONG><BR> + W3 Consortium<BR> + MIT Laboratory for Computer Science<BR> + 545 Technology Square<BR> + Cambridge, MA 02139, U.S.A.<BR> +<BR> + Fax: +1 (617) 258 8682<BR> + EMail: [email protected] +<P> + +<H2><A NAME="Appendices">Appendices</A></H2> + + These appendices are provided for informational reasons only -- they do not form a part of the + HTTP/1.0 specification. +<P> + +<H2>A. <A NAME="message_http">Internet Media Type message/http</A></H2> + + 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<A HREF="#RefMediaType"> [13]</A>. +<P> + +<PRE> + 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 +</PRE> + +<H2>B. <A NAME="Tolerant">Tolerant Applications</A></H2> + + 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. +<P> + + Clients should be tolerant in parsing the <CODE>Status-Line</CODE> and servers tolerant when parsing the + <CODE>Request-Line</CODE>. In particular, they should accept any amount of <CODE>SP</CODE> or <CODE>HT</CODE> characters between + fields, even though only a single <CODE>SP</CODE> is required. +<P> + + The line terminator for <CODE>HTTP-header</CODE> fields is the sequence <CODE>CRLF</CODE>. However, we recommend that + applications, when parsing such headers, recognize a single <CODE>LF</CODE> as a line terminator and ignore + the leading <CODE>CR</CODE>. +<P> + +<H2>C. <A NAME="MIME">Relationship to MIME</A></H2> + + HTTP/1.0 uses many of the constructs defined for Internet Mail (RFC 822<A HREF="#RefSTD11"> [7]</A>) and the + Multipurpose Internet Mail Extensions (MIME<A HREF="#RefMIME1"> [5]</A>) 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. +<P> + + 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. +<P> + + 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. +<P> + +<H3>C.1 <A NAME="MIME-Canonical">Conversion to Canonical Form</A></H3> + + 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<A HREF="#RefMIME1"> [5]</A>. + <A HREF="#TextCanonicalization">Section 3.6.1</A> of this document + describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. +<P> + + 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. +<P> + + 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 <A HREF="#TextCanonicalization">Section 3.6.1</A> of this document + to the RFC 1521 canonical form of <CODE>CRLF</CODE>. Note, however, that this may be complicated by the + presence of a <CODE>Content-Encoding</CODE> and by the fact that HTTP allows the use of some character sets + which do not use octets 13 and 10 to represent <CODE>CR</CODE> and <CODE>LF</CODE>, as is the case for some multi-byte + character sets. +<P> + +<H3>C.2 <A NAME="MIME-Date">Conversion of Date Formats</A></H3> + + HTTP/1.0 uses a restricted set of date formats (<A HREF="#DateFormats">Section 3.3</A>) to simplify the process of date + comparison. Proxies and gateways from other protocols should ensure that any <CODE>Date</CODE> header + field present in a message conforms to one of the HTTP/1.0 formats and rewrite the date if + necessary. +<P> + +<H3>C.3 <A NAME="MIME-CE">Introduction of Content-Encoding</A></H3> + + RFC 1521 does not include any concept equivalent to HTTP/1.0's <CODE>Content-Encoding</CODE> 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 <CODE>Content-Type</CODE> header field or + decode the <CODE>Entity-Body</CODE> before forwarding the message. (Some experimental applications of + <CODE>Content-Type</CODE> for Internet mail have used a media-type parameter of + <CODE>";conversions=<content-coding>"</CODE> to perform an equivalent function as + Content-Encoding. However, this parameter is not part of RFC 1521.) +<P> + +<H3>C.4 <A NAME="MIME-CTE">No Content-Transfer-Encoding</A></H3> + + 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. +<P> + + 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. +<P> + +<H3>C.5 <A NAME="MIME-parts">HTTP Header Fields in Multipart Body-Parts</A></H3> + + 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. +<P> + +<H2>D. <A NAME="Additional">Additional Features</A></H2> + + 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 with, other + HTTP/1.0 applications. +<P> + +<H3>D.1 <A NAME="Additional-Methods">Additional Request Methods</A></H3> + +<H4>D.1.1 <A NAME="PUT">PUT</A></H4> + + The PUT method requests that the enclosed entity be stored under the supplied <CODE>Request-URI</CODE>. If + the <CODE>Request-URI</CODE> 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 <CODE>Request-URI</CODE> 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. +<P> + + The fundamental difference between the POST and PUT requests is reflected in the different + meaning of the <CODE>Request-URI</CODE>. 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. +<P> + +<H4>D.1.2 <A NAME="DELETE">DELETE</A></H4> + + The DELETE method requests that the origin server delete the resource identified by the + <CODE>Request-URI</CODE>. +<P> + +<H4>D.1.3 <A NAME="LINK">LINK</A></H4> + + The LINK method establishes one or more Link relationships between the existing resource + identified by the <CODE>Request-URI</CODE> and other existing resources. +<P> + +<H4>D.1.4 <A NAME="UNLINK">UNLINK</A></H4> + + The UNLINK method removes one or more Link relationships from the existing resource + identified by the <CODE>Request-URI</CODE>. +<P> + +<H3>D.2 <A NAME="Additional-Headers">Additional Header Field Definitions</A></H3> + +<H4>D.2.1 <A NAME="Accept">Accept</A></H4> + + 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 of that + type. The set of ranges given by the client should represent what types are acceptable given the + context of the request. +<P> + +<H4>D.2.2 <A NAME="Accept-Charset">Accept-Charset</A></H4> + + 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. +<P> + +<H4>D.2.3 <A NAME="Accept-Encoding">Accept-Encoding</A></H4> + + The Accept-Encoding request-header field is similar to Accept, but restricts the content-coding + values which are acceptable in the response. +<P> + +<H4>D.2.4 <A NAME="Accept-Language">Accept-Language</A></H4> + + 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. +<P> + +<H4>D.2.5 <A NAME="Content-Language">Content-Language</A></H4> + + 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. +<P> + +<H4>D.2.6 <A NAME="Link">Link</A></H4> + + 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. +<P> + +<H4>D.2.7 <A NAME="MIME-Version">MIME-Version</A></H4> + + 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<A HREF="#RefMIME1"> [5]</A>, 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. +<P> + +<H4>D.2.8 <A NAME="Retry-After">Retry-After</A></H4> + + 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. +<P> + +<H4>D.2.9 <A NAME="Title">Title</A></H4> + + The Title entity-header field indicates the title of the entity. +<P> + +<H4>D.2.10 <A NAME="URI-header">URI</A></H4> + + The URI entity-header field may contain some or all of the Uniform Resource Identifiers + (<A HREF="#URI">Section 3.2</A>) by which the <CODE>Request-URI</CODE> resource can be identified. There is no guarantee that + the resource can be accessed using the URI(s) specified. + +</BODY></HTML> |