aboutsummaryrefslogtreecommitdiffstats
path: root/lib/inets/doc/archive/rfc1945.html
diff options
context:
space:
mode:
authorErlang/OTP <[email protected]>2009-11-20 14:54:40 +0000
committerErlang/OTP <[email protected]>2009-11-20 14:54:40 +0000
commit84adefa331c4159d432d22840663c38f155cd4c1 (patch)
treebff9a9c66adda4df2106dfd0e5c053ab182a12bd /lib/inets/doc/archive/rfc1945.html
downloadotp-84adefa331c4159d432d22840663c38f155cd4c1.tar.gz
otp-84adefa331c4159d432d22840663c38f155cd4c1.tar.bz2
otp-84adefa331c4159d432d22840663c38f155cd4c1.zip
The R13B03 release.OTP_R13B03
Diffstat (limited to 'lib/inets/doc/archive/rfc1945.html')
-rw-r--r--lib/inets/doc/archive/rfc1945.html3035
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 ------------------------&gt;
+ UA -------------------v------------------- O
+ &lt;----------------------- 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 --------------------------------------&gt;
+ UA -----v----- A -----v----- B -----v----- C -----v----- O
+ &lt;------------------------------------- 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 ----------&gt;
+ UA -----v----- A -----v----- B - - - - - - C - - - - - - O
+ &lt;--------- 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>"&lt;"</CODE> and <CODE>"&gt;"</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>"&lt;n&gt;*&lt;m&gt;element"</CODE> indicating at least <CODE>&lt;n&gt;</CODE> and at most <CODE>&lt;m&gt;</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>"&lt;n&gt;(element)"</CODE> is equivalent to <CODE>"&lt;n&gt;*&lt;n&gt;(element)"</CODE>; that is, exactly <CODE>&lt;n&gt;</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>"&lt;n&gt;#&lt;m&gt;element"</CODE> indicating at least <CODE>&lt;n&gt;</CODE> and at most <CODE>&lt;m&gt;</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 = &lt;any 8-bit sequence of data&gt;
+ CHAR = &lt;any US-ASCII character (octets 0 - 127)&gt;
+ UPALPHA = &lt;any US-ASCII uppercase letter "A".."Z"&gt;
+ LOALPHA = &lt;any US-ASCII lowercase letter "a".."z"&gt;
+ ALPHA = UPALPHA | LOALPHA
+ DIGIT = &lt;any US-ASCII digit "0".."9"&gt;
+ CTL = &lt;any US-ASCII control character
+ (octets 0 - 31) and DEL (127)&gt;
+ CR = &lt;US-ASCII CR, carriage return (13)&gt;
+ LF = &lt;US-ASCII LF, linefeed (10)&gt;
+ SP = &lt;US-ASCII SP, space (32)&gt;
+ HT = &lt;US-ASCII HT, horizontal-tab (9)&gt;
+ &lt;"&gt; = &lt;US-ASCII double-quote mark (34)&gt;
+</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 = &lt;any OCTET except CTLs,
+ but including LWS&gt;
+</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*&lt;any CHAR except CTLs or tspecials&gt;
+</PRE>
+
+<PRE>
+ tspecials = "(" | ")" | "&lt;" | "&gt;" | "@"
+ | "," | ";" | ":" | "\" | &lt;"&gt;
+ | "/" | "[" | "]" | "?" | "="
+ | "{" | "}" | 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 = &lt;any TEXT excluding "(" and ")"&gt;
+</PRE>
+
+ A string of text is parsed as a single word if it is quoted using double-quote marks.
+<P>
+
+<PRE>
+ quoted-string = ( &lt;"&gt; *(qdtext) &lt;"&gt; )
+</PRE>
+
+<PRE>
+ qdtext = &lt;any CHAR except &lt;"&gt; and CTLs,
+ but including LWS&gt;
+</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 "&lt;major&gt;.&lt;minor&gt;" 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 &lt;minor&gt; 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 &lt;major&gt;
+ 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 | ":" | "@" | "&amp;" | "=" | "+"
+ uchar = unreserved | escape
+ unreserved = ALPHA | DIGIT | safe | extra | national
+</PRE>
+
+<PRE>
+ escape = "%" HEX HEX
+ reserved = ";" | "/" | "?" | ":" | "@" | "&amp;" | "=" | "+"
+ extra = "!" | "*" | "'" | "(" | ")" | ","
+ safe = "$" | "-" | "_" | "."
+ unsafe = CTL | SP | &lt;"&gt; | "#" | "%" | "&lt;" | "&gt;"
+ national = &lt;any OCTET excluding ALPHA, DIGIT,
+ reserved, extra, safe, and unsafe&gt;
+</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 = &lt;A legal Internet host domain name
+ or IP address (in dotted-decimal form),
+ as defined by Section 2.1 of RFC 1123&gt;
+</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 = &lt;the OCTETs making up the field-value
+ and consisting of either *TEXT or combinations
+ of token, tspecials, and quoted-string&gt;
+</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 = *&lt;TEXT, excluding CR, LF&gt;
+</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>
+</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 = &lt;base64<A HREF="#RefMIME1"> [5]</A> encoding of userid-password,
+ except not limited to 76 char/line&gt;
+</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&aring;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&ccedil;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&amp;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>
+<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>
+<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>
+<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=&lt;content-coding&gt;"</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>