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="javascript:void(0);' +
Math.round(Math.random()*1000000000) + '">Your Link
Here</a>')</script>
-----Original Message-----
From: Garth Penglase
Sent: Monday, July 22, 2002 6:15 PM
To: Multiple recipients of list witango-talk
Subject: Fwd: Witango-Talk: IE caching problem (was [OT] Outsourced DNS Service)
To reply to my own
message, Scott, I guess what you wrote back on 6th of June was absolutely
correct - and I quote "I my opinion, for reliable dynamic web-applications, all
TAFs should expire From: Garth Penglase
Sent: Monday, July 22, 2002 6:15 PM
To: Multiple recipients of list witango-talk
Subject: Fwd: Witango-Talk: IE caching problem (was [OT] Outsourced DNS Service)
immediately."
So I guess I'll ensure that the following is in my headers:
Cache-Control: no-cache, max-age=0, must-revalidate,
proxy-revalidate<@CRLF>Pragma: no-cache
as I understand that simply adding a meta tag to the header of the HTML will not necessarily be read by proxy servers.
Garth
Date: Tue, 23 Jul 2002 10:56:42 +1000________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
To: [EMAIL PROTECTED]
From: Garth Penglase <[EMAIL PROTECTED]>
Subject: Witango-Talk: IE caching problem (was [OT] Outsourced DNS Service)
I'd be interested in anyone's opinion on how to ensure that all my site admin systems, most of which include file uploads facilities, do not suffer from this caching problem in the future. My first thought is to set a META tag telling the browser not to cache any page - but is that going to do the trick?
MSIE is very aggressive in its approach to caching, particularly later versions and those on the Mac from 5.5 up. This I discovered because I did not code an admin site with this over-agressiveness of caching in mind and have experienced problems with IE on a a client's network recently. Though I have not changed any code, they weren't able to successfully upload files to the WiTango server, resulting in incomplete records, many retries and a lot of frustration.
I can't agree with Scott when he says that some sites behave "oddly" in terms of caching (see below for transcript) - not being defensive, but since I have a had the same admin site running without a problem for users of IE and Navigator alike for two years only to experience this problem recently as my client upgraded to later versions of IE and moved to the Mac (Navigator nor any other browser has these problems), I must feel compelled to blame IE's more recent approach to caching, or their later versions on the Mac.
While I solved my client's initial file upload problem (the file upload page was simply hanging and then timing out as the browser confused itself using a cached version) by telling them to do exactly what Scott advised Daniel to do - change the caching settings in the browser, they still suffered problems when they loaded some images and then modified records, since their browser would tell them that the image was correctly loading, even though it wasn't (long story as to what they were doing - suffice to say it was a secondary issue that I had to solve based on IE's method of caching). In their case, to solve their problem once and for all, I then simply told them to use Navigator, something I hate to do, as I believe that it is up to the developer to ensure that any site made for the masses should work no matter what the settings on the browser (caching/proxies/javascript on or off/etc.) - in this case I have a "captive" audience as the admin system is only used by one company but you get my point. Obviously, they haven't had a problem since.
I agree with Ian that a site should work in the "dumbest" most standard mode possible (unless one is developing, as Scott often does, for a intranet or captive audience which is another kettle of fish giving one a greater latitude in development).
Garth
At 11:39 19/07/02 -0700, you wrote:
You are welcome Ian,
That MSIE setting is useful for those rare sites you come across that does
behave oddly in terms of caching.
> I prefer to leave my browser in "dumb mode," to imitate the worst setting
> that a user could have their browser set to.
>
> If I can make our sites work when the settings are not optimal, then we
are
> in good shape. As an aside, I always develop with cookies shut off, as
> well, to help ensure that I pick up any missed User Ref's. I know that
you
> develop for cookies, however ... no need to go there.
Good strategy - I do the same during development, including sizing my forms
for all the default Toolbar settings which tend to take up alot of screen
real-estate.
As for cookies - I don't use them either, except for 'session-cookies'
which are not the same thing as far as MSIE is concerned... enough said by
me:-)
Cheers....
________________________________________________________________________
TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]
with unsubscribe witango-talk in the message body
