To Dan and the others relating to the caching issues .. I offer the attached post from the last time that I wrestled this issue to the ground.
And wrestle it to the ground we did. Dan .. I believe that, if you are suffering at the mercy of a caching proxy server, then the attached will solve your issue. It speaks directly to what we spoke by phone about this afternoon. Interestingly, your name is attached to this older thread, too. I can attest to the fact that our caching issues evaporated with the introduction of a dynamically-generated URL, per the JavaScript code below. And we do know for sure that your first hit to your taf has no other non-caching measures implemented, meaning: -- you hit it from a static URL. Therefore, the symptoms are predictable, meaning, -- a static URL is used to hit a TAF, and the proxy sever caches the resulting code, including the header, which includes the user reference cookie and any page with hyperlinks with a user reference argument appended. -- a second person hits the same page, and the cached copy of the code is returned, thus giving the same user reference argument out to another person. Note: this is only a problem if the first user still has user-scoped variables ... or to be specific in your case, is still logged in. If they have logged out, and you have purged the user-scoped variables, there is no (real) harm and no discernable problem in giving a second person the first person's user reference argument (still undesirable behavior of the code, in any case). Thus, your problem only materializes when, as you said, you have higher load. If this doesn't solve your problem, I'll eat my shorts. ... but you might have to wait until the next Witango conference to see that !! ... (this better work !) Ian -----Original Message----- From: Ian Daniel [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 11, 2001 3:23 PM To: [EMAIL PROTECTED] Subject: RE: Proxy Problems Ah, well ... you see, we've elevated this discussion some. The problem of proxies and other caches ... is largely overcome, when you can dynamically generate a URL that is different every time. Once they log onto a Tango (or ASP, for that matter) application, it's quite easy to remember to send them a unique identifying argument, that means nothing. Here at NCOL, we call that a "no-cache" argument, and it looks like this in our snippets folder, appending onto the end of whatever else we have in the URL. We use a hash of the currenttime, to be sufficiently distinct: &_nc=<@CIPHER action=hash str=<@CURRENTTIME>> The problem remains, when someone first hits a TAF, which generates a user reference number. They would normally hit that TAF from a static page, hence the first time the TAF is hit, it could be cached, including the user reference number on all the links it contains. So, to avoid bringing up the cached TAF, we need a way to uniquely hit that TAF in the first place (or more accurately, the second place -- for the second user to try and hit the TAF), even though we may do so from another cached HTML page. Enter JavaScript. The script generates the unique URL ***in the browser*** thus defeating any cached TAF page out there. I should think it was the was the final chink in our anti-cacheing armour, and should (we'll see tomorrow) solve all of our outstanding problems. PS -- for the uninitiated, there is a separate and very good discussion to be had around preventing things from being cached at all. The thread I describe above ... is where you've done all you can to prevent cacheing, and things still cache. Then what? Then our methods, described above. .. or so I hope .... I will report in with the results ... but I do believe this will have it licked. Ian -----Original Message----- From: Lee Sobo [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 11, 2001 3:03 PM To: [EMAIL PROTECTED] Subject: RE: Proxy Problems To Ian, etc. I'm not sure how the random generator, javascript code will fix the problem. I understand that it will create a random url for the logon page, but what about after that? ----- Original Message ----- From: "Ian Daniel" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, March 10, 2001 10:53 PM Subject: RE: Proxy Problems > To Dan and Robert: > > The two of you had equally good suggestions using JavaScript, one for the > random number generator, the other to set and retrieve a unique cookie, to > force a unique call back to through the proxy when trying to go from the > static page to the dynamic page. The latter, dealing with cookies, could be > defeated by the user ... so I'm less inclined. > > I am opting for the random number generator, like so: > > <SCRIPT LANGUAGE="JavaScript"> > document.write("<A HREF='http://www.domain.com/qry/logon.taf?";); > num=Math.floor(99999999999999999*Math.random()); > document.write(num); > document.write("'</A>Logon"); > </SCRIPT> > > I won't get another chance to test this with the users 'till Monday morning, > but I'm feelin' pretty darned smug about it fixing the problem. > > By the way, the number above is about the largest random number a person > could generate. If you add another nine on the end, at least one browser > just returns a zero for the next significant digit. > > With serious thanks for your help. I think we should be away !! > > Ian > > -----Original Message----- > From: Dan Stein [mailto:[EMAIL PROTECTED]] > Sent: Saturday, March 10, 2001 6:13 PM > To: [EMAIL PROTECTED] > Subject: RE: Proxy Problems > > > I see the problem. What about using a random number generator based on > JavaScript with the static page to force the cleared cache from there. > > If it is caching software not the proxy server then I am only taking AWAG > with the above and the only other thing I could think of would be to go to a > Taf first that dumps the cache and then goes to the login. > > Is Tango Cache on or off? > > on 3/10/01 7:33 PM, Ian Daniel at [EMAIL PROTECTED] wrote: > > > > > We have a static home page, which has a hyperlink to a TAF. Of course, > there > > is no URN or other unique identifier yet involved. Clicking that takes > you > > to a Logon screen, generated by Tango, returning a URN. Therein lies the > > issue, as you'll see. Here's the sequence: > > -- > Dan Stein > Digital Software Solutions > 799 Evergreen Circle > Telford PA 18969 > 610-256-3843 > 215-703-0783 > Fax 419-821-3048 > FMP,Tango, EDI > [EMAIL PROTECTED] > > > > The Tango-Talk List Server is a service of Pervasive Software > <http://www.pervasive.com> > To remove yourself from this list click here: > <mailto:[EMAIL PROTECTED]?subject=unsubscribe> > To obtain a list of commands for this list click here: > <mailto:[EMAIL PROTECTED]?subject=help> > > All Subscriptions can be maintained through http://devtalk.pervasive.com. > Just Login first and go to the User Options page. > > Sent to: [EMAIL PROTECTED] > > > > The Tango-Talk List Server is a service of Pervasive Software <http://www.pervasive.com> > To remove yourself from this list click here: <mailto:[EMAIL PROTECTED]?subject=unsubscribe> > To obtain a list of commands for this list click here: <mailto:[EMAIL PROTECTED]?subject=help> > > All Subscriptions can be maintained through http://devtalk.pervasive.com. Just Login first and go to the User Options page. > > Sent to: [EMAIL PROTECTED] > > The Tango-Talk List Server is a service of Pervasive Software <http://www.pervasive.com> To remove yourself from this list click here: <mailto:[EMAIL PROTECTED]?subject=unsubscribe> To obtain a list of commands for this list click here: <mailto:[EMAIL PROTECTED]?subject=help> All Subscriptions can be maintained through http://devtalk.pervasive.com. Just Login first and go to the User Options page. Sent to: [EMAIL PROTECTED] The Tango-Talk List Server is a service of Pervasive Software <http://www.pervasive.com> To remove yourself from this list click here: <mailto:[EMAIL PROTECTED]?subject=unsubscribe> To obtain a list of commands for this list click here: <mailto:[EMAIL PROTECTED]?subject=help> All Subscriptions can be maintained through http://devtalk.pervasive.com. Just Login first and go to the User Options page. Sent to: [EMAIL PROTECTED] ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
