There are two main topologies available for configuring caches.

• The first is "Distributed caching":

  Here the contents of the cache is distributed over a number of proxy servers, all connected together in a net. The group of servers creates an Array in which the members cooperate therefore creating a strong caching system with the ability to share the load. This also serves well when one of the proxies fails. The data flowing to the different users does not stop. This technology makes the finding of information in the cache area quite fast.

• The second is "Hierarchical caching" (or mesh):

  Here the proxy servers are being connected in hierarchical way. Users requests are first of all being processed by a local server, and then, if it could not find the requested information within the local cache area, it turns to another proxy server according to the hierarchy rules that were set. And if still no hit has occurred, the request will be sent to the original server.

  In a cache hierarchy one cache establishes peering relationships with its neighbor caches: either parent or sibling. A parent is one level up, and a sibling cache is in the same level. The general flow of requests is up the hierarchy. A cache that doesn't hold the requested object refers to its neighbor caches to see if they might have the object. If one of the neighbors has it the cache will request it from them. (There are ways to decide which neighbor should be preferred, in case of several hits). Else, the cache forwards the request either to a parent, or directly to the origin server. A "neighbor hit" can be cached from parent or sibling while "neighbor miss" can't be fetched from a sibling.

Big part of WWW clients are built on top of libwww (the WWW Common Library), that handles communication protocols like HTTP, FTP and others, all used in the Web. All the proxy support needed is handled with libwww transparently. This is done by using environment variables, which are set to the URL of the proxy that knows, by this way, the protocol of the requests it should serve (In some cases there is a proxy for every protocol, but it is not very likely).

The libwww forces a connection to the proxy rather than to the remote server whenever an environment variable is used, set to a certain protocol. Usually an exception list for a client to not go through a proxy is available, too, which is useful for connecting local servers. Since proxy support in a Web is very simple-libwww is not a necessity for clients. In fact, proxy support is implemented only for HTTP version 1.0 on the server side, which most clients these days are able to use.

The proxy acts both as a server and a client. When accepting requests from clients it functions as server, but acts as a client when connected to the remote server. The proxy forwards header fields it got from the client to the remote server. However, it doesn't pass the full URL it got, but only the path and keyword portion in the URL. A full proxy server should be able to speak all Web protocols.

Implementations have developed in the last years to support passing access authorization information to the remote server. That is necessary when accessing protected documents.