Re: rethinking caching

Benjamin Franz:

 On Sun, 17 Dec 1995, Koen Holtman wrote:
	...
 > Of course, Shel's idea of making the cache key of a negotiated variant
 > be the pair (request-URI, location-URI) eliminates all spoofing risks,
 > we could switch to such a scheme if the consensus is that Location
 > header filtering is unfeasible.  Shel's scheme is safe no matter how
 > much the server administrator does about security, but has the
 > disadvantage of allowing less cache hits: it would be much more
 > difficult to let preemptive and reactive content negotiation share
 > cache slots for the variants.  [Note: an explanation of this last
 > statement would require a level of detail only appropriate in the
 > content negotiation or caching subgroups.]

One note: as long as the cache-validator of an object remains the same
it is OK for copies of it to persist in the cache under separate keys,
even though it may be the result of content-negotiation in several
ways, or the result of a direct request.  (Example: you have URLs A,
B, and C.  Requests for both A and B yield "location" C, as do
direct requests for C.  Though each request would result in a
different (key,object) in the cache, ((A,C), (B,C), and (C,-)), if the
cache validator for C is the same in all cases there is no problem
leaving the other copies in the cache.  The only performance hit
occurs when C changes.  Then the next similar request for A, B, or C must
flush all other occurrences of C from the cache.  So it really isn't
so bad.)

 Never-the-less, I believe this is the route that will have to be taken.
 The other route (local filtering) just places too much reliance on good
 security management at the local level. It amounts really to trusting all 
 system admins to 'play nice and know what they are doing' - something the 
 ever growing ever growing spam/forgery problems on the Usenet and in 
 E-mail have shown just is not a good assumption in general. 

Even if this route is taken, it still may be "robust" cache design
to refuse to accept Location headers from an upstream server that do not
at least match the hostname part of the request's URL. Unless there
are exception cases I can't think of ...

	...

--Shel Kaphan

Received on Sunday, 17 December 1995 11:12:49 UTC