You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
probably this too:
<META HTTP-EQUIV="EXPIRES" CONTENT="0">
you can also use this javascript to force a unique reload
Code:
<html>
<head>
<script type="text/javascript">
// force a unique page
function uPage(){
// get the current url
var temp=location.href;
// look for the string 'ver=' in the url
if (temp.indexOf('ver=')==-1 ){
// no version numberin url so append a number
// having a unique number will force the browser to re-cache
window.location = temp+"?ver="+genNumber();
}else{
// has a version number so do nothing
}
}
// Generate and return a random number between 1-1000 for uniqueness
function genNumber() {
var i, rannum;
// This will generate a random number 0-1000.
rannum = Math.random()*1000;
// rannum is now a decimal value
// so round to nearest integer
rannum = Math.round(rannum);
return rannum;
}
</script>
</head>
<body onLoad="uPage();">
</body>
</html>
Many people believe that assigning a Pragma: no-cache HTTP header to a representation will make it uncacheable. This is not necessarily true; the HTTP specification does not set any guidelines for Pragma response headers; instead, Pragma request headers (the headers that a browser sends to a server) are discussed. Although a few caches may honor this header, the majority won’t, and it won’t have any effect. Use the headers below instead.
HTML Meta Tags and HTTP Headers
....... Meta tags are easy to use, but aren’t very effective. That’s because they’re only honored by a few browser caches (which actually read the HTML), not proxy caches (which almost never read the HTML in the document). While it may be tempting to put a Pragma: no-cache meta tag into a Web page, it won’t necessarily cause it to be kept fresh.
I have an html file that never changes, how do I insure that it is always read from the browser cache?
is it automatic?
is there a technical paper that explains it?
THANKS!!!!
Always read from the cache? Actually you can't control that, as it's on the user end. For example - I clear my cache frequently and have to re-load things. Just before I run a virus check or defrag all caches are emptied and temporary files cleaned out.
There are a number of options for going the other way (not caching), and for that the best method is to use some simple php code to alter the html headers - basically by ensuring that the file date is always in the future. This will cause the browser to re-load the file every time.
To maximize your odds of keeping something cached on the user's hard drive, set the file date far enough in the past that when the browser checks it sees that the server version is always older or the same as the local version. They'll still reload it after they have cleared the cache though (since then it won't be there).
Just curious - why do you want the page always cached on the viewer's hard drive? Is the page that large that you're worried about bandwidth?
JS
John,
--------------------------------
John Strasser
Phone: 480 - 273 - 8798
i'd use the expires http header i think. i'm actually in the process of doing this with a large web app at the company for which i work. here's what i'm doing:
1. setting up a custom http header for the files that sets the expiration far into the future (a few years). this is done in the web server configuration and is different from version to version of iis and apache.
2. if one of the files changes, i'll have to change the calling URL to ensure that it gets the fresh copy.
for example:
if this is the reference to the version that expires far into the future ...
< img src="http://whatever.com/myimg.gif" >
i'll change the reference to:
< img src="http://whatever.com/myimg.gif?ver1.0" >
when the image changes.
this is technically retrieving the same image as the web server will ignore the stuff after the question mark BUT the web browser doesn't. the web browser considers this a new URL.
yea, that's pretty much what the two papers I read (links in earlier posts) said was best way! I think I understand now, except maybe whether or not includes are cached?? havn't tested it yet.
hi brad, i'm doing just fine. hope all's well with you!
per your question about the cascading effect of the caching ... here's what my testing shows:
suppose i have index.htm which loads script1.js and that, in turn, loads script2.js ...
if i change index.htm to load script1.js?something, it *will* reload script1.js from the server, but *not* script2.js. if you need to script2.js to reload, you'll have to change the reference to it in script1.js by adding something changed to the end of the url that references script2.js.
yea, that's pretty much what the two papers I read (links in earlier posts) said was best way! I think I understand now, except maybe whether or not includes are cached?? havn't tested it yet.
Brad & Don,
"Includes" by definition can't be cached as it is the server that "includes" them. Your browser actually only sees the resulting html to put the page on the screen. That's why they call them "Server-Side-Includes" or SSI <grin>. Same thing for php or other server based scripting languages. The server does the including.
For files like javascript or css files, so long as each file is separate then it will be cached in the browser. Even an "included" css file will be. Why? Because it is the browser that (meaning the user end) that does the including. So long as you don't use a server script to build the file you'll be fine.
As for using the "expires" header, you're better off setting the "expired date" to be only 24 hours in the future, rather than a few years. Same effect and easier to keep track of. Also, it's easy enough to add that as a SSI or have php or asp generate the date header before it goes to the browser. The added bonus is that it's easier to change if you *do* update the page.
Another option to "changing" the url is to use 301 and 302 redirects. You can use these either in an .htaccess file or in any server scripting file (php or asp)
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Tweet
no problem Shawn, that probably would have been my next question anyway!!
Comment