Re: SPOOF issue (Was: Re: Rewrite of 13.12 (Cache keys))

> Some people in the phone conference yesterday wanted such a mechanism,
> though they did not explain, as far as I could tell, why they wanted
> it, let alone why they wanted it in plain 1.1.  This mechanism is
> certainly not needed as a content negotiation `hook'.

One use for having a response invalidate cache entries would be to
allow invalidations to be returned from "POST" requests. 

This is probably necessary for folks who send new documents using POST
to different URLs than the URL that served the original document.

This would only allow a kind of sequential access transparency: the
cache is only transparent if you're using the same cache for access
and update. That's not so onerous a requirement.

I agree that this has nothing to do with content negotiation, but it
is a situation where the capability is quite useful.

Another situation is where the origin server does an internal
redirect; I'm afraid we punted on this issue, and we perhaps shouldn't

> There is _no consensus_ in the WG now, and there will likely be no
> consensus in the next few weeks, about the need to include, into
> plain 1.1, a mechanism by which the response for URI 1 can change or
> create data cached for URI 2.

Just a question before dropping this completely: is this something
that web proxies do today? Does anyone have any data or examples?
I just don't want to forget the "running code" part.


Received on Tuesday, 30 April 1996 16:00:06 UTC