default hit_for_pass usage

Rogier R. Mulhuijzen varnish at
Tue Aug 23 14:50:51 CEST 2011

What we object to specifically was that hit_for_pass is returned when 
(beresp.ttl <= 0). Which is true not just for things like 401, but also 
500 and 503. My primary objection is the 503.

Like Andreas says, it possible to get a 500 or 503 on a page either due to 
load or some temporary error, where the next request could result in a 
perfectly cacheable page. But with the hit_for_pass in place, all workers 
blocking on that URL before then will just go through to the backend 
en-masse for the next two minutes. Especially with a 503, which most 
probably means the backend isn't coping very well due to load, and I'd 
hate to see an error like that cause even more load on a backend.

I think the default.vcl should be more conservative, and looking at all 
the status codes other than the ones deemed cacheable by default, I can 
only think of 401 and 403 as needing a hit_for_pass.



On Tue, 23 Aug 2011, Andreas Plesner Jacobsen wrote:

> I was just going through the docs, updating examples to 3.0 syntax.
> I fell over something that bothered me:
> Has a section on increasing hit_for_pass ttl. I discussed rewriting this
> section with DocWilco on irc, and we came to the conclusion that the current
> default vcl may not be completely sane. For example, it looks like a 500 will
> cause varnish to hit_for_pass for the next two minutes, even though the next
> request could result in a nice cacheable 200.
> Any ideas? Was this already considered when writing the default?
> -- 
> Andreas
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at

More information about the varnish-dev mailing list