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

[Tollef Fog Heen]

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