AJAX hits being cached??

[matt.delvecchio]

hello,

im working on my first production AJAX project, and im noticing
something weird.

when my clientside events fire (user clicks on various product rows), i
make an xmlhttp call. in this call i hit a URL and pass it the clicked
productID, such as: "/ajax/productDetail.aspx?pid=666666". this page
produces XML direct from the database and i render it onscreen. cool.

but what ive noticed is, if this data changes in the db, the AJAX
clientside requests dont get the latest data . but, if i hit the
"/ajax/productDetail.aspx?pid=666666" url directly in a web browser
(where i can see the fresh data), and then go *back* to the clientside
app & try again, it gets the latest data!

so on the surface it looks like the ajax calls to the URL are somehow
cached. can anyone speak to this possibility?

i am running IE 6, win, IIS 5.



my code:


var xmlhttp = false;

//win/IE
try {
xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
} catch (e2) {
xmlhttp = false;
}
}

//make the call
xmlhttp.open("GET", url, false); //setting async to false due to
previous lag

xmlhttp.onreadystatechange = function()
{
if (xmlhttp.readyState == 4) //ready
{
if (xmlhttp.status == 200) //success
{
var xml = xmlhttp.responseXML;

if (xml.documentElement){
// [does rendering stuff]
}

} else {
alert('There was a problem retrieving the data:\n' +
xmlhttp.statusText);
}
}
xmlhttp.send(null)
}


.....this code successfully produces the xml object that i then render
into htlml DIV tags. but the data its getting is stale.

thanks!
matt

 

[António Marques]

(...) but what ive noticed is, if this data changes in the db, the
AJAX clientside requests dont get the latest data . but, if i hit the
"/ajax/productDetail.aspx?pid=666666" url directly in a web browser
(where i can see the fresh data), and then go *back* to the
clientside app & try again, it gets the latest data! (...)

Iirc, IE caches ajax GET requests by default. Maybe setting some header
on the response (within the server) can solve it. A workaround is to
use POST requests, which may or may not be deemed acceptable (it surely
isn't pretty, but has no side effects that I know of. I don't know
everything, though).

 

[Richard Cornford]

im working on my first production AJAX project,

I doubt that you will take it well, but I suspect that you are not yet
qualified for that undertaking.

and im noticing something weird.

And archive search would reveal that it is neither unusual nor uncommon.

so on the surface it looks like the ajax calls to the
URL are somehow cached. can anyone speak to this possibility?

Any resource accessed with HTTP may be cached. Factors influencing
caching include browser settings, HTTP headers sent with the request and
the type of the request. GET requests are particularly prone to being
cached.

Writing an AJAX project without a familiarity with RFC 2616 (HTTP 1.1)
is distinctly optemistic.

var xmlhttp = false;

//win/IE
try {
xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
} catch (e2) {
xmlhttp = false;
}
}

What is the point of having the - catch - clause set the xmlhttp
variable to false if you then go on to call a method of xmlhttp without
verifying that it is not false at that point?

Is this for an Intranet? otherwise assuming that ActiveX will be
available on the client is also optimistic.

//make the call
xmlhttp.open("GET", url, false); //setting async to false due
to previous lag

<snip>

Making synchronous XML HTTP requests is a mistake. You should solve the
issue that makes you think it is necessary now because it will become a
problem very soon, and when it does you may have gone too far to make
going back to this point and solving the issue properly an appealing
prospect.

Richard.

 

[petermichaux]

hello,

im working on my first production AJAX project

From a brief glance at the code you posted it looks like you are taking

care of the cross browser issues yourself. Have you thought about using
code like Yahoo! UI connection library or the code at ajaxtoolbox.com?
These might reduce the number of things you have to worry about.

Disclaimer. Perhaps you are doing something special that needs custom
code. (Have to be careful with what you say around here.)

Peter

 

[Arnulf Sortland]

make an xmlhttp call. in this call i hit a URL and pass it the clicked

productID, such as: "/ajax/productDetail.aspx?pid=666666". this page
produces XML direct from the database and i render it onscreen. cool.

Try to add a timestamp:
var tm=new Date();
... "/ajax/productDetail.aspx?pid=666666&time="+tm.getTime();

and/or do something with response header as António suggest

include xmlhttprequest.js from Andrew Gregory:
http://www.scss.com.au/family/andrew/webdesign/xmlhttprequest/

and use XMLHttpRequest() for all browsers

I also recommend JSON for better portability between browsers

arnulf @ http://rlb.no/my/

 

[matt.delvecchio]

I doubt that you will take it well, but I suspect that you are not yet

qualified for that undertaking.

hi richard, mind if i call you DICK?

i know it may shock your uber-brain, but this stuff aint rocket
science. the balance of world economies or life & limb are neither at
stake. its a web app. big whoop.

i was writing clientside code w/ the MS xmlhttp object in 2002,
probably long before you hopped on the "AJAX" bandwagon. we just didnt
call it as such back then, and there was no uniform browser support --
only intranets on IE. which, happily, is what i am working on again
now, 4 years later.

however, as my particular focus of coding generally shifts from project
to project, depending on my clients, i dont remember all the
particulars of lesser-used areas. do you? great! i can admire that.
wish i had your memory.

What is the point of having the - catch - clause set the xmlhttp
variable to false if you then go on to call a method of xmlhttp without
verifying that it is not false at that point?

again, another shock to your brain -- i snipped my code samples for
brevity. you know, the whole "Save the Bandwidth!" thing?

Is this for an Intranet? otherwise assuming that ActiveX will be
available on the client is also optimistic.

yes, i am aware of my clients environment, thanks.

Making synchronous XML HTTP requests is a mistake.

as you have no idea what the context of this code is, ill be the judge
of that. but thanks for the concern.


arrogant & snide posts aside, the problem here was that of caching,
from the xml-producing page. two simple response headers (recommended
from another forum, where, amazingly, people are friendly instead of
righteous) put an end to that.


but thanks for your 'tude, dude. you may have the last word -- insult
me further, mock my l0053r skillz, whatever it is that makes you feel
good about yourself. me, im a professional, and i like to spend as
little time not-coding & not-billing as possible. as such, this thread
is no longer on my watched items.

flame on!!


matt