AJAX html won't refresh after data update

[javelin]

I created a feature in a page where a DIV displays child records of
the current record. From this same page, I can submit the insertion of
a new child record. However, the while the previous child records
displayed fine, the newly added ones don't - until I close down IE and
restart it. I know, there's a setting in IE options which will force a
refresh on each page load, instead of caching, but I can't access it
from these computers (NT policy prohibits it, I guess). None of the
end users can either, so that's not a solution. Anything I can do
programmatically here?

Thanks.

[Robin]

javelin wrote:

I created a feature in a page where a DIV displays child records of
the current record. From this same page, I can submit the insertion of
a new child record. However, the while the previous child records
displayed fine, the newly added ones don't - until I close down IE and
restart it. I know, there's a setting in IE options which will force a
refresh on each page load, instead of caching, but I can't access it
from these computers (NT policy prohibits it, I guess). None of the
end users can either, so that's not a solution. Anything I can do
programmatically here?

Add a 'unique' variable to the query string of you ajax URI so that
browser doesn't use the cached copy.

i.e.
obj.open('GET','ajax_call.php?recid='+recid+'&z='+
new Date().getTime(),true);
HTH
Robin

[Good Man]

javelin <go*************@spamgourmet.comwrote in
news:11**********************@22g2000hsm.googlegro ups.com:

I created a feature in a page where a DIV displays child records of
the current record. From this same page, I can submit the insertion of
a new child record. However, the while the previous child records
displayed fine, the newly added ones don't - until I close down IE and
restart it. I know, there's a setting in IE options which will force a
refresh on each page load, instead of caching, but I can't access it
from these computers (NT policy prohibits it, I guess). None of the
end users can either, so that's not a solution. Anything I can do
programmatically here?

Send an expired header with your data. Here's a straight lift from PHP
code:

//IE CACHES AJAX PAGES!!!
header("Expires: Sun, 19 Nov 1978 05:00:00 GMT");
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header("Cache-Control: no-store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");

.... followed by the correct headers and data for the XML or whatever output
you send back....

[cts1]

Dang, Robin! That actually works! Not used to getting such good help
the first time around :D

Thanks for the great idea.

J

On Oct 4, 9:52 am, Robin <[e-mail]:

javelin wrote:

I created a feature in a page where a DIV displays child records of
the current record. From this same page, I can submit the insertion of
a new child record. However, the while the previous child records
displayed fine, the newly added ones don't - until I close down IE and
restart it. I know, there's a setting in IE options which will force a
refreshon each page load, instead of caching, but I can't access it
from these computers (NT policy prohibits it, I guess). None of the
end users can either, so that's not a solution. Anything I can do
programmatically here?

Add a 'unique' variable to the query string of you ajax URI so that
browser doesn't use the cached copy.

i.e.
obj.open('GET','ajax_call.php?recid='+recid+'&z='+
new Date().getTime(),true);

HTH
Robin

[Thomas 'PointedEars' Lahn]

ct**@spvision.com wrote:

On Oct 4, 9:52 am, Robin <[e-mail]:

>Add a 'unique' variable to the query string of you ajax URI so that
browser doesn't use the cached copy.

i.e.
obj.open('GET','ajax_call.php?recid='+recid+'&z=' +
new Date().getTime(),true);

Dang, Robin! That actually works! Not used to getting such good help
the first time around :D

Thanks for the great idea.

That idea is BAD because it fills the browser cache with garbage, and so
eventually slows down access to other content. Unnecessarily.

Please don't top-post: http://jibbering.com/faq/
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[cts1]

Dang, Robin! That actually works! Not used to getting such good help
the first time around :D

Thanks for the great idea.

J

On Oct 4, 9:52 am, Robin <[e-mail]:

javelin wrote:

I created a feature in a page where a DIV displays child records of
the current record. From this same page, I can submit the insertion of
a new child record. However, the while the previous child records
displayed fine, the newly added ones don't - until I close down IE and
restart it. I know, there's a setting in IE options which will force a
refreshon each page load, instead of caching, but I can't access it
from these computers (NT policy prohibits it, I guess). None of the
end users can either, so that's not a solution. Anything I can do
programmatically here?

Add a 'unique' variable to the query string of you ajax URI so that
browser doesn't use the cached copy.

i.e.
obj.open('GET','ajax_call.php?recid='+recid+'&z='+
new Date().getTime(),true);

HTH
Robin

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 10/5/2007 2:00 PM:

ct**@spvision.com wrote:

>On Oct 4, 9:52 am, Robin <[e-mail]:

>>Add a 'unique' variable to the query string of you ajax URI so that
browser doesn't use the cached copy.

i.e.
obj.open('GET','ajax_call.php?recid='+recid+'&z= '+
new Date().getTime(),true);

Dang, Robin! That actually works! Not used to getting such good help
the first time around :D

Thanks for the great idea.

That idea is BAD because it fills the browser cache with garbage, and so
eventually slows down access to other content. Unnecessarily.

Pure nonsense.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Thomas 'PointedEars' Lahn]

Randy Webb wrote:

Thomas 'PointedEars' Lahn said the following on 10/5/2007 2:00 PM:

>ct**@spvision.com wrote:

>>On Oct 4, 9:52 am, Robin <[e-mail]:
Add a 'unique' variable to the query string of you ajax URI so that
browser doesn't use the cached copy.

i.e.
obj.open('GET','ajax_call.php?recid='+recid+'&z ='+
new Date().getTime(),true);
Dang, Robin! That actually works! Not used to getting such good help
the first time around :D

Thanks for the great idea.

That idea is BAD because it fills the browser cache with garbage, and so
eventually slows down access to other content. Unnecessarily.

Pure nonsense.

(sic!)

It isn't nonsense, it's a fact. (Or have I overlooked your argument by any
chance?)
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 10/5/2007 7:41 PM:

Randy Webb wrote:

>Thomas 'PointedEars' Lahn said the following on 10/5/2007 2:00 PM:

>>ct**@spvision.com wrote:
On Oct 4, 9:52 am, Robin <[e-mail]:
Add a 'unique' variable to the query string of you ajax URI so that
browser doesn't use the cached copy.
>
i.e.
obj.open('GET','ajax_call.php?recid='+recid+'& z='+
new Date().getTime(),true);
Dang, Robin! That actually works! Not used to getting such good help
the first time around :D

Thanks for the great idea.
That idea is BAD because it fills the browser cache with garbage, and so
eventually slows down access to other content. Unnecessarily.

Pure nonsense.

(sic!)

It isn't nonsense, it's a fact. (Or have I overlooked your argument by any
chance?)

You have overlooked the argument. There is a very good reason for using
a query string to force a reload from the server. And no, headers and
server settings won't satisfy the need.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Laurent vilday]

Thomas 'PointedEars' Lahn a écrit :

Randy Webb wrote:

>Thomas 'PointedEars' Lahn said the following on 10/5/2007 2:00 PM:

>>ct**@spvision.com wrote:
On Oct 4, 9:52 am, Robin <[e-mail]:
Add a 'unique' variable to the query string of you ajax URI so that
browser doesn't use the cached copy.
Dang, Robin! That actually works! Not used to getting such good help
the first time around :D
Thanks for the great idea.
That idea is BAD because it fills the browser cache with garbage, and so
eventually slows down access to other content. Unnecessarily.

Pure nonsense.

(sic!)

It isn't nonsense, it's a fact.

sic !

It is well-known among competent Web developers that IE is suffering a
cache issue with XHR when the call method is "GET". And no headers will
do anything to it.

The only solution is to add a dummy unique variable to the querysting.

*That* is a fact among others !

--
laurent

[Thomas 'PointedEars' Lahn]

Randy Webb wrote:

Thomas 'PointedEars' Lahn said the following on 10/5/2007 7:41 PM:

>Randy Webb wrote:

>>Thomas 'PointedEars' Lahn said the following on 10/5/2007 2:00 PM:
ct**@spvision.com wrote:
On Oct 4, 9:52 am, Robin <[e-mail]:
>Add a 'unique' variable to the query string of you ajax URI so
>that browser doesn't use the cached copy.
>>
>i.e. obj.open('GET','ajax_call.php?recid='+recid+'&z='+ new
>Date().getTime(),true);
Dang, Robin! That actually works! Not used to getting such good
help the first time around :D
>
Thanks for the great idea.
That idea is BAD because it fills the browser cache with garbage,
and so eventually slows down access to other content.
Unnecessarily.
Pure nonsense.

(sic!)

It isn't nonsense, it's a fact. (Or have I overlooked your argument by
any chance?)

You have overlooked the argument.

There was no argument. There was a statement.

There is a very good reason for using a query string to force a reload
from the server. And no, headers and server settings won't satisfy the
need.

You have not stated the reason; that is no argument, it is a statement.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8*******************@news.demon.co.uk>

[Thomas 'PointedEars' Lahn]

Laurent vilday wrote:

Thomas 'PointedEars' Lahn a écrit :

>Randy Webb wrote:

>>Thomas 'PointedEars' Lahn said the following on 10/5/2007 2:00 PM:
ct**@spvision.com wrote:
On Oct 4, 9:52 am, Robin <[e-mail]:
>Add a 'unique' variable to the query string of you ajax URI so that
>browser doesn't use the cached copy.
Dang, Robin! That actually works! Not used to getting such good help
the first time around :D
Thanks for the great idea.
That idea is BAD because it fills the browser cache with garbage, and so
eventually slows down access to other content. Unnecessarily.
Pure nonsense.

(sic!)

It isn't nonsense, it's a fact.

sic !

It is well-known among competent Web developers that IE is suffering a
cache issue with XHR when the call method is "GET". And no headers will
do anything to it.

Where is your proof for that?

The only solution is to add a dummy unique variable to the querysting.

Non sequitur.

*That* is a fact among others !

You have to prove that.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8*******************@news.demon.co.uk>

[Bart Van der Donck]

Thomas 'PointedEars' Lahn wrote:

Laurent vilday wrote:

>It is well-known among competent Web developers that IE is suffering a
cache issue with XHR when the call method is "GET". And no headers will
do anything to it.

Where is your proof for that?

The proof for IE is below.

>The only solution is to add a dummy unique variable to the querysting.
*That* is a fact among others !

You have to prove that.

http://msdn2.microsoft.com/en-us/library/ms536648.aspx

| Microsoft Internet Explorer caches the results of HTTP GET
| requests in the Temporary Internet Files (TIF) folder. In
| most cases, caching improves performance for data that will
| not change frequently. To guarantee that the results are not
| cached, use POST.

If you want to use 'GET' anyway, use a randomized query-string.

--
Bart

[Laurent vilday]

Thomas 'PointedEars' Lahn a écrit :

Laurent vilday wrote:

>It is well-known among competent Web developers that IE is suffering a
cache issue with XHR when the call method is "GET". And no headers will
do anything to it.

Where is your proof for that?

LOL, and you really pretend to know your stuff ?

This issue is *VERY* well known, can't you do a few google search to
know what you talking about ?

Or better, actually spend more time working with the technology you
pretend to know instead of babbling about it ?

You will discover a lot of things. Reality is *far* away from anything
you keep pretending to know !

>The only solution is to add a dummy unique variable to the querysting.

Non sequitur.

<p lang="fr">
Je comprend pas ta langue gamin, te la joues pas avec ton latin pourri !
</p>

>*That* is a fact among others !

You have to prove that.

LOL, why would I have to proove anything ? Since when did c.l.j. became
your helpdesk ? I'm not here to educated you ! Do your searches, read
books (even bad ones), read webpages, experiment, get *LOT* more of real
experience. Then, come back to us if you have any questions !

Days after days, you saying a lot of nonsense without prooving much. Why
would I have to proove anything more to you when I'm right ?

<FAQENTRY>
4.45 [IE - XHR - GET] Why is my AJAX page not updated from IE cache when
using HTTP GET request ?
Microsoft Internet Explorer caches the results of HTTP GET requests. If
you need a non cached version of the page, you will have to use a
randomized query-string or use a HTTP POST request. No headers or server
configuration will do any help to it.
<http://msdn2.microsoft.com/en-us/library/ms536648.aspx>
</FAQENTRY>

ps : Thomas, I already know my english sucks, no need to correct my
english grammar errors in this message except the FAQENTRY of course.

--
laurent

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 10/6/2007 1:18 PM:

Laurent vilday wrote:

><FAQENTRY>
4.45 [IE - XHR - GET] Why is my AJAX page not updated from IE cache when
using HTTP GET request ?
Microsoft Internet Explorer caches the results of HTTP GET requests. If
you need a non cached version of the page, you will have to use a
randomized query-string or use a HTTP POST request. No headers or server
configuration will do any help to it.

That is your statement, still lacking proof.

When I have tested it extensively, it has proof. If you want proof, then
you are welcome to test it yourself.

><http://msdn2.microsoft.com/en-us/library/ms536648.aspx>

There is _nothing_ there that says the caching behavior cannot be controlled
by headers. In fact, it would be very weird behavior if IE's HTTP
implementation would obey cache control headers in normal operation (and it
does) and would not when it is triggered through the IXMLHTTPRequest interface.

Perhaps you should follow the rest of the advice in the post you replied
to and get out in the real world and find out how things really work
instead of trying to defend the way you think things *should* work.
Especially when the way you think they work and the way they work are
not the same.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 10/6/2007 4:35 AM:

Randy Webb wrote:

>Thomas 'PointedEars' Lahn said the following on 10/5/2007 7:41 PM:

>>Randy Webb wrote:
Thomas 'PointedEars' Lahn said the following on 10/5/2007 2:00 PM:
ct**@spvision.com wrote:
>On Oct 4, 9:52 am, Robin <[e-mail]:
>>Add a 'unique' variable to the query string of you ajax URI so
>>that browser doesn't use the cached copy.
>>>
>>i.e. obj.open('GET','ajax_call.php?recid='+recid+'&z='+ new
>>Date().getTime(),true);
>Dang, Robin! That actually works! Not used to getting such good
>help the first time around :D
>>
>Thanks for the great idea.
That idea is BAD because it fills the browser cache with garbage,
and so eventually slows down access to other content.
Unnecessarily.
Pure nonsense.
(sic!)

It isn't nonsense, it's a fact. (Or have I overlooked your argument by
any chance?)

You have overlooked the argument.

There was no argument. There was a statement.

Yes there is. You just missed it.

>There is a very good reason for using a query string to force a reload
from the server. And no, headers and server settings won't satisfy the
need.

You have not stated the reason; that is no argument, it is a statement.

I would explain it to you, again, but it would be the third time in a
single thread where it got explained to you. Perhaps you should follow
the advice given to you and get out into the real world and find out how
things really work instead of how you think they should work.

Maybe then you would even realize why I have the opinion of standards
that I do.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Lee]

Thomas 'PointedEars' Lahn said:

>I am not defending anything. I am saying that not enough proof has
been presented yet for the statement to be accepted as general truth.

Surely you have enough web development experience to know that
when colleagues warn that some feature doesn't work correctly
in some browser, that the warning should be considered to be
at least probably true until you've had a chance to test it.
You only make yourself look silly by asking them to prove the
failure to you.
--

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 10/6/2007 3:45 PM:

Randy Webb wrote:

>Thomas 'PointedEars' Lahn said the following on 10/6/2007 1:18 PM:

>>Laurent vilday wrote:
<FAQENTRY>
4.45 [IE - XHR - GET] Why is my AJAX page not updated from IE cache when
using HTTP GET request ?
Microsoft Internet Explorer caches the results of HTTP GET requests. If
you need a non cached version of the page, you will have to use a
randomized query-string or use a HTTP POST request. No headers or server
configuration will do any help to it.
That is your statement, still lacking proof.

When I have tested it extensively, it has proof.

It has not (logical fallacy: proof by example). Your method of testing may
be flawed. It starts to become proof the moment a peer review has showed
that there are no flaws in your method of testing and that the test result
can be reproduced within the domain of the statement. That would however
require the above statement to be less general, as not all versions of
Internet Explorer can be tested against.

But you already knew that and are simply trolling again.

You really are as stupid as you act, aren't you?

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[timsamshuijzen]

On Oct 7, 2:38 am, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

[e-mail] wrote:

If anyone is still interested in this subject, just let me know and I
will post the code I used during testing.

I'd rather you posted the public URL to your test case(s) as well, so that
one can observe which response headers are sent and what the result of
sending them is.

This is something you could have done yourself from the start. Instead
you seem to have some sort of weird fetish for these troll-like
discussions.

Back on-topic:
A simple method that also seems to do the job (force non-cache re-
fetch with a GET method) is the following:

XHRObject.setRequestHeader("If-Modified-Since", "Sat, 1 Jan 2000
00:00:00 GMT");

I tested this in IE 7 and it does force a re-fetch. This method might
be usefull for those who have no control over the server side headers,
want to use the GET method as opposed to the POST method, and do not
want to use the unique-variable-in-query-string method.

Here are some URL's to my very simple test script for testing the
various GET methods:

Without any server-side/client-side "ignore cache" headers:
http://www.samshuijzen.nl/tim/cachetest/index.php
(IE uses cache)

With a number of various server side "ignore cache" headers:
http://www.samshuijzen.nl/tim/cachet...rsideheaders=1
(IE does a re-fetch each click)

Without server-side "ignore cache" headers, with "If-Modified-Since"
request header:
http://www.samshuijzen.nl/tim/cachet...equestheader=1
(IE does a re-fetch each click)

Tip: Firebug will show the headers sent and returned.

If anyone encounters a problem with these tests, please let me know.

Tim Samshuijzen

[Thomas 'PointedEars' Lahn]

ti************@gmail.com wrote:

On Oct 7, 2:38 am, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

>[e-mail] wrote:

>>If anyone is still interested in this subject, just let me know and I
will post the code I used during testing.

I'd rather you posted the public URL to your test case(s) as well, so that
one can observe which response headers are sent and what the result of
sending them is.

This is something you could have done yourself from the start. Instead
you seem to have some sort of weird fetish for these troll-like
discussions.

I have no need of testing as I have been using cache controlling HTTP
headers successfully for several years now. You will observe that we had a
discussion about this in another context in this very newsgroup about a year
before; the arguments against those headers and in favor of a changing query
part were much the same, and no proof whatsoever that they don't work had
been provided then by the people who made those arguments (which
unsurprisingly include at least one person who is arguing in much the same
way now.)

What you call troll-like discussion I call the reasonable and necessary
attempt to demand proof for statements that are very unlikely to be true.
It is up to the people who made those statements/arguments to prove them
eventually; it is _not_ up to me to prove their statements/arguments wrong.

Logical fallacy: shifting the burden of proof.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Bart Van der Donck]

Thomas 'PointedEars' Lahn wrote:

[...]
Microsoft is especially well-known to be backwards-compatible (no matter
how misguided that approach is at times).

On the contrary. Microsoft has a constant need to boost up their
sales, and they repeatedly announce not to support earlier products
anymore. NT, MS Access, Web Components, etc. Any experienced Microsoft
developer will tell you the same.

The statement in the MSDN Library (which is not a statement from Microsoft
but a statement of the MSDN Library editor(s)) is one that falls in the
category "insufficient" or even "factually incorrect"

I find the cited text very well formulated. Read it again - IMO the
author chooses his words very carefully. It's a mistery to me how you
would ever motivate your claim; which "fact" would be "incorrect" ?

| Microsoft Internet Explorer caches the results of HTTP GET
| requests in the Temporary Internet Files (TIF) folder. In
| most cases, caching improves performance for data that will
| not change frequently. To guarantee that the results are not
| cached, use POST.

>I (regret to say that I) agree with PointedEars that setting a unique
variable to the query string is a bad solution for forcing page reloads.
But I am also saying that I do not know a better alternative solution.

Have you not just confirmed that cache control headers have an effect?
That is not just random chance.

These headers don't deserve a status of "can be relied upon".

--
Bart

[Robin]

Thomas 'PointedEars' Lahn wrote:

ct**@spvision.com wrote:

>On Oct 4, 9:52 am, Robin <[e-mail]:

>>Add a 'unique' variable to the query string of you ajax URI so that
browser doesn't use the cached copy.

i.e.
obj.open('GET','ajax_call.php?recid='+recid+'&z= '+
new Date().getTime(),true);

Dang, Robin! That actually works! Not used to getting such good help
the first time around :D

Thanks for the great idea.

That idea is BAD because it fills the browser cache with garbage, and so
eventually slows down access to other content. Unnecessarily.

Please don't top-post: http://jibbering.com/faq/

Wow. Didn't expect my little post to cause such 'discussion'.

I tend to go with the easiest solution that I know works and the unique
querystring method is that to me. Leaves me more time to tackle the more
complex parts of the project.

Anyway, I've serious doubts that the browser will have problems with (or
serious delays in) clearing any 'garbage' out of its cache. No more so
than normal lengthy browsing would fill it anyway.

Actually, Thomas, as you're asking others for proof; have I missed the
post where you prove the "eventually slows down access to other content"
statement?

Robin