In a previous episode hardie@equinix.com said...
::
:: > 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.
absolutely... administrative control belongs to whomever makes the
decision about what bytes get served on the wire.. under a normal
webfarm SLA that'll be the web hosting company subject to certain
conditions (expiration times, honoring of development->production
requests, whatever..) made with their customer..
I'd suggest that a common distinction would be a web hosting solution
would fall under administrative control where a co-location agreement
typically would not.. but that's not really appropriate for the
taxonomy.
:: 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.
::
[..]
::
:: 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.
::
right.. it all depends on the policy.. the point is that how the
content is created is goverened by policy not by protocol (the policy
may simply be to use the protocol, but it may include exceptions, out
of band things, or whatever).. and that's why they all have to be
under the same administrative domain.
:: 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.
actually I think of the surrogate(s) and classic-origin server(s)
all together as logically forming the HTTP origin server.. together
they are the end point of the HTTP transaction, how they coordinate
amongst themselves isn't really relevant.. That cluster is one logical
point in the chain. maybe it's just a higher level view of what you're
saying..
this brings us full circle to Henrik's point that he doesn't want to
see surrogates/reverse-proxies lumped together with network
transparent proxies (a point that I wholeheartedly agree with). Caches
and origin servers do indeed get different HTTP requests (the URI
formation mentioned earlier is one element, the absence/inclusion of
cache-control/pragma is another).. a surrogate can answer the request
properly getting an origin-server style request because by policy it
is part of the origin server's scope, but a hijacking proxy can't do
it right all the time when getting the wrong style of request because
it doesn't share knowledge of the origin server's state.
-P
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST