Only apply "do not cache" headers to files inside the the cache folder.

Hi,

status changed to critical.

Thanks for pointing this out. We have Boost installed on a multi-site production server and our root .htaccess was edited according to the boost .htaccess rules which was probably affecting all our sites.

The changes work perfectly and the module is running smoothly.

To confirm for other boost users...edit your main .htaccess file in root and remove the following lines

  <IfModule mod_headers.c>
      Header add Expires "Sun, 19 Nov 1978 05:00:00 GMT"
      Header add Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"
  </IfModule>

Create a new .htaccess file and paste the above lines into it. Upload this file to your cache directory.

To see it working, delete some of your old cached files (which will show small file sizes of around 20 bytes before this change) and then call them with a browser as an anonymous user. You will notice the new file created with boost will be much larger in size (now in kB).

Excellent module!

There is some incorrect information in my last post. It appears that images are not being cached. I notice when visiting the site using ie that the browser continues to request image files on each page load.

The notes about checking file sizes to see if files are being cached may not be true as I notice that boost is creating symbolic links for nodes (in the nodes folder cache/domain.org/0/node). So to see if static files are being created follow the symbolic link.

This bug/by design issue is related only to css/image/js files as the title says and not the actual content as I misunderstood.

I've seen this problem, too. Thank you, firebus, for posting a solution.

Should this be committed to the module? Seems like a good idea....

#3 & #5 works for me, now all are loaded from browser cache if available.

I add these line to the bottom of my .htaccess file and it seems to work.

#Cache These Files Forever - gif|png is a little aggressive, i know.
<FilesMatch "\.(ico|js|css|js.gz|css.gz|gif|png)$">
Header set Cache-Control "public"
Header set Expires "Thu, 15 Apr 2020 20:00:00 GMT"
Header unset Last-Modified
</FilesMatch>

# 2 HOURS - Not sure how well this one works
<FilesMatch "\.(jpg|JPG|jpeg|xml|txt|flv|swf)$">
Header set Cache-Control "max-age=7200, must-revalidate"
</FilesMatch>

Although I should probably re-do some of the above once I read
http://www.askapache.com/htaccess/speed-up-sites-with-htaccess-caching.html
Anyway the reason for boosts Cache-Control settings is for users who log-in and log-out.

Will look into using this method
http://httpd.apache.org/docs/trunk/mod/core.html#directory

untested

<Directory /cache>
  <FilesMatch "\.(html.gz|html)$">
    <IfModule mod_headers.c>
        Header add Expires "Sun, 19 Nov 1978 05:00:00 GMT"
        Header add Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"
    </IfModule>
  </FilesMatch>
</Directory>

"Header set" should be used instead of "Header add", otherwise Apache sends TWO values in Expires and Cache-Control.
Directory tag is not going to work in .htaccess - it should be placed in Apache config directly or the content of this should be added in .htaccess in cache/

Partial commit, adding .htaccess to cache dir not done yet.

Not sure splitting the htaccess file up is the smartest thing to do; seems like it would add too much complexity. If there is a good argument for doing it, please state your case.

+1 for Alexander's comment http://drupal.org/node/185075#comment-1626156

@sidharth_k
"Header set" is already in 6.x-1.x-beta1

The question has to do with mutiple .htaccess files. Is this a vote for that?
http://groups.drupal.org/node/22864
In short every single .htaccess has to potential to slows down apache; with the already included FilesMatch directive it should only apply to *.html & *.html.gz files so it's sorta overkill, thats why I'm asking if this is really needed.

marking wont fix, as <FilesMatch "\.(html.gz|html)$"> is in place. multiple .htaccess files would make this module even more complex.

Figured out an alt way... kinda nuts but simple.
#514156: disable clean url's for all logged in users; allow for browser to cache pages.

moving this back to 5.x

Closing all 5.x issues; will only reevaluate if someone steps up #454652: Looking for a co-maintainer - 5.x

Reason is 6.x has 10x as many users as 5.x; also last 5.x dev was over a year ago. The 5.x issue queue needs to go.

subcribbing...