> From owner-wrec@cs.utk.edu Fri Sep 10 08:33:13 1999
> Delivery-Date: Fri, 10 Sep 1999 08:33:13 -0700
> Return-Path: owner-wrec@cs.utk.edu
> From: Ian Cooper <ian@mirror-image.com>
> To: Markus Buchhorn <markus@acsys.anu.edu.au>
> Cc: wrec@cs.utk.edu
> Subject: Re: Taxonomy Term closure needed
> Date: Fri, 10 Sep 1999 12:35:38 +0100
> List-Unsubscribe: <mailto:wrec-request@cs.utk.edu?Subject=unsubscribe>
>
> On Fri, 10 Sep 1999 12:23:38 +1000, Markus Buchhorn wrote:
>
> >
> >At 17:40 9/09/99 -0700, Joe Touch wrote:
> >>A cache is a system which stores temporary copies of response messages,
> >>and replays them when prompted.
> >
> > .. of successful response messages..? or somesuch - not much point caching
> >error results.
>
> Well, there might be. It would depend on what type of error.
>
> > And there's also the question of permission/time - being
> >allowed to cache a response (Pragma: No-Cache; Expires: Now).
>
> Doesn't that come under the catch-all term "cacheable"?
>
> >>> Reverse Proxy
> >>
> >>This is the one I find odd. There is nothing reverse about it.
> >>It's just a proxy cache co-located (or nearly-colocated) with the server.
> >>
> >>Why not just call it a "server-side, or server-proximal" cache?
> >
> >Agreed. A 'server-side' cache is designed to take load off the origin
> >server, but does nothing for the network or performance as seen by the
> >end-user.
>
> Not necessarily. By taking load off the origin server you may well
> enhance the performance as seen by the end-user. I know what you're
> saying though.
>
> >>> Second Derivative Terms: (Build upon first derivative terms)
> >>> Caching Proxy
> >>And which intercepts requests that have associated responses
> >>in its cache.
> >
> >No - it "intercepts" _all_ requests, but if it can't service them will
> >forward them on on behalf of the client, and store the response while also
> >passing it on. And depending on the application it may not be an
> >"intercept" (which sounds like a hijack) it may be a deliberate direct
> >request ("have you got this? If not please get it for me").
>
> "Intercepts" seems to hint at the wrong thing (as you say).
> "terminates" is probably too strong, although the request stream _is_
> being terminated for cached content.
Why do we have a problem with intercepts?
When that's what you want, it's a good thing. (intercepting bugs)
When it isn't, it's hijacking.
Sounds like exactly the right thing, in this case.
Joe
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST