Boost not serving cached pages
gregarios - November 7, 2009 - 22:38
| Project: | Boost |
| Version: | 6.x-1.14 |
| Component: | Apache integration |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
For some reason, my Boost installation is no longer serving the cached version of pages. Pages are being cached and erased from cache as expected, but anonymous browsers never show cached pages loaded. Tried deleting caches, hitting the reset button, restarting the server. By the way, are all the pages supposed to end in "_.html" in the cache? I thought it was just ".html" before, but I can't remember...
Running Drupal 6.14, Apache 2.2.11, PHP 5.2.9
PS: Verified in shell that the Boost timestamp is indeed appearing at the bottom of cached pages.
#1
So apache is not serving the cached version correct?
Would you mind posting your htaccess file? Also can you verify by hitting your site from another browser.
_.html is how I was able to reduce the number of htaccess rules required; change went in a long time ago.
#2
Correct. Apache is not serving up the cached version. Site seems to work great otherwise. Tried Safari 4.03 Mac, Explorer 8 Windows XP, Firefox 3.5.5 Mac -- all with the same results -- normal pages served, not cached pages.
Attached is my .htaccess file.
The site is www.kpbj.com. The front page is not cached, so try any article (full node) pages.
#3
what folder is the cache being saved to?
#4
...in the cache directory.
Here is a test for ya... go to this cached page directly:
http://kpbj.com/cache/kpbj.com/advertising_information_.html
But go there through Drupal and it serves up only the Drupal version:
http://kpbj.com/advertising_information
PS: I just tried using the "boosted2.txt" file instead of the "boosted1.txt" to see if it made a difference and it didn't.
#5
your htaccess file does not match the folder path. Grab the htaccess from the boost-rules page and try again.
#6
I see... the default cache directory changed since I installed it maybe? That fixed it. Thank you! :-)
#7
yes, it has changed; splitting the gzip and non gzip content isn't the best idea for the most part. 99% of users don't have over 100k files in a single dir so it's not that much of an issue if you put both in the same dir.
#8
I also had this problem and my hta.access was fine
I found this in the issues that fixed it:
http://drupal.org/node/204832#comment-718371
#9
Automatically closed -- issue fixed for 2 weeks with no activity.