Thanks for the insight Ian and Bob,
surely one downside of doing that at all times is that if you have a
javacript:history.back() button for users who haven't filled out a form
correctly, they then have to re-fill the form out again - can be
frustrating. I would guess that one needs to be selective with which pages
a time is included in the URL then.
Garth
At 08:35 22/07/02 -0700, you 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>
>-----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
>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: [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
>________________________________________________________________________
>TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]
>with unsubscribe witango-talk in the message body
________________________________________________________________________
TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]
with unsubscribe witango-talk in the message body
