RE: Demographics

Neat observation. Certainly better than some special purpose hack. But
I'll bet not many caches will try the optiimization you suggested to
avoid duplicate entries.

>----------
>From: 	Shel Kaphan[SMTP:sjk@amazon.com]
>Sent: 	Wednesday, July 10, 1996 12:19 PM
>To: 	Paul Leach
>Cc: 	'koen@win.tue.nl'; 'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'
>Subject: 	RE: Demographics
>
>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 13:02:37 UTC