Local versus live cache - PHP setting breaking cache

Day later local 304s, live server overrides code foring HTTP 200.

[JAB Creations]

I'm having one of those wonderful local works live does not scenarios. I've implemented a cache feature. Locally if I set the clock ahead by a day the files are requested and my local server correctly returns 304 Not Modified response as it should. Unfortunately on my live server with the exact same code if I make the initial request and then set the clock ahead by a day it forcibly downloads fresh copies / HTTP 200. For clarification I've ensured that when I change the clock I do so at the correct times (in regards to the date modified) so that is not a mistake that I'm making.

Since my code is exactly the same I can only conclude that there is a setting on the live server that I'm going to be forced to override. I tried session_cache_limiter('private_no_expire'); without luck (it worked for when starting a session would break the cache however that seems to be a different issue altogether). Suggestions please?

- John

[eelixduppy]

I would check both php.ini files for differences in how things are being cached. Maybe it's also a configuration issue with your web server and not PHP? Hard to say from here.

[JAB Creations]

After a lot of testing I can only think of one possible scenario: the server's clock is behind my clock. That would explain why the last modified date is set to Thu, 01 Jan 1970 00:00:00 GMT instead of the file's real date. Any suggestions on how I can find what the server's clock is set to? I've worked to get the minimal amount of code working, here is what I have...

- John

<?php
header('Cache-Control: max-age=10'); // Quick testing.
$lastmod = getlastmod();

if (isset($_SERVER['HTTP_IF_MODIFIED_SINCE']) && strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) >= $lastmod)
{
 header('HTTP/1.1 304 Not Modified');
 die();
}
else
{
 $gmtDate = gmdate('D, d M Y H:i:s\G\M\T',$lastmod);
 header('Last-Modified: '.$gmtDate);
 echo 'Last-Modified: '.$gmtDate;
}
?>

[JAB Creations]

Well I resolved the constant HTTP 200 responses. However after I upload the file to the live server, clear my browser cache, request the file, test it once before the max-age kicks in (no HTTP request is made), request past the max-age (HTTP request made) and then turn the clock forward one day on my computer the server then proceeds to ALWAYS make the request with HTTP 304 responses every time whereas I want it to pull from the cache/hard drive. I'm not sure what I'm missing. Here are the two variations I've tried out and there are no differences in the way the server responds...

- John

<?php
session_cache_limiter('private_no_expire');
date_default_timezone_set('GMT');
header('Cache-Control: max-age=10');
$lastmod = getlastmod();

if (isset($_SERVER['HTTP_IF_MODIFIED_SINCE']) && strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) >= $lastmod)
{
 header('HTTP/1.1 304 Not Modified');
 die();
}
else
{
 $expires = $lastmod + 12;
 header('Expires: '.gmdate('D, d M Y H:i:s',$expires).' GMT');
 header('Last-Modified: '.gmdate('D, d M Y H:i:s',$lastmod).' GMT');
 echo 'Last-Modified: '.gmdate('D, d M Y H:i:s',$lastmod);
}
?>

<?php
header('Cache-Control: max-age=10');
$lastmod = getlastmod();

if (isset($_SERVER['HTTP_IF_MODIFIED_SINCE']) && strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) >= $lastmod)
{
 header('HTTP/1.1 304 Not Modified');
 die();
}
else
{
 header('Last-Modified: '.gmdate('D, d M Y H:i:s',$lastmod).' GMT');
 echo 'Last-Modified: '.gmdate('D, d M Y H:i:s',$lastmod);
}
?>

[JAB Creations]

I tested Firefox 3.6, Firefox 4.0, Opera 11, IE8, Safari and Chrome. Opera and IE turned out to be the most useful, they did not make every request a 304 by ignoring the cache after I set the computer's clock ahead by a day. Chrome and Safari were not helpful absent of go buttons. Either my code is off or there is a bug in Firefox. I'll post a bug later this evening.

- John

[JAB Creations]

This bug was already recently submitted however I attached my code and amended my own report to the bug.

(Site won't make this in to a link for some reason?)
https://bugzilla.mozilla.org/show_bug.cgi?id=628998

- John