cache non-PHP files that live within Drupal

If you want to see whether I'm telling the truth or not, grab firebug and run it on a regular drupal site. Gasp at the fact that *no* files are cached by the browser properly. Visit other sites to see the difference. Apply this patch and then breathe relief :-)

Per chx's suggestion on IRC

Updated patch after talking with Heine on IRC. Wrap the headers in an IF incase that module is turned off.

Dries, sure:

/**
 * Set HTTP headers in preparation for a page response.
 *
 * Authenticated users are always given a 'no-cache' header, and will
 * fetch a fresh page on every request.  This prevents authenticated
 * users seeing locally cached pages that show them as logged out.
 *
 * @see page_set_cache
 */
function drupal_page_header() {
  header("Expires: Sun, 19 Nov 1978 05:00:00 GMT");
  header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
  header("Cache-Control: no-store, no-cache, must-revalidate");
  header("Cache-Control: post-check=0, pre-check=0", FALSE);
  header("Pragma: no-cache");
}

We send the headers *not* to cache any file.

Now--this is *correct* for PHP files and any dynamic file. It's in correct for regular text and binary files. You'd have to hack this function up to say if the file is an image or css or js or whatever to not send those headers.

This solution instead overrides the headers before anything is sent fixing it for those. It's very clean.

Gerhard just put this patch on Drupal.org and everyone in IRC is acknowledging the fact that the site is *much* more snappier now.

Don't cache html or htm files as per John VanDykes request on IRC.

@chx and @dries - Yes my post about the headers was incorrect. It was made in haste and those headers apply *only* to text/html pages served by Drupal. Does not apply to images, CSS, JS, etc..

@killes - You won't see a huge drop in bandwith/resources right away. Browsers still have local caches--some are session based, others are smarter like Opera, and so forth. But overtime this patch should show a decrease in bandwith/resources provided regular traffic stays constant.

That said, here is what Drupal currently sends for files:

Date	Sat, 06 Jan 2007 03:50:22 GMT
Server	Apache/2.0.59 (Unix) PHP/5.1.6 DAV/2
Last-Modified	Tue, 05 Sep 2006 03:50:56 GMT
Etag	"b676b4-2cd-c40d4800"
Accept-Ranges	bytes
Content-Length	717
Keep-Alive	timeout=15, max=97
Connection	Keep-Alive
Content-Type	text/css

Note, there is nothing about about caching the file. Proxies would not cache this file. Some browsers would look and compare the Etag but not guaranteed IIRC.

So here's a new patch which changes the headers to:

Date	Sat, 06 Jan 2007 03:51:46 GMT
Server	Apache/2.0.59 (Unix) PHP/5.1.6 DAV/2
Last-Modified	Tue, 05 Sep 2006 03:50:56 GMT
Etag	"b676b4-2cd-c40d4800"
Accept-Ranges	bytes
Content-Length	717
<strong>Cache-Control	max-age=1209600
Expires	Sat, 20 Jan 2007 03:51:46 GMT</strong>
Keep-Alive	timeout=15, max=98
Connection	Keep-Alive
Content-Type	text/css

Now, these files can be properly cached--both by proxies, browsers, and everything else.

Here's what changed in the patch:

• Instead of using mod_headers, use mod_expires, this removes this dependency and puts it on one that Drupal already relies on
• Fix the current incorrect usage of mod_expires, since it's worthless without turning it on ;-)
• Add in an expiration default of 2 weeks which applies to all files
• Override this default for PHP pages served by Drupal (which is now *actually* working)

The previous patch was correct, it set Cache-control to 2 weeks explicitly, but it didn't have the properly paired expiration header. By using mod_expires, it automatically adds both headers.

This patch should be ready go. This is a bug in 5 and it's not an API change. Not only that, but it fixes 2 bugs: incorrect usage of mod_expires and the fact that Drupal doesn't send proper headers for files to be cached.

Looks like my <strong> within <code> didn't get rendered. You get the point though :-p

If you still don't know *why* this is useful, have a read:

http://www.websiteoptimization.com/speed/tweak/cache/

(although he incorrectly uses Expires within FileMatch which seems to cause an error on Apache 2, perhaps it works in 1.3 -- concepts are the same though :-)

Right, this applies to a significant number of files. On drupal.org this applies to 38 files out of 39. That's 97% less HTTP requests the *2nd* time around. Not too shabby :-p

Easy fix for 4.7 too :-)

Since in effect the mod_expires in 4.7 is useless without the ExpiresActivate On part (otherwise it's off).

The patch that was commited (D8) will work on 5 and 4.7.