Patrick writes:
> 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.
If administrative control can be extended to include a business
relationship like a web hosting company's relationship to its
customers, then I agree.
> 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.
It depends on the rules. A GET if-modified-since gets satisfied
the same way, as do any of the e-tag based semantics. You might
configure a surrogate to ignore some cache directives, but that
happens with user community caches as well. It is not a necessary
part of the model.
> 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..
You can use out-of-band or "side-band" arrangements to push content
to a surrogate, but it isn't a necessary part of the model. The
idea of using a threshold-based system is to avoid that sort of
manual configuration.
> 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
The point of calling these things "surrogates" rather than "proxies" was
to distinguish who expects the device to do some work for it. As you
note above, the client expects a proxy to do some work for it. The
server expects a surrogate to do some work for it. That doesn't make
the surrogate an origin server any more than the proxy is an end-user.
The surrogate may be a destination and the proxy may be a client, but
they are not the same as the ends of the chains.
regards,
Ted hardie
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST