But wouldn't you want to know what the backend thinks before you return stale?
IE, would return stale make more sense in fetch or error? ------Original Message------ From: Poul-Henning Kamp To: Artur Bergman Cc: [email protected] Subject: Re: V4 VCL roadmappery... Sent: Apr 7, 2013 13:43 > If you get a 304 from origin on a IMS to origin? Where would you end up. The bits on this diagram is all on the "client-side" of things. The places where you see "fetch" we will (mostly) fork another thread to do the actual fetching. (exception: pass ?) If we have an expired obj ("exp_obj"), we'll pass that to the thread, that will enable it to do conditional fetch (will do by default) and if we get 304 back well stitch the exp_obj's body into the new object. > And why would you want to return stale from lookup? (I feel like I am > missing part of the puzzle) That's basically what "grace" does today, only now we expose that decision in VCL. The default.vcl will look something like: sub vcl_lookup { if (obj.uncacheable) { return (pass); } if (obj.ttl >= 0s) { return (deliver); } if (obj.ttl + obj.grace > 0s) { return (stale); } return (fetch); } (input very welcome!) > And is exp-obj the stale object? Yes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. Sent via BlackBerry by AT&T _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
