tunnel

       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.

   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




 
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




 
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.