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]

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

 

[Thomas 'PointedEars' Lahn]

Subject: AJAX html won't refresh after data update

http://www.mnot.net/cache_docs/


PointedEars

 

[cts1]

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

Thanks for the great idea.

J

 

[Thomas 'PointedEars' Lahn]

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

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

 

[cts1]

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

Thanks for the great idea.

J

 

[Thomas 'PointedEars' Lahn]

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

Pure nonsense.

(sic!)

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


PointedEars

 

[Laurent vilday]

Thomas 'PointedEars' Lahn a écrit :

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

 

[Thomas 'PointedEars' Lahn]

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

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

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn a écrit :

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

 

[Bart Van der Donck]

Laurent vilday wrote:

Where is your proof for that?

The proof for IE is below.

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.

 

[Laurent vilday]

Thomas 'PointedEars' Lahn a écrit :

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 !

Non sequitur.

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

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.

 

[Thomas 'PointedEars' Lahn]

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

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

</FAQENTRY>

PointedEars

 

[Thomas 'PointedEars' Lahn]

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

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

If you want proof, then you are welcome to test it yourself.

I am not the one who has to prove the above statement.

You know that, too.

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.

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.

You know that, too.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Laurent vilday said the following on 10/6/2007 12:42 PM:

<FA**NTRY>
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>
</FA**NTRY>

<proposed entry>
4.45 Why is my AJAX page not updated properly when using an HTTP GET
request in Internet Explorer?

Microsoft Internet Explorer caches the results of HTTP GET requests. To
ensure that the document is retrieved from the server, you will need to
use the POST Method.

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

</proposed entry>

Nothing that has not been proven by peer review should be added to the FAQ.
A statement from the MSDN Library is not sufficient to back up a FAQ entry
or even a recommendation in the FAQ. There are statements in the MSDN
Library are biased, insufficient, factually incorrect, or plain nonsense.

But it figures and tells much of your competence of being the FAQ editor (or
rather the lack thereof) that you would consider including such a statement
in the FAQ anyway.


PointedEars

 

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


--

 

[timsamshuijzen]

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

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.

I have followed this post with interest as I have experienced some
strange exceptions to the "IE caches the results of HTTP GET requests"-
rule. I have not found a concise pattern in my findings yet, but I can
conclude that IE's internal caching-strategy "agent" is more complex
than can be listed in a small set of rules. I think that IE has a
large set of rules (including some state-dependencies) for determining
whether to fetch data from cache or to do a reload. In my current
simple test-environment I can reproduce the fact that the "Cache-
Control" and/or "Expires" headers definately have an effect on whether
data is fetched from cache or from a reload (in IE, that is).
Furthermore, IE's caching strategy seems to be dependant on the
requested document's extension, but I am not completely sure of this
statement yet. In any case, with my PHP (-extension) scripts, the
"Cache-Control" and "Expires" headers definately make a difference. On
the other hand, one could argue that setting the headers will not be a
good general solution in forcing reloads, because one also has to take
"forwards compatibility" into account. MS clearly states that the
"POST" method will "guarantee" a page reload, which simply translates
into a meaning that they reserve the right to change their GET-
oriented cache strategy in future versions of IE. 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. If anyone is
still interested in this subject, just let me know and I will post the
code I used during testing.

 

[Thomas 'PointedEars' Lahn]

I have followed this post with interest as I have experienced some
strange exceptions to the "IE caches the results of HTTP GET requests"-
rule. I have not found a concise pattern in my findings yet, but I can
conclude that IE's internal caching-strategy "agent" is more complex
than can be listed in a small set of rules. I think that IE has a
large set of rules (including some state-dependencies) for determining
whether to fetch data from cache or to do a reload. In my current
simple test-environment I can reproduce the fact that the "Cache-
Control" and/or "Expires" headers definately have an effect on whether
data is fetched from cache or from a reload (in IE, that is).

I don't know about Cache-Control (HTTP/1.1), but Expires (HTTP/1.0) is
handled at least since IE 4.

Furthermore, IE's caching strategy seems to be dependant on the
requested document's extension, but I am not completely sure of this
statement yet. In any case, with my PHP (-extension) scripts, the
"Cache-Control" and "Expires" headers definately make a difference.

They will also for other resources, but you have to have a Web server that
supports that and serves the corresponding headers for every such resource.

On the other hand, one could argue that setting the headers will not be a
good general solution in forcing reloads, because one also has to take
"forwards compatibility" into account. MS clearly states that the
"POST" method will "guarantee" a page reload, which simply translates
into a meaning that they reserve the right to change their GET-
oriented cache strategy in future versions of IE.

Even Microsoft has to obey HTTP or they render their UA not working on the
Web. It is highly unlikely that they will not implement one of Expires or
Cache-Control or E-Tag in future versions (provided there will be any).
Microsoft is especially well-known to be backwards-compatible (no matter
how misguided that approach is at times).

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 have not tested
`POST' with XHR there yet) that I have named before. As Microsoft has now
added a Community Content section for each topic, one can only hope that
further such statements are discovered and documented as being bogus.

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.

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.


PointedEars

 

[timsamshuijzen]

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/cachetest/index.php?withserversideheaders=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/cachetest/index.php?withrequestheader=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]

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