Re: rethinking caching

Benjamin Franz writes:
 > On Sat, 16 Dec 1995, Koen Holtman wrote:
 > 
 > > 
 > >   Clients (including caching proxies) should disregard Location
 > >   headers in 2xx responses if they do not point to the same server
 > >   that generated the response.
 > > 
 > > This restriction still leaves you with a negotiation mechanism
 > > powerful enough to handle the French/English example.
 > > 
 > > Note that the above solution assumes that either the content providers
 > > on the same server either trust each other not to spoof, or that the
 > > server has some Location response header filtering mechanism that
 > > excludes spoofing.
 > > 
 > 
 > This is not a safe assumption. Numerous providers sell space to many 
 > independent people on single servers. For example: www.xmission.com 
 > serves on the order of 1000 independent entities, including many 
 > businesses and people, and allows CGI to be owned by the individuals. 
 > Clearly there is the opportunity for someone to spoof there under the 
 > rule. It is not significantly safer than unrestricted redirections when 
 > many (most?) people share common servers.
 > 
 > -- 
 > Benjamin Franz

If the cache key for the returned document were essentially
the _pair_ (request-URI, location-URI), then this would be safe.

Then even if a server returned a completely bogus Location URI, it
would still be associated with the request URI, and so could not
"escape" to spoof other requests where the request URI was the same
as that Location URI.

Furthermore, associated with this pair (and the object) could be the
content-negotiation information that caused that request-URI to yield
that particular Location-URI.

However, in order to avoid duplicate objects in the cache, I think
that an object returned with a given Location-URI must flush any other
objects from the cache with that URI as either the request-URI or the
location-URI.  This is "spoofable" in a sense, but can only affect
performance, and not correctness.

But this should probably wait for the caching subgroup.... (sorry, Jeff)

--Shel

Received on Saturday, 16 December 1995 15:16:25 UTC