Redirect calls to index.php to root in Apache

Redirect all calls to index.php to the root of your domain. This can be particularly useful when considering the SEO impact of having two identical pages, and perhaps links linking to one or the other, therefore spreading the backlink benefits.

Enter the following in your htaccess file.


RewriteEngine On
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php
RewriteRule ^index\.php$ / [L,R=301]

Reporting whether Varnish delivered file from cache or not

When calling a resource from Varnish, it can be difficult to tell whether the resource was retrieved from Varnish’s cache, or whether it had to go to the source server to fetch it. In most cases we want the resource to come straight from Varnish’s cache – that’s the whole point of using it – so it’s nice to know when that happens.

Edit the config file with the following:

sub vcl_deliver {
        if (obj.hits > 0) {
                set resp.http.X-Cache = "HIT";
        } else {
                set resp.http.X-Cache = "MISS";

This code adds a new header of either HIT or MISS. The header can be viewed using Chrome developer tools within the Network tab, or via a similar tab in Firebug.

Setup a simple reverse proxy using Varnish

How to setup Varnish as a simple reverse proxy.

The first step is to define the source domain. This is where all your files are stored. Edit the config file with the following:

backend mydomain {
  .host = "";
  .port = "80";

Now we have defined the source of the data, we want to tell Varnish when to call this. For the following code to work, the domain must be setup to point to the Varnish server.

sub vcl_recv {
   if ( ~ "") {
    set = "";
    set req.backend = mydomain;

That’s how to setup a single domain. You can of course handle multiple domains by defining multiple backends, and altering the logic within vcl_recv.

Removing all cookies from a request

By default, Varnish won’t cache a page that contains cookies. It’s thinking is that a cookie suggests that the page is unique to that user, and it could cause issues if it was cached. If you cached a page unique to user X, all other users would see their content.

If we feel that we do not need the cookie (it might be used for analytics and can safely be removed) It’s possible to remove the cookie from the request, allowing Varnish to cache the content. To do this, edit the VCL file with the following:

unset req.http.cookie;

This must be placed inside sub vcl_recv. The following is a very basic example that would remove all cookies from all requests

sub vcl_recv{
unset req.http.cookie;


Rewrite folder name in URL internally using htaccess

I had images stored with a folder, which was named descriptively. Unfortunately this meant that the resulting URL was larger than it had to be. Rather than rename the directoy, and make all existing image calls invalid, I wanted to allow the folder to be called by an alias in the URL. If the URL contains /a/example.jpg, it will rewrite to the actual directory name on my server, eg /a-very-long-directory-name/example.jpg. I entered this in my htaccess file.

RewriteEngine on
RewriteRule ^a/(.*) a-very-long-directory-name/$1

How to use mod_deflate to compress files in Apache

Despite the increase in home internet speeds, the time taken to transfer a file to a browser is often the slowest link in the chain. One way to reduce that time is to compress(zip) the file before sending it. You could gzip the file, or use deflate, like I do in the example below. Both are almost the same, but many argue that deflate is faster. You do not want to compress anything that is already compressed, eg jpg,mp3,png. Nothing would crash if you tried to compress an already compressed file, but you would be wasting CPU time. You could probably add any rss feeds to the list below, but I do not know the mime type of the top of my head. In the example mod_deflate must be loaded for the files to be compressed. You can add this into your .conf file, or into a .htaccess file.

<IfModule mod_deflate.c>
# compress text, html, javascript and css files
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

Further reading is available on the apache mod_deflate page.

Cache Control using htaccess file

When a user visits a webpage, which contains an image, the browser will first check if it has the image in it’s cache. If it does, it will ask your web server if it has a newer version. If there isn’t a newer version, then the browser doesn’t download the image again, and instead displays it using its cached version. That’s very nice, because you do not have to send the image to the user again, but the web server has had to do a little work by checking the last time the file was updated. You can stop the browser asking so frequently by using a cache control header. This basically tells the browser not to ask if there is an updated version until a certain amount of time has passed. One way of setting this cache control up is using a .htaccess file. This assumes that you are using Apache.

The following example tells the browser to cache any gif, jpg, or png files for 1 month:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/gif "access plus 1 months"
ExpiresByType image/png "access plus 1 months"
ExpiresByType image/jpg "access plus 1 months"

You could extend that to cache any CSS or javascript files by adding the following:

<IfModule mod_expires.c>
ExpiresByType text/javascript "modification plus 1 months"
ExpiresByType application/javascript "modification plus 1 months"
ExpiresByType text/css "modification plus 1 months"

Alternatively, you could use the following, which caches anything with the listed extension for 1 day

<FilesMatch "\.(ico|pdf|jpg|jpeg|png|gif|js)$">
Header set Cache-Control "max-age=86400"

I personally use the final example, because it’s easier to list the file extensions, rather than listing the mimetypes.

Sender Policy Framework (SPF)

Sender Policy Framework is used by email vendors (hotmail, gmail etc) to try and spot spam. Basically it is a DNS record that lists the servers that can send mail for that particular domain.

I cannot confess to knowing everything there is to know about SPF records, but here is an example TXT that says you can send emails from the IP specified. You can include multiple IPs.

"v=spf1 ip4: -all"

This example says you can send email from Again, you can include multiple domains.

"v=spf1 -all"

As I say, I am not expert, but this should get you started.