rfc2068.txt

穿越防火墙技术代码

1.4 Overall Operation

   The HTTP protocol is a request/response protocol. A client 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 over a
   connection with a server. 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 entity-body content. The relationship
   between HTTP and MIME is described in appendix 19.4.







Fielding, et. al.           Standards Track                    [Page 11]

RFC 2068                        HTTP/1.1                    January 1997


   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 part 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 will 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
   cached copy of an earlier response from O (via C) for a request which
   has not been cached by UA or A.





Fielding, et. al.           Standards Track                    [Page 12]

RFC 2068                        HTTP/1.1                    January 1997


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

   Not all responses are usefully cachable, and some requests may
   contain modifiers which place special requirements on cache behavior.
   HTTP requirements for cache behavior and cachable responses are
   defined in section 13.

   In fact, there are a wide variety of architectures and configurations
   of caches and proxies currently being experimented with or deployed
   across the World Wide Web; these systems include national hierarchies
   of proxy caches to save transoceanic bandwidth, systems that
   broadcast or multicast cache entries, organizations that distribute
   subsets of cached data via CD-ROM, and so on. HTTP systems are used
   in corporate intranets over high-bandwidth links, and for access via
   PDAs with low-power radio links and intermittent connectivity. The
   goal of HTTP/1.1 is to support the wide diversity of configurations
   already deployed while introducing protocol constructs that meet the
   needs of those who build web applications that require high
   reliability and, failing that, at least reliable indications of
   failure.

   HTTP communication usually 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;
   the mapping of the HTTP/1.1 request and response structures onto the
   transport data units of the protocol in question is outside the scope
   of this specification.

   In HTTP/1.0, most implementations used a new connection for each
   request/response exchange. In HTTP/1.1, a connection may be used for
   one or more request/response exchanges, although connections may be
   closed for a variety of reasons (see section 8.1).

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 [9]. Implementers will need to be familiar with the
   notation in order to understand this specification. The augmented BNF
   includes the following constructs:





Fielding, et. al.           Standards Track                    [Page 13]

RFC 2068                        HTTP/1.1                    January 1997


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 ("|") 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.

#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



Fielding, et. al.           Standards Track                    [Page 14]

RFC 2068                        HTTP/1.1                    January 1997


     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.

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 ANSI X3.4-1986 [21].

          OCTET          = <any 8-bit sequence of data>
          CHAR           = <any US-ASCII character (octets 0 - 127)>
          UPALPHA        = <any US-ASCII uppercase letter "A".."Z">
          LOALPHA        = <any US-ASCII lowercase letter "a".."z">
          ALPHA          = UPALPHA | LOALPHA
          DIGIT          = <any US-ASCII digit "0".."9">
          CTL            = <any US-ASCII control character
                           (octets 0 - 31) and DEL (127)>
          CR             = <US-ASCII CR, carriage return (13)>
          LF             = <US-ASCII LF, linefeed (10)>
          SP             = <US-ASCII SP, space (32)>
          HT             = <US-ASCII HT, horizontal-tab (9)>
          <">            = <US-ASCII double-quote mark (34)>










Fielding, et. al.           Standards Track                    [Page 15]

RFC 2068                        HTTP/1.1                    January 1997


   HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
   protocol elements except the entity-body (see appendix 19.3 for
   tolerant applications). The end-of-line marker within an entity-body
   is defined by its associated media type, as described in section 3.7.

          CRLF           = CR LF

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

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

   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 characters from character sets other than ISO
   8859-1 [22] only when encoded according to the rules of RFC 1522
   [14].

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

   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.1 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.

          token          = 1*<any CHAR except CTLs or tspecials>

          tspecials      = "(" | ")" | "<" | ">" | "@"
                         | "," | ";" | ":" | "\" | <">
                         | "/" | "[" | "]" | "?" | "="
                         | "{" | "}" | SP | HT

   Comments can be included in some HTTP header fields by surrounding
   the comment text with parentheses. Comments are only allowed in
   fields containing "comment" as part of their field value definition.
   In all other fields, parentheses are considered part of the field
   value.

          comment        = "(" *( ctext | comment ) ")"
          ctext          = <any TEXT excluding "(" and ")">