Project

General

Profile

Actions

Mod expire » History » Revision 20

« Previous | Revision 20/22 (diff) | Next »
arantius, 2012-08-11 10:42
Without "plus" on lighty 1.4.25, this did not work for me


Controlling the Expiration of Content in Caches

Module: mod_expire

Description

mod_expire controls the Expire and Cache-Control: max-age headers in the Response Header of HTTP/1.0 and HTTP/1.1
messages. It is useful to set it for static files which should be cached
aggressively like images, stylesheets or similar.

Options

expire.url
assigns a expiration to all files below the specified path. The
specification of the time is made up of:

    <access|modification> plus <number> <years|months|days|hours|minutes|seconds>
where access means time of user access and modification means time of file modification. Follows the syntax used by mod_expire in Apache 1.3.x and later. (See: http://httpd.apache.org/docs/1.3/mod/mod_expires.html) Example:
    expire.url = ( "/images/" => "access plus 1 hours" )
Example to include all sub-directories:
    $HTTP["url"] =~ "^/images/" {
         expire.url = ( "" => "access plus 1 hours" )
    }

Troubleshoot

It is known that mod_expire may not work due to an incorrect order of loading of modules. One instance is that mod_expire is loaded after mod_fastcgi. The solution is simple, it is to move mod_expire within the modules array in front of mod_fastcgi. Note: The order of the modules is loaded from top to bottom.

Symptoms of the above scenario is the server starts up fine but fails to serve content.

In 1.4.13 (and probably others) you must load mod_expire BEFORE mod_compress. Otherwise, expires headers will NOT be output when serving a compressed document.

Also, expire.url = ( "/images/" => "access 1 hours" ) did not work for me. I had to use the second form.

I tested in 1.4.18 and above two problem(one is order mod_expire and mod_compress and the other is expire time specification setting) is not appeared.

Updated by arantius over 11 years ago · 20 revisions