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>
> -----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
