I concur with Scott's response ... that is exactly what we do in these
cases, to guarantee that the browser actually calls the server.
Ian
-----Original Message-----
From: Scott Cadillac
Hi Garth,
Do like Ian does with TAF files. When making a fresh call to the image - to
check that it made it - dynamically add an argument (to the filename) that
contains a unique value each time.
Example:
<img src="uploaded_images/emu.jpg?random=2349872394872" />
MSIE believes it has to get a fresh copy because MSIE cache is typically
based on the entire URL. Then IIS will serve up your image normally and the
arguments are ignored.
Hope this helps. Cheers...
----- Original Message -----
From: "Garth Penglase" <[EMAIL PROTECTED]>
To: "Multiple recipients of list witango-talk" <[EMAIL PROTECTED]>
Sent: Tuesday, July 23, 2002 10:18 AM
Subject: RE: Witango-Talk: Caching Problems in General ... was IE caching
problem
> Another thought, regarding this...
> Have unique URLS won't stop IE's aggressive caching of images though. A
lot
> of my caching problems are not the HTML code but images that are cached
by IE.
>
> For example, a recent problem which still has me stumped is the case of
an
> admin system which includes a file upload process.
>
> The process entails a particular file being uploaded (say emu.jpg) and
then
> referenced by the following page (ie ubuys/emu.jpg) to display that the
> image was successfully loaded. However, if the image changes, though the
> reference stays the same, the old image will still show, or if there now
is
> no image, IE still shows that there is an image. Accordingly the admin
> system is now "lying" to the administrators and they don't know what to
> believe.
>
> Any ideas on how to get around this?
> Garth
>
> At 11:25 22/07/02 -0700, you wrote:
> >Good point, Robert .... always thinking ..
> >
> >Ian
> >
> >-----Original Message-----
> >From: Robert Shubert
> >
> >Just an interesting note:
> >
> >The HASH function of T2K restricts output to 32 characters and it is
> >therefore possible to create two identical HASHes with <@CIPHER
> >action=hash str=<@CURRENTTIME>>.
> >
> >Another way of creating an ever increasing value is <@TSTOSECS
> ><@CURRENTTIMESTAMP>><@TIMER> This value is ensured to be unique unless
> >the same person is able to retrieve two pages in the same millisecond.
> >Keep in mind that this only works if the CURRENTTIMESTAMP is ever
> >increasing, if you adjust the time on the server (or adjust for daylight
> >savings) it could create duplication, although it's still highly
> >unlikely.
> >
> >Bob Shubert
> >Tronics
> >
> > > Ian Daniel wrote:
> > >
> > > Hey Garth:
> > >
> > > We experienced great caching issues which would not all be solved
> > > using the approach described below. Remember that cache involves
> > > multiple versions and schemes of browsers, proxy servers, firewalls,
> > > network routers and servers.
> > >
> > > In my experience, the only way to "beat them all" in one action is to
> > > ensure that every URL is unique.
> > >
> > > For dynamically-generated pages, we append what we call a "no-cache"
> > > argument to every URL. At NCOL, we have standardized on a hash of
the
> > > currenttimestamp, like so:
> > >
> > > &_nc=<@CIPHER action=hash str=<@CURRENTTIME>>
> > >
> > > For statically-generated pages, we add a large random number,
> > > generated in JavaScript, to ensure that every browser display (even
> > > those presented by the browser back button) has a unique URL. There
> > > are several ways to do this. We usually use:
> > >
> > > <script language="javascript">document.write('<a href="whatever.taf?'
> > > + Math.round(Math.random()*1000000000) + '">Your Link
> > > Here</a>')</script>
> >
________________________________________________________________________
TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]
with unsubscribe witango-talk in the message body
