Joe Touch wrote:
> The only meaningful difference may be whether the protocol
> changes - does it?
Yes.
A normal proxy request looks like
[TCP connection client -> proxy server]
GET http://www.example.com/path/to/file HTTP/1.0
[mime-headers]
While a traditional HTTP server request looks like
[TCP connection client -> origin server]
GET /path/to/file HTTP/1.0
[mime-headers]
From reading HTTP/1.1 specs it seems that the intent is to remove this
format difference in a future version of HTTP/1. (RFC 2616 section 5.1.2
Request-URI, second paragraph on page 37)
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
A normal proxy brings your people out to the internet
A reverse proxy gives internet users controlled access to your servers
behind your firewall or private network.
A server-side cache sits infront of your server and takes some of the
request load by caching.
Regarding the term "server-side caches". To me it is a very broad term
which may include caching performed by the origin server itself. It is
not necessary a proxy. Caching may also be performed in a number of
levels in HTTP server applications, not only at the HTTP protocol level.
-- Henrik Nordstrom
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST