- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Tue, 30 Apr 1996 15:55:29 PDT
- To: koen@win.tue.nl
- Cc: fielding@avron.ICS.UCI.EDU, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, jg@w3.org, klensin@mail1.reston.mci.net
> 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 have. > 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. Larry
Received on Tuesday, 30 April 1996 16:00:06 UTC