In a previous episode hardie@equinix.com said...
:: Perhaps I misunderstand you here, but it sounds like you assume that a
:: surrogate/reverse proxy/server side proxy acts for a single server.
:: That may be a common implementation, but it is not necessarily the
:: case.
not really.. what I was (awkwardly) trying to say is that the server
side proxy acts for a finite number of servers all under the same
administrative control.. a single server certainly satifies that as do
the NASA and exodus examples.
The cachability rules of a reverse proxy are goverened by the
administrative policies that it is serving, not by HTTP
semantics.. The HTTP requirements are satisified because it is
considered the origin server from the client's pov.
For example with your NASA situation.. under high load would one of
your reverse proxies (I'm unsure of exactly what is meant by
surrogate, so I'm avoiding the word so I don't misuse it) still
forward a request to Kennedy that contained [Pragma|Cache-Control]:
no-cache ? It might.. it might not.. I'd certainly argue that you
could use out-of-band to notify the proxy of changes.. creating a sort
of production and development type of environment where the reverse
proxy never needs to ask what we typically think of as the origin
server if an element is up to date.. it's presence means it is defacto
up to date..
because of this it isn't really a proxy, it's a destination.. it's an
origin server that by convention creates it's content through
HTTP.. if it were a proxy it would have to obey HTTP proxy rules..
:: Now, is this taxonomically different from a proxy?
I really think so.. a client expects a proxy to do some work for it,
and as such has some control over the process of generating the
response.. a client has no control over how a reverse proxy behaves
and just wants a resource from it, but cannot control how that happens
because the reverse proxy 'owns' the data.
-P
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST