To provide redundancy, use the <META> tag in your HTML. Check here for info:
http://www.htmlhelp.com/reference/wilbur/head/meta.html

Will that apply to proxy servers as well? I want to prvent caching on all levels...
_______________________________________________
"Intelligence is a tool used achieve goals, however goals are not always chosen wisely..."

Unfortunately, you can't guarentee that at all; the Expires header is defined in the standard, and therefore, any proxy should follow it, but as with users and homegrown browsers, they don't have to. I know that in recent discussions on my isp's newsgroups on the possibly of installing a proxy, most proxies that are used at a large scale site are home grown and typically have had much trouble with 80% of the web sites out there that *don't* follow the standard.

Again, falling back on a sessionid and other tracer should help prevent problems from cached page use.

---

Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain

I want to prvent caching on all levels...

Remember, you can't prevent anything. This is the #1 thing that web creators seem to be not able to understand: Once that page leaves your server, it's outta your hands. You don't know who's going to render it, or cache it, or index it, or whatever.

Basically, my point is, the cache things are suggestions at best. Nobody enforces them, and Lord only knows what mutant and/or broken browsers might be out there.

xoxo,
Andy

# Andy Lester  http://www.petdance.com  AIM:petdance
%_=split';','.; Perl ;@;st a;m;ker;p;not;o;hac;t;her;y;ju';
print map $_{$_}, split //,
'andy@petdance.com'

use CGI qw(:standard);

print header(-pragma => 'no-cache');
[download]

stephen

I've had better luck with "Cache-control: no-cache". It's the HTTP/1.1 version of "Pragma: no-cache". All of the caching proxies I know of support HTTP/1.1.

If you're truly paranoid, you can use both.

In addition to using the correct HTTP headers, I've had some success in using unique IDs appended to the script URL as the path info. e.g.: http://domain/script.pl/UNIQUE_ID

koolade's suggestion echoes an approach that has worked well for me. Here's a bit of (slightly verbose) code to illustrate:

sub make_rand_str {
   my $num_chars = shift;
   my @possible_chr_array = @_;
   my $num_possibles = @possible_chr_array;
   my $rnd_str = "";
   for (my $i=$num_chars; $i--;) {
      $rnd_str .= $possible_chr_array[rand($num_possibles)];
   }
   return $rnd_str;
}

my $rnd_str = make_rand_str(4, "A".."Z", "0".."9");

my $url = "http://my/host/cgi/script.pl/$rnd_str",
[download]

Aside from the no-cache pragma, which I find works for 98%+ of folks out there, I find the simplest and easiest way to create a unique string is just a call to time(); e.g.,

$url = '/cgi-bin/script.pl?time=' . time();

Using both of these things in combination results in 99.9% effectiveness in preventing caching. (Estimates based on a scientific survey created by top scientists which was just recently pulled out of my *.)

If you use a "force content expiration" scheme that relies only on using a unique ID in the URL, you run a risk: If there is a caching proxy between the web server and some browser, that proxy's cache is going to hang on to otherwise expired content (i.e., prior unique IDs and their responses), and will spill valid content sooner, thus reducing the effectiveness of the cache.

To be friendly to caching proxy servers, use "Cache-control: no-cache" as part of your scheme.

By the way, caching proxy servers are starting to crop up all over. I'm seeing a lot of them near corporate firewalls, as a means for the corporation to better utilize bandwidth.

Cache-control: no-cache
Pragma: no-cache
Expires: (time)
[download]

This should catch all variants of agents and intermediaries, however, I expect there are still a few old/badly behaved agents out there...

--
RatArsed