rfc1945.txt

<VC++网络游戏建摸与实现>源代码

       cannot, or should not, interpret the relayed communication.

   cache

       A program's local store of response messages and the subsystem
       that controls its message storage, retrieval, and deletion. A
       cache stores cachable responses in order to reduce the response
       time and network bandwidth consumption on future, equivalent
       requests. Any client or server may include a cache, though a
       cache cannot be used by a server while it is acting as a tunnel.

   Any given program may be capable of being both a client and a server;
   our use of these terms refers only to the role being performed by the
   program for a particular connection, rather than to the program's
   capabilities in general. Likewise, any server may act as an origin
   server, proxy, gateway, or tunnel, switching behavior based on the
   nature of each request.

1.3  Overall Operation

   The HTTP protocol is based on a request/response paradigm. A client
   establishes a connection with a server and sends a request to the
   server in the form of a request method, URI, and protocol version,
   followed by a MIME-like message containing request modifiers, client
   information, and possible body content. The server responds with a



Berners-Lee, et al           Informational                      [Page 6]

RFC 1945                        HTTP/1.0                        May 1996


   status line, including the message's protocol version and a success
   or error code, followed by a MIME-like message containing server
   information, entity metainformation, and possible body content.

   Most HTTP communication is initiated by a user agent and consists of
   a request to be applied to a resource on some origin server. In the
   simplest case, this may be accomplished via a single connection (v)
   between the user agent (UA) and the origin server (O).

          request chain ------------------------>
       UA -------------------v------------------- O
          <----------------------- response chain

   A more complicated situation occurs when one or more intermediaries
   are present in the request/response chain. There are three common
   forms of intermediary: proxy, gateway, and tunnel. A proxy is a
   forwarding agent, receiving requests for a URI in its absolute form,
   rewriting all or parts of the message, and forwarding the reformatted
   request toward the server identified by the URI. A gateway is a
   receiving agent, acting as a layer above some other server(s) and, if
   necessary, translating the requests to the underlying server's
   protocol. A tunnel acts as a relay point between two connections
   without changing the messages; tunnels are used when the
   communication needs to pass through an intermediary (such as a
   firewall) even when the intermediary cannot understand the contents
   of the messages.

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

   The figure above shows three intermediaries (A, B, and C) between the
   user agent and origin server. A request or response message that
   travels the whole chain must pass through four separate connections.
   This distinction is important because some HTTP communication options
   may apply only to the connection with the nearest, non-tunnel
   neighbor, only to the end-points of the chain, or to all connections
   along the chain. Although the diagram is linear, each participant may
   be engaged in multiple, simultaneous communications. For example, B
   may be receiving requests from many clients other than A, and/or
   forwarding requests to servers other than C, at the same time that it
   is handling A's request.

   Any party to the communication which is not acting as a tunnel may
   employ an internal cache for handling requests. The effect of a cache
   is that the request/response chain is shortened if one of the
   participants along the chain has a cached response applicable to that
   request. The following illustrates the resulting chain if B has a



Berners-Lee, et al           Informational                      [Page 7]

RFC 1945                        HTTP/1.0                        May 1996


   cached copy of an earlier response from O (via C) for a request which
   has not been cached by UA or A.

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

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

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

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

1.4  HTTP and MIME

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

2.  Notational Conventions and Generic Grammar

2.1  Augmented BNF

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




Berners-Lee, et al           Informational                      [Page 8]

RFC 1945                        HTTP/1.0                        May 1996


   name = definition

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

   "literal"

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

   rule1 | rule2

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

   (rule1 rule2)

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

   *rule

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

   [rule]

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

   N rule

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




Berners-Lee, et al           Informational                      [Page 9]

RFC 1945                        HTTP/1.0                        May 1996


   #rule

       A construct "#" is defined, similar to "*", for defining lists
       of elements. The full form is "<n>#<m>element" indicating at
       least <n> and at most <m> elements, each separated by one or
       more commas (",") and optional linear whitespace (LWS). This
       makes the usual form of lists very easy; a rule such as
       "( *LWS element *( *LWS "," *LWS element ))" can be shown as
       "1#element". Wherever this construct is used, null elements are
       allowed, but do not contribute to the count of elements present.
       That is, "(element), , (element)" is permitted, but counts as
       only two elements. Therefore, where at least one element is
       required, at least one non-null element must be present. Default
       values are 0 and infinity so that "#(element)" allows any
       number, including zero; "1#element" requires at least one; and
       "1#2element" allows one or two.

   ; comment

       A semi-colon, set off some distance to the right of rule text,
       starts a comment that continues to the end of line. This is a
       simple way of including useful notes in parallel with the
       specifications.

   implied *LWS

       The grammar described by this specification is word-based.
       Except where noted otherwise, linear whitespace (LWS) can be
       included between any two adjacent words (token or
       quoted-string), and between adjacent tokens and delimiters
       (tspecials), without changing the interpretation of a field. At
       least one delimiter (tspecials) must exist between any two
       tokens, since they would otherwise be interpreted as a single
       token. However, applications should attempt to follow "common
       form" when generating HTTP constructs, since there exist some
       implementations that fail to accept anything beyond the common
       forms.

2.2  Basic Rules

   The following rules are used throughout this specification to
   describe basic parsing constructs. The US-ASCII coded character set
   is defined by [17].

       OCTET          = <any 8-bit sequence of data>
       CHAR           = <any US-ASCII character (octets 0 - 127)>
       UPALPHA        = <any US-ASCII uppercase letter "A".."Z">
       LOALPHA        = <any US-ASCII lowercase letter "a".."z">



Berners-Lee, et al           Informational                     [Page 10]

RFC 1945                        HTTP/1.0                        May 1996


       ALPHA          = UPALPHA | LOALPHA
       DIGIT          = <any US-ASCII digit "0".."9">
       CTL            = <any US-ASCII control character
                        (octets 0 - 31) and DEL (127)>
       CR             = <US-ASCII CR, carriage return (13)>
       LF             = <US-ASCII LF, linefeed (10)>
       SP             = <US-ASCII SP, space (32)>
       HT             = <US-ASCII HT, horizontal-tab (9)>
       <">            = <US-ASCII double-quote mark (34)>

   HTTP/1.0 defines the octet sequence CR LF as the end-of-line marker
   for all protocol elements except the Entity-Body (see Appendix B for
   tolerant applications). The end-of-line marker within an Entity-Body
   is defined by its associated media type, as described in Section 3.6.

       CRLF           = CR LF

   HTTP/1.0 headers may be folded onto multiple lines if each
   continuation line begins with a space or horizontal tab. All linear
   whitespace, including folding, has the same semantics as SP.

       LWS            = [CRLF] 1*( SP | HT )

   However, folding of header lines is not expected by some
   applications, and should not be generated by HTTP/1.0 applications.

   The TEXT rule is only used for descriptive field contents and values
   that are not intended to be interpreted by the message parser. Words
   of *TEXT may contain octets from character sets other than US-ASCII.

       TEXT           = <any OCTET except CTLs,
                        but including LWS>

   Recipients of header field TEXT containing octets outside the US-
   ASCII character set may assume that they represent ISO-8859-1
   characters.

   Hexadecimal numeric characters are used in several protocol elements.

       HEX            = "A" | "B" | "C" | "D" | "E" | "F"
                      | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT

   Many HTTP/1.0 header field values consist of words separated by LWS
   or special characters. These special characters must be in a quoted
   string to be used within a parameter value.

       word           = token | quoted-string




Berners-Lee, et al           Informational                     [Page 11]