PATCH: stale-while-revalidate support

[Federico Schwindt]

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 <perbu at varnish-software.com>
wrote:

>
>
>
> On Mon, Jun 23, 2014 at 11:44 AM, Federico Schwindt <fgsch at lodoss.net>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20140623/ec792932/attachment.html>