W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

RE: Demographics

From: Shel Kaphan <sjk@amazon.com>
Date: Wed, 10 Jul 1996 12:19:03 -0700
Message-Id: <199607101919.MAA21451@samba.amazon.com>
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>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1085
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.

Received on Wednesday, 10 July 1996 12:46:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC