Hope this makes it clear what the difference is between forward and reverse proxy:
Forward Proxy:
A forward proxy listens on a proxy port to receive incoming requests from a user agent. Typically this is on port 8080 or 3128 depending on the vendor. The user agent (typically a browser) is aware talking to a proxy instead the origin server. The forward proxy uses a build-in user agent to request the object from the origin server (or another forward proxy if configured, see ICP). The forward proxy delivers it back to the user agent.
Reverse Proxy:
Different picture here. The user agent sends the request to the (what he believes) origin server. In fact the request comes in to the reverse proxy (you achieve this by modifying the dns record of the origin server so that it resolves to the reverse proxy instead of the origin server), which has a listener on port 80 (like an origin server). The reverse proxy will then use a build-in user agent to request the object from the (real) origin server. It will then send the object back to the requesting user agent.
Now you just need to add caching to these scenarios. Of course, a caching proxy will first evaluate all incoming requests to see whether the object is already in cache. It will also use http response headers if available (or defaults or other heuristics) to determine the freshness of objects. Typically the algorithms used are the same for forward and reverse caching.
Summary: A forward cache is acting as a user agent to an origin server, while a reverse cache is acting as a web server to a user agent.
Frank
>>> Joe Touch <touch@ISI.EDU> 11.09.99 18.35 >>>
Henrik Nordstrom wrote:
>
> Henrik Nordstrom wrote:
>
> > The most important aspect for a reverse proxy is "on behalf", which
> > implies that is is set up by and under the administrative control of the
> > content provider.
>
> Sorry, I was a bit uncareful in the wording there. The administrative
> control is usually that of the network managers of the origin server,
> which does not neccesary imply that it is under the control of the
> content provider. It should however be included in the a service
> agreement between the content provider and management of the origin
> server, network connection or reverse proxy.
Whether a term is in wide use or not does not necessarily
require its use in the core of the taxonomy document.
We can easily define an appropriate term and define 'reverse proxy'
in terms thereof.
What concerns me about the above is the use of "intent"
in a definition. There must be some objective metric.
Management control, service agreeements, etc. aren't
useful objective metrics.
Is there any definition of a reverse proxy that is objective?
(and can distinguish it completely from a non-reverse proxy cache?)
Joe
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST