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

RE: Demographics

From: Paul Leach <paulle@microsoft.com>
Date: Wed, 10 Jul 1996 12:49:36 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-77-MSG-960710194936Z-21262@tide19.microsoft.com>
To: 'Shel Kaphan' <sjk@amazon.com>
Cc: 'http-wg' <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:05 EDT