Weird situation with unexpected 206 from the backend, hit-for-pass and default_ttl

Thomas Parmelan tom+varnish at
Mon Mar 1 12:58:52 CET 2010

Le lundi 01 mars 2010 à 10:32, d'après
Tollef Fog Heen <tfheen at> :

> We generally try to avoid guessing in the C code, so I think this should
> be left for VCL.

I tried the "unexpected 206" with -trunk (r4596), and it acts just as I
wanted! So I guess this was already fixed in the C code. Or maybe just a
side effect of some other fixes?

> What happens if you set obj.cacheable to true and ttl to 1s if the
> response is a 206?  Does that work?

I will give it a try with 2.0.6 and report the result.

However, the VCL trick that didn't work for me is supposed to work
according to the FAQ:

Also, I found some more interestings things about the hit-for-pass TTL,
be it in 2.0.6 or in -trunk, it appears from my various tests that it is
computed as the maximum between default_ttl and the "RFC" TTL from the
obj/beresp headers. My default_ttl was 86400...

Is this a known feature? I didn't see any explanation about this on the

> |   - I also tried to purge the hit-for-pass culprit with the CLI (purge
> | == && req.url == /the/url), but it didn't work
> |     (the object was still there after). Any idea how to purge such
> |     objects ? Is this a bug ? 
> According to phk on IRC, this should work and it not working is a bug.

I'm confused about this one, as it definitely worked for me on a new
test yesterday. I think we can put this one on human error on my part
for the moment (and I will probably do some more tests just to be sure).
Or maybe it as something to do with default_ttl (since I put it back to
its 120s default value before doing the test that worked)?

> If you have a chance to reproduce this in a test environment with both
> 2.0.6 and trunk, that'd be appreciated.

Yes, I now have a test environment where I can reproduce all this
(that's how I noticed that -trunk behaves better). Will do the
purge/default_ttl test again. If you want another specific test, just

Thomas Parmelan  -+-  Thomas.Parmelan at  -+-  tom at

More information about the varnish-misc mailing list