I didn't add stale-while-error support on purpose. The RFC states this should be served after we got an error from the backend, not before, so I don't believe this fits into grace per se. YMMV.
On Mon, Jun 23, 2014 at 11:12 AM, Per Buer <[email protected]> wrote: > > > > On Mon, Jun 23, 2014 at 11:44 AM, Federico Schwindt <[email protected]> > wrote: > >> Hi, >> >> After Per's recent post (1) and discussing it with him here's a patch >> that uses this to initialize beresp.grace. >> I've reused cache_rfc2616.c but perhaps this should be moved into its own >> file, i.e. cache_rfc5861.c. >> Comments? >> >> > RFC5861 ads two subheaders to Cache-control, stale-while-revalidate and > stale-while-error. I think it makes sense to parse these in Varnish because > it is much more convenient to have the backend issue the policy on each > response, instead of having lots and lots of VCL. > > The semantics would be to parse both stale-while-revalidate and > stale-while-error, set beresp.grace to the biggest. > > The problematic part is delivery, where one would have to have a bit more > logic in vcl_hit. So vcl_hit would maybe look something like this: > > if (std.healthy(req.backend_hint)) { > # backend healthy. > if (obj.ttl + obj.cachecontrol.stale-while-revalidate > 0s) { > return(deliver); > } else { > return(fetch); > } > } else { > # backend is not healthy, do stale-while-error > if (obj.ttl + obj.cachecontrol.stale-while-error > 0s) { > return(deliver); > } else { > return(fetch); > } > } > > One of the problems here is that the logic relies on a probe being active > on the backend. In my experience the added complexity is worth it, a lot of > the "low end" users out there have mental barriers writing VCL but have no > problems adding a header or two to their PHP application. The > stale-while-revalidate functionality has been in Squid for quite some time > and I believe there is support for ATS as well. Nginx or Apache mod_proxy > does not seem to have any support for this, but those aren't very ambitious > proxies, imho. > > > > > -- > <http://www.varnish-software.com/> *Per Buer* > CTO | Varnish Software > >
_______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
