views:

101

answers:

4

I have a page where once a button is clicked, it is replaced by an Ajax spinner whilst the user waits for the next page to load.

I am controlling (or attempting to control) caching using .htaccess. If the user hits back (browser button, mouse button, alt+left, backspace) it needs to reload the page from the cache. IEs 6-8 and Chrome were all fine with this. Firefox wasn't working for a while and recently started to work, but the problem seems to be remaining in Safari. This seems a little odd, because I'd have expected Safari and Chrome to behave in the same way.

This is my .htaccess file:

# Add Proper MIME-Type for Favicon
AddType image/x-icon .ico

<IfModule mod_expires.c>
    ExpiresActive On
#   ExpiresDefault A2630000
    ExpiresByType image/x-icon A2630000
    ExpiresByType image/gif A2630000
    ExpiresByType image/jpeg A2630000
    ExpiresByType image/png A2630000
    ExpiresByType application/x-javascript M2630000
    ExpiresByType application/javascript M2630000
    ExpiresByType text/css M2630000
</IfModule>

<IfModule mod_headers.c>
    Header set Cache-Control "public"
    <FilesMatch "\.php$">
        Header set Cache-Control "no-store, no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0"
    </FilesMatch>
</IfModule>

SetOutputFilter DEFLATE

AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/javascript

I've tried it with and without the Cache-Control public line.

I've also tried adding:

AddType application/x-httpd-php .php

with:

ExpiresByType application/x-httpd-php A0

To no avail.

Am I missing something obvious?

Edit: I don't think it's anything to do with the cache settings.

I've tried adding this to the PHP itself:

#safari test
if (strstr($_SERVER['HTTP_USER_AGENT'],'Safari')){
    header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
    header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the past
}

And even without those lines I can see in "inspect element" > resources that the right headers are being received. The problem seems to be what Safari is doing with them in its bid to be "the fastest browser". It would appear that it explicitly ignores what the site developers specificy - this sounds like IE's original mindset from back in the day when tables where used for layouts.

A: 

I had a similar problem with firefox but modifying the .htaccess with the code...

<IfModule mod_headers.c>
  Header set Cache-Control "public"
  <FilesMatch "\.php$">
      Header set Cache-Control "no-store, no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0"
  </FilesMatch>
</IfModule>

...that, ironically, you have in your code, fixed it for me. Not sure about the Safari problem though.

daveyWavey
+2  A: 

The HTTP spec explicitly says that recalling from history (back/forward button) does not have to do cache validation. So this seems valid behaviour.

jilles
Yep, bang on the money. It is after all not a matter of caching (storing responses to reuse for subsequent requests for which they are valid) but of history. It makes little sense to try to change history.
Jon Hanna
A: 

Try adding this as a meta tag in your HTML:

<meta http-equiv="cache-control" content="no-cache, no store, must-revalidate"/>
Jacob
A: 

Is Safari giving you 304 while Chrome does not? If so, I suspect you are using Apache 2.0 and upgrading to Apache 2.2 solves this issue.

amer
Safari's giving a 200 status, as does Chrome.
bcmcfc