Le lundi 01 mars 2010 à 10:32, d'après Tollef Fog Heen <[email protected]> :
> 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: http://varnish-cache.org/wiki/FAQ#WhyamIgettingacachehitbutarequestisstillgoingtomybackend 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 Wiki. > | - I also tried to purge the hit-for-pass culprit with the CLI (purge > | req.host == the.host && 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 ask. -- Thomas Parmelan -+- [email protected] -+- [email protected] _______________________________________________ varnish-misc mailing list [email protected] http://projects.linpro.no/mailman/listinfo/varnish-misc
