Search

Forcing a miss

Forcing a miss

All of the previous cache invalidation examples resulted in objects being removed from cache without fetching the updated version of the object.

The burden is always on the next visitor to trigger the revalidation process. The blow is softened when soft purges are used because grace mode might still trigger a background fetch while stale content is temporarily served.

The downside of soft purges is that the outdated content is still around for the duration of the revalidation.

All these mechanisms are designed to delete content rather than refresh content.

However, there is a VCL variable available from the client subroutines called req.hash_always_miss. By default its value is false. But when you set it to true, a cache hit will be treated as a cache miss, and the content will get refreshed. The old version of the object will remain in cache until it expires or is evicted by other invalidation strategies.

We could trigger such a refresh using a custom REFRESH HTTP method. We could also borrow the ACL check from the purge example.

We could end up with the following code:

vcl 4.1;

backend default {
	.host = "localhost";
	.port = "8080";
}

acl purge {
	"localhost";
	"192.168.55.0"/24;
}

sub vcl_recv {
	if (req.method == "REFRESH") {
		if (!client.ip ~ purge) {
			return(synth(405));
		}
		set req.hash_always_miss = true;
		set req.method = "GET";
	}
}

This refresh mechanism will be triggered using the following HTTP request:

REFRESH / HTTP/1.1
Host: example.com

The output would not be a synthetic message, but the actual content of the new object.

In terms of integration, you could combine the hit always miss logic, with bans, or purges.


®Varnish Software, Wallingatan 12, 111 60 Stockholm, Organization nr. 556805-6203