Cross-verb cache invalidation (POST/PUT invalidates GET)

Robert Shilston rtshilston at
Mon May 16 09:31:26 CEST 2011

On 15 May 2011, at 22:37, Jonathan Matthews wrote:

> On 13 May 2011 20:11, Jonathan Matthews <contact at> wrote:
>> How can I (and *should* I?) instruct Varnish to obey the TTL that the
>> backed sets for content received by GETting a specific URI (say
>> but to invalidate that content when
>> a PUT/POST to the same URI is observed?
>> I've not started poking at it through Varnish yet and, given the
>> definition of the HTTP verbs in the RFCs, I kind of hope it might Just
>> Work
> OK, having read the RFCs a bit more I note that this behaviour is
> mandated:
> Indeed, it's item #325 in the table at
> So, coming back to the initial naive implementation, it looks like it
> could be correct. But what have I missed? There's got to be some
> complication to explain why this (or something like it) isn't in the
> default VCL - was a decision taken not to adhere to section 13.10 of
> RFC2616 at some point in the past?
> Jonathan


As a person using managing Varnish config, I'd suggest that the answer might simply be that Varnish isn't really an HTTP proxy/cache, but an accelerator.  You can't (sensibly) use Varnish as a naive HTTP cache, but instead tune it to the exact needs and behaviour of the application sitting behind Varnish.  So, whilst the RFC describes fail-safe behaviour if you're using a backend whose behaviour is unknown to the cache, I don't think it's fair to compare this to Varnish, which is typically closely coupled with the backend.


More information about the varnish-misc mailing list