request chain ---------->
       UA -----v----- A -----v----- B - - - - - - C - - - - - - O
          <--------- response chain

   Not all responses are cachable, and some requests may contain
   modifiers which place special requirements on cache behavior. Some
   HTTP/1.0 applications use heuristics to describe what is or is not a
   "cachable" response, but these rules are not standardized.

   On the Internet, HTTP communication generally takes place over TCP/IP
   connections. The default port is TCP 80 [15], but other ports can be
   used. This does not preclude HTTP from being implemented on top of
   any other protocol on the Internet, or on other networks. HTTP only
   presumes a reliable transport; any protocol that provides such
   guarantees can be used, and the mapping of the HTTP/1.0 request and
   response structures onto the transport data units of the protocol in
   question is outside the scope of this specification.

   Except for experimental applications, current practice requires that
   the connection be established by the client prior to each request and
   closed by the server after sending the response. Both clients and
   servers should be aware that either party may close the connection
   prematurely, due to user action, automated time-out, or program
   failure, and should handle such closing in a predictable fashion. In
   any case, the closing of the connection by either or both parties
   always terminates the current request, regardless of its status.

1.4  HTTP and MIME

   HTTP/1.0 uses many of the constructs defined for MIME, as defined in
   RFC 1521 [5]. Appendix C describes the ways in which the context of
   HTTP allows for different use of Internet Media Types than is
   typically found in Internet mail, and gives the rationale for those
   differences.

2.  Notational Conventions and Generic Grammar

2.1  Augmented BNF

   All of the mechanisms specified in this document are described in
   both prose and an augmented Backus-Naur Form (BNF) similar to that
   used by RFC 822 [7]. Implementors will need to be familiar with the
   notation in order to understand this specification. The augmented BNF
   includes the following constructs:





 
RFC 1945                        HTTP/1.0                        May 1996


   name = definition

       The name of a rule is simply the name itself (without any
       enclosing "<" and ">") and is separated from its definition by
       the equal character "=". Whitespace is only significant in that
       indentation of continuation lines is used to indicate a rule
       definition that spans more than one line. Certain basic rules
       are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc.
       Angle brackets are used within definitions whenever their
       presence will facilitate discerning the use of rule names.

   "literal"

       Quotation marks surround literal text. Unless stated otherwise,
       the text is case-insensitive.

   rule1 | rule2

       Elements separated by a bar ("I") are alternatives,
       e.g., "yes | no" will accept yes or no.

   (rule1 rule2)

       Elements enclosed in parentheses are treated as a single
       element. Thus, "(elem (foo | bar) elem)" allows the token
       sequences "elem foo elem" and "elem bar elem".

   *rule

       The character "*" preceding an element indicates repetition. The
       full form is "*element" indicating at least  and at
       most  occurrences of element. Default values are 0 and
       infinity so that "*(element)" allows any number, including zero;
       "1*element" requires at least one; and "1*2element" allows one
       or two.

   [rule]

       Square brackets enclose optional elements; "[foo bar]" is
       equivalent to "*1(foo bar)".

   N rule

       Specific repetition: "(element)" is equivalent to
       "*(element)"; that is, exactly  occurrences of
       (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a