Is there a way I can force a page to reload every time someone goes to it, rather than them seeing the page they have cached? I have a calendar for my band. It changes sometimes. People who have cached pages still see the old entries. What can I do?
Thanks
a novice webmaster
instead of using static pages with the same name, serve it up through a PERL script or some other CGI language. That way it is compiled fresh every time and not cacheable (I think)
You can try using meta tags, though these aren’t accepted by every browser. Some of the more useful ones include:
<HEAD>
<META HTTP-EQUIV="pragma" CONTENT="no-cache">
</HEAD>
(Instruction: never cache this page.)
<HEAD>
<META HTTP-EQUIV="expires" CONTENT="Fri, 11 Jun 2004 9:00 GMT">
</HEAD>
(Instruction: a cache of this page is only valid until tomorrow morning. Do not use it after that time.)
These go before the <BODY> tag in your web page.
Not true. The fact that the content was generated on-the-fly on the server has no bearing on whether or not the browser caches it. chrisk nailed it, and I’d only add that using an expires value of -1 is an easy way to handle that header if you want it to immediately expire (equivalent to the no-cache header, but some browsers don’t recognize no-cache and will handle an expires=-1 properly). There’s no reason not to use both, so you can include:
<HEAD>
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
</HEAD>
If you are using server-side code like CGI, ASP, or PHP, there are specific commands for setting these values in the HTTP header as well.
I’ll also add that if you have access to some kind of scripting on your site, there’s a trick to force reloading of any pages reached by links from other pages within the site, (or forms.) Basically, what you need to do is figure out a way to add a random querystring parameter to every link…
<A href=‘page17.htm?rand=45343532’> and so on, with the value of rand being determined by a CGI or scripting program every time the page with the link on it is generated.
The page being linked to doesn’t have to do anything with the ‘rand’ parameter, it’s just there to fool a caching strategy into thinking that the link is to a different page than any previously visited, (such as page17.htm?rand=00034237 ) because browser caches have to treat different querystring parameters as different pages, otherwise most CGI sites won’t work correctly. (amazon.com, for instance, uses a certain template for every product and probably passes a product ID number in the querystring.)
This is a lot of work, I know… just wanted to show off the technique. 
So what you are saying is that if I call “http:\www.whatever.com\loadfresh.pl” (or .php) the browser may still cache the results? Wouldn’t some dopers be having problems with this site caching since the GQ forum list (for example) doesn’t include those meta tags in its header?
D’oh! I did a little browsing and found this nugget: Google Group Link
The little PERL CGI I have done has always been based on a form submit…
Now I can check off the task “Learn something new”.
Hmm… that’s an interesting question, actually… caching based on a dynamic link-based site like the SDMB. A few possibly answers:
the board may set the no-cache and expire values directly in the HTTP header info, where we can’t see them easily. The <META> tags I showed you are workarounds… web page authors can’t generally alter the header information that their pages are sent with, so <META http-equiv> is used as a substitute - a way of saying to the browser ‘pretend that the page arrived with this HTTP header value.’ SDMB may well be set up to send the real thing.
Very few people are actually set up with a cache strategy that doesn’t often directly check for an update to a page before sending through a cached copy. This would discover thread replies on the board, for instance.
it wouldn’t surprise me too much if there were browsers that automatically assumed the pragma nocache for any web page with certain extensions – .asp, .php, .pl, and so on.
chrisk, you’ve given me a couple of good ideas about improving my PHP/MySQL online art gallery database. Would you happen to know if the no-cache headers work universally under all browsers? One of my Staff who uses Opera has had problems with a meta-redirect tag I use sending to a page which should refresh (but doesn’t).
It’s true that plain HTML files don’t allow you direct control of the headers, but most languages used for dynamically generating pages do. For example, in ASP you can do
<% Response.AddHeader "Pragma", "no-cache" %>
In something like Perl CGI, you not only can but must output the HTTP headers (at very least specifying the MIME type) so you can include something like
print "Content-type: text/html
";
print "Pragma: nocache
";
The two blank lines after the pragma header (the
is a newline) indicates the end of the header block and the start of the content.
The pragma tag doesn’t work in some versions of MSIE, which is why you’ll typically see both the pragma no-cache and the expires=-1 used together. One or the other works in almost every case (I don’t know of exceptions but I don’t doubt that there are some browsers that will ignore both). I haven’t specifically tested Opera, but I have never had caching issues in Opera like you see in MSIE. I use Opera for all my non-testing browsing and I frequently miss “problems” that IE users report because they’re dealing with cached versions. I’ll try to make time to specifically test, but my off-the-cuff answer is that Opera will handle these fine.
I’ll have to play around with this stuff someday.
On the other hand, caching problems don’t always happen with the browser. Proxy servers can cache content as well, and sometimes they don’t honor ANY http header properly for cache control. That’s why the randomized (or date-stamped) querystring tag for links came to be… though it doesn’t work on the main page of your site, or any other page that someone might be following from static links or bookmarks.
Nothing’s perfect in this (virtual?) world.
That was the distinction I was trying to make when I said that “web page authors can’t generally alter the header information…” I was specifically referring to people working with plain static HTML, as opposed to dynamic web languages, which (to me) are the domain of “web developers.”
