PFSense - Squid - Refresh Patterns

Refresh patterns determine what is saved and served from the cache.

Ideally, you would want your squid to follow the directions of the Web servers serving the content to determine what is cacheable and for how long.

These directions are set as HTTP headers that are processed and understood by Squid.

Unfortunately, the directions given by most servers are the Web servers’ defaults, and do not produce significant bandwidth savings.

Master Refresh Pattern

Squid Refresh Patterns Master List

Other Squid Refresh Patterns

Squid Refresh Patterns - Anti-Virus

Squid Refresh Patterns - Facebook

Squid Refresh Patterns - Microsoft

Squid Refresh Patterns - Ubuntu

Squid Refresh Patterns - YouTube

Squid Refresh Patterns - Catch-All

Refresh Pattern Format

Refresh patterns are of the format:

refresh_pattern [-i] regex min percent max [options]

where min and max are time values in minutes and percent is a percentage figure. The options are:

override-expire — ignores the expire header from the Web server.
override-lastmod — ignores the last modified date header from the Web server.
reload-into-ims — a reload request from a client is converted into an If-Modified-Since request.
ignore-reload — a client’s no-cache or “reload from origin server” directive is ignored. The request can therefore be satisfied from the cache if available.
ignore-no-cache — a no-cache directive from the Web server which makes an object non-cacheable is ignored.
ignore-no-store — a no-store directive from the Web server which makes an object non-cacheable is ignored.
ignore-private — a private directive from the Web server which makes an object non-cacheable is ignored.
ignore-auth — objects requiring authorisation are non-cacheable. This option overrides this limitation.
refresh-ims — a refresh request from a client is converted into an If-Modified-Since request.

Consult your configuration file to see which of these options are available in your version of Squid.

Refresh Pattern Effectiveness

Refresh patterns are effective if there is no expire header from the origin server, or your refresh pattern has an override-expire option. Example:

refresh_pattern -i .gif$ 1440 20% 10080.

This says:

If there is no expire header for all objects whose names end in .gif or .GIF (that is, image files) then:
- if the age (that is how long the object has been on your cache server) is less than 1,440 minutes, then consider it fresh and serve it and stop
- else if the age is greater than 10,080 minutes, consider it stale and go to the origin server for a fresh copy and stop
- else if the age is in between the min and max values, use the lm-factor to determine freshness. lm-factor is the ratio of the age on your cache server to the period since creation or modification of the object on the origin server as a percentage. So if the object was created 10,000 minutes ago on the origin server and it has been on my cache server for 1,800 minutes (that is the age) the lm-factor is 1,800/10,000 = 18%.
- If the lm factor is less than the percent in our refresh pattern (20%) then the object is considered fresh; serve it and stop
- else the object is stale, go for a fresh copy from the origin server.

For objects that scarcely change under the same file name, such as video, images, sound, executables, and archives, you can modify the refresh pattern to consider them fresh on your Squid for a longer time, increasing the probability of having hits. For example, you could modify our refresh pattern above to:

refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i .(gif|png|jpg|jpeg|ico)$ 10080 90% 43200                               override-expire ignore-no-cache ignore-no-store ignore-private
refresh_pattern -i .(iso|avi|wav|mp3|mp4|mpeg|swf|flv|x-flv)$ 43200 90% 432000            override-expire ignore-no-cache ignore-no-store ignore-private
refresh_pattern -i .(deb|rpm|exe|zip|tar|tgz|ram|rar|bin|ppt|doc|tiff)$ 10080 90% 43200   override-expire ignore-no-cache ignore-no-store ignore-private
refresh_pattern -i .index.(html|htm)$ 0 40% 10080
refresh_pattern -i .(html|htm|css|js)$ 1440 40% 40320
refresh_pattern . 0 40% 40320

Sometimes, for no good reason, at least from our perspective, origin servers, such as youtube.com, do everything to make it difficult or impossible for you to cache content. The options above should help you to overcome some of these limitations.

Refresh patterns are matched against all requests in order from the top until there is a matching rule.

The last rule is a catch-all and will match any request that is not satisfied by any of the rules above it.

There are normally separate catch-all default rules for other protocols like FTP and gopher at the very top of the list so as to exempt those protocols from the patterns below them.

Cache Dynamic Content

By default, Squid will not cache dynamic content.

Dynamic content is determined by matching against either “cgi-bin” or “?”.

This feature used to be activated via the “hierarchy_stoplist” and “cache deny” settings in older versions of Squid.

In recent versions, starting with 3.1, this feature is activated via a refresh pattern such as refresh_pattern (/cgi-bin/|?) 0 0% 0.

This enables you to specify sites that serve dynamic content that could be made cacheable in bypass rules. For example, you could set up a refresh pattern such as:

refresh_pattern -i movies.com/.* 10080 90% 43200
refresh_pattern (/cgi-bin/|?) 0 0% 0

Then, even if content from movies.com is served with “?” in their URL, the content will still be cached if all other conditions are met.

For the older versions of Squid, you will have to define an access control list (ACL) for the content providers you wish to make exceptions for, and use cache accept to exempt it before the cache deny rule. The following example is from the Squid wiki:

# Let the client's favourite video site through
acl youtube dstdomain .youtube.com
cache allow youtube
# Now stop other dynamic stuff being cached
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin ?
cache deny QUERY