HTCP CLR operation for purging clustered reverse proxy cache

[Simon Lyall]

On Wed, 6 Jul 2011, Ben Truitt wrote:
> Last comment on this, and then I'll leave it to you all to discuss as you see fit:
> 
> In investigating Varnish more today, I was very surprised to learn that it does not respect section 13.10 of the HTTP/1.1 RFC
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13), which states "Some HTTP methods MUST cause a cache to invalidate
> an entity. These methods are: PUT, DELETE, POST." 
> 
> I found this thread (http://www.gossamer-threads.com/lists/varnish/misc/19516), where Per Buer comments:
> "We won't do this because it would totally break if you have more then one Varnish servers. It's the backend job to notify the
> caches when the content actually changes."
> 
> I disagree. According to the spec, this is the job of the cache. The spec doesn't address a clustered cache, but I would expect
> a clustered cache to perform clustered invalidation. HTCP CLR is designed for this purpose. Therefore, to me it makes total
> sense to incorporate this into Varnish proper. 

The thing is the RFC section is really written for caches that are running 
by the client (or their network provider) not those run by the website.

The varnish cache is part of the website, it is inside the demarcation and 
from the point of view of the client is a webserver like apache. The main 
difference is that it is under the control of the website and the website 
can explicitly remove [and sometimes add] something from the cache.

The cache in the spec is run by the client and the only way the server 
admin can talk to it is via headers added to http replies.

If I send a PUT,DELETE or POST to your website do you remove entries for 
that page from your memcache, application cache and database cache?


-- 
Simon Lyall  |  Very Busy  |  Web: http://www.darkmere.gen.nz/
"To stay awake all night adds a day to your life" - Stilgar | eMT.