Re: Weird situation with unexpected 206 from the backend, hit-for-pass and default_ttl
Le lundi 01 mars 2010 à 12:58, d'après Thomas Parmelan : > > 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. Nope, doesn't change a thing. > Will do the purge/default_ttl test again. Ok I found the explanation for this one: my purge command was "purge req.http.host == img.s-sfr.fr && req.url == /foo/bar", but in vcl_recv I change req.http.host to rewrite Host so that the backend recognize it. If I do the purge with the "corrected" req.http.host, the hit-for-pass is purged as expected. (this test was on 2.0.6, if it matters). -- Thomas Parmelan -+- thomas.parme...@free.fr -+- t...@ankh.fr.eu.org ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Weird situation with unexpected 206 from the backend, hit-for-pass and default_ttl
Le lundi 01 mars 2010 à 10:32, d'après Tollef Fog Heen : > 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 -+- thomas.parme...@free.fr -+- t...@ankh.fr.eu.org ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Weird situation with unexpected 206 from the backend, hit-for-pass and default_ttl
]] Thomas Parmelan
| - seeing as wrong as this backend answer is, I think it shouldn't be
| dealt with "normally" by varnish, it would me more interesting to
| let the next request have its chance to populate the cache with a
| valid (200) answer, in order to keep the following requests being
| able to be served from the cache. Is this something that should be
| changed in varnish, or in the vcl (and how) ?
We generally try to avoid guessing in the C code, so I think this should
be left for VCL.
| - the TTL used for the HitPass object seems to be the default_ttl (-t
| 86400 in my setup); I tried to keep it low (0s or 10s) from the vcl
| config, like this :
|
| sub vcl_fetch {
| if (!obj.cacheable) {
| set obj.ttl = 0s;
| return (pass);
| }
| /* ... */
| }
What happens if you set obj.cacheable to true and ttl to 1s if the
response is a 206? Does that work?
| - 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.
If you have a chance to reproduce this in a test environment with both
2.0.6 and trunk, that'd be appreciated.
--
Tollef Fog Heen
Redpill Linpro -- Changing the game!
t: +47 21 54 41 73
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
