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 , 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 . 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
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 . 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.
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.
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".
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
Square brackets enclose optional elements; "[foo bar]" is
equivalent to "*1(foo bar)".
Specific repetition: "(element)" is equivalent to
"*(element)"; that is, exactly occurrences of
(element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a