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

[Robert Shilston]

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

> On 13 May 2011 20:11, Jonathan Matthews <contact at jpluscplusm.com> 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
>> http://example.com/api/object-1/) 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: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10.
> Indeed, it's item #325 in the table at
> http://www.varnish-cache.org/trac/wiki/HTTPFeatures.
> 
...
> 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

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.


Rob