Varnish poisoned cache avoidance
kb+varnish at slide.com
Sun Jan 10 04:27:43 CET 2010
Have the application emit a cache pragma or expires to make the BANNED page non-cacheable. Alternatively, you could have the app emit an Expires header to cause the browser to cache the result, but also add a header that would trigger Varnish to /not/ cache it.
Looking at your previous posts, make sure you don't try to pull app logic up into caches, firewalls, or load balancers -- it will hurt you later, IMHO. The application is the definitive source of cacheability. Varnish/etc offer tools to tweak this, but the logic really belongs in the app and widely supported cache headers.
As an alternate IP blocking implementation, you could create a list of banned IPs in a file that your VCL includes; a Varnish reload causes essentially no outage. But then you're adding an extra linear lookup for /every/ hit to Varnish.
On Jan 9, 2010, at 10:59 AM, pub crawler wrote:
> We have some ban / block logic in our application server behind
> Varnish. For instance, when we have a comment spammer or other
> repetitive troublemaker messing with our applications we ban their IP
> in our application server.
> A person or bot returning after being blocked will still reach our app
> server, but it just returns a page that says BANNED.
> We had such a banned IP request a page and subsequently I requested
> the same page and was given the BANNED message as it was sitting in
> Varnish cache - even though my IP is not banned.
> My question here is how best to prevent this and what sort of
> workaround other folks have for this?
> I've considered banning at our firewall level, but it's too time
> consuming to do so and the block lists are so long that it really
> causes the firewall to take forever to restart from cold reboot.
> Originally I had blocked at the firewall, so I've been down that road.
> Any input would be greatly appreciated...
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
More information about the varnish-misc