]] 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