In a previous episode Henrik Nordstrom said...
::
:: My main problem with basing a definition of reverse proxy or server-side
:: proxy on this is that TCP hijacking proxies see server requests while
:: there is conceptually nothing being server-side or reverse with a TCP
:: hijacking proxy. The thing being reverse in a revese proxy or
:: server-side in a server-side cache is how and where it is used, not the
:: tiny details of the protocol parsing in performs. The term is a
:: functional description when you discuss network topology and firewalling
:: with a sites network or IS managers
I fully agree.. to elaborate:
server side proxies are not really proxies at all.. they're just
origin servers typically implemented that way so clustered hardware
can be used (yielding fault tolerance, division of labor, and things
like filesystem optimizations).. but they are origin servers without a
doubt.. the fact that they fufill some of their requests using HTTP or
ICP or somesuch is not really more germane than if they fufilled them
by running ODBC programs; they are authoritative for the URLs as far
as the client is concerned how they fufill them is a matter of server
design.
the request presented to them is addressed to them.. and all the data
belongs to the same administrative domain, they are not generic and as
such have no expiration or privacy issues beyond that of normal origin
servers... issues such as the inclusion of cache-control in the
request are not really relevant.. whereas they certainly are with
client side proxies.. in my mind a reverse proxy could choose to serve
a request with cache-control: no-cache out of it's cache because it is
authoritative for that resource..
the sometimes used term accelerator seems to be a much better piece of
terminology for this element.
-P
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST