- From: Shel Kaphan <sjk@amazon.com>
- Date: Wed, 10 Jul 1996 12:19:03 -0700
- To: Paul Leach <paulle@microsoft.com>
- Cc: "'koen@win.tue.nl'" <koen@win.tue.nl>, "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Paul Leach writes: ... > If fact, "Referer" makes it very hard for a cache to be semantically > transparent: if a cache was trying to be semantically transparent, the > presence of "Referer" on a GET request should cause a cache to do a > conditional GET on the Request-URI. The only way to avoid this would be > to remember each different value of Referer: had been seen and to report > hit counts on each of them (somehow). Not only is this more complex than > using cached 302s, it also would result in exactly as many remembered > Referers as cached 302s in your proposal. > > Not that I'm recommending this per se, but if a server cared about this, it could use the Vary header to indicate the result varies on the Referer request-header, causing any caches to treat the results independently. Of course this would mean a lot more bookkeeping entries in caches, but implementation-wise, if caches could have unique entries for resources that were logically different but physically identical (using a digest hash or something), this wouldn't be that much uglier than some special case method of keeping track specifically by Referer. --Shel
Received on Wednesday, 10 July 1996 12:46:22 UTC