Pointed Ears may have a good amount of knowledge, and maybe a good
amount of experience with development with the XmlHTTPRequest Object,
but what he is pushing is his knowledge, but not practical experience.
Others have been expressing that practical experience with this object
does have responses being cached in the browser, this is for a variety
of reasons:
1. Server is not configured to expire content
2. Client Browser is just holding on to the cached version of the
response.
To name two reasons.
The truth is, that no matter how much knowledge you have if you do not
expect the worse case with your applications it is doomed to faile.
Take this example, I build a web application that runs in IE and I use
XmlHTTPRequest to get me data so that I can update my web interface,
but I am using a service that I did not build and I have no control
over. They are not going to change their server settings for just my
one application and I need to use this so that I can get my application
running. So I set my headers and test out hitting the service, but end
up always getting back the same information, I then add the Unique ID
and get fresh data each time I make the request. This is a real world
example of using all the knownledge being thrown around, and exists in
many applications today. Now if you were to create your own data
channel that the XmlHTTPRequest Object is to use, then you make the
header changes on the server and test the application calling it with
out the Unique ID, if this works by giving you freash data every time,
then you have your solution but if you find it buggy and it isn't 100%
reliable you must add the extra over head of a Unique ID to make it
that way.
The application is what takes priority not the theory of what should
work and how it should work. The web was built by people with all
levels of knowledge and personalities. Some do not even want to change
there data services others are more than willing to make a change as
long as that they see it benifical.
Received on Sat Dec 3 04:32:38 2005