[PATCH] stale-while-revalidate updated

[Federico Schwindt]

I don't think we have a way to express this in any sensible way in VCL at
the moment and I'd argue that it'd be weird to only cover grace and not
other variables.

Personally I don't want the default/builtin VCL to grow unbounded.
Processing in C while allowing to tweak things afterwards in VCL is a good
combination.
This is the scenario I imagine for s-w-r. This is used as the default
value, much like default_grace is used, while you can still change it in
VCL if you want.

If the consensus is to handle this in VCL that's fine but we need some
primitives to do so. A regex spaghetti will make things harder.

So which one should we aim for?


On Wed, Aug 27, 2014 at 10:34 PM, Geoff Simmons <geoff at uplex.de> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 8/27/14 7:11 PM, Federico Schwindt wrote:
> >
> > Attached is an updated patch for s-w-r support that I originally
> > sent in June 23.
> >
> > Before this turns into another bike-shedding, a few things worth
> > clarifying:
> [...]
>
> This might be a bit of bike-shedding, and I know that there's been
> some discussion going that I haven't kept up with. So apologies in
> advance.
>
> I think I'm unsure about what we're striving for in Varnish 4 --
> wasn't the goal to move as much caching policy as possible out to VCL,
> with good defaults in builtin.vcl? The patch implements a solution for
> s-w-r in the binary, by magic as it were, but it seems to me that it
> could be done in VCL.
>
> My stab at a VCL solution does turn out to be cumbersome (just typing
> the idea here, haven't tested it).
>
> if (beresp.http.Cache-Control ~ "stale-while-revalidate\s*=\s*\d+") {
>     set beresp.grace
>         = std.duration(regsub(beresp.http.Cache-Control,
>                              "^.*stale-while-revalidate\s*=\s*(\d+).*$",
>                              "\1s"), 120s);
> }
>
> That is admittedly pretty ugly. (We really need to get that VMOD for
> easier backref capture upgraded for Varnish 4, then it would be much
> simpler.)
>
> Is the verbosity of a VCL solution the reason for wanting varnishd to
> take care of s-w-r?
>
> I'm hesitating here because s-w-r would give application developers a
> way to set grace. It can be hard enough to get them to understand how
> to set TTL (and do it well), and grace needs even more explanation.
> But grace can be critical for getting Varnish to run smoothly and
> perform well. App developers might get the idea of setting grace to 0,
> but as an admin in charge of Varnish and the owner of VCL, I think I'd
> prevent them from doing so. That thought tends to persuade me of the
> wisdom of implementing as much caching policy in VCL as we can,
> especially where grace is concerned.
>
>
> Best,
> Geoff
> - --
> UPLEX Systemoptimierung
> Scheffelstraße 32
> 22301 Hamburg
> http://uplex.de/
> Mob: +49-176-63690917
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
>
> iQIcBAEBCAAGBQJT/k7kAAoJEOUwvh9pJNURyScP/R6r2kKnfeRaNVzf6+QiC7sO
> ics/lOCPVCTuNeVyjfSPFiW6G+rvGa7KkltIit1sooh1Qo5lNMPqguh5McnUzrvU
> mPEpjPleO8dNuPN6yu5ybimJpLgWSLAP4VJxruCytrqld0pAV/ItuHhWb/0LiUGs
> McqlV17zvDourZ4ltsPhdFZM7UTJWOwvUNi9VUFmDqWXYAN2CZT+srOVKiiElYvw
> v106uu2bpdCK8D/6yh1zZThqH2QvIHSmIP39FdJZFagjuGKPIviWe3JP2E/IoKJ0
> S9dAWBjP18ObLezesk+X55HVcelmAn9Uu8LG5plOLhVtdD8L81LCrR8h97xZQ5NE
> GqM+0sGjbQtTd/YTncR4NnXfjAfjKK/Fpb5pL747PWpzY6IilK9kNuJA7eIvzx3l
> alv/znK2DY7CSjOjcJPxwu2kSUaNpxo0DxsvjaGY5VV50eSIJ0pJyV0KihJgc+DN
> m4uwnw6C4QlQsOrfW9Fd/uxk1vYuxPTGt3fZ3RK5VVtS0FwO2FftZImmeaYPH//H
> 1F9poE2lweAqmbqsg4zSI8EOb5NRNAI4bSofxSaaRuKp0d8gso1yI6oHgRvFuPrn
> M4baOg0ht7CaKWMrSD8CZcVFBHDY7Fr+bFNZnZmthhWpkKvD8/L25elhEkYpfhkb
> esjSSXQBNRg1Y8/LID8p
> =i60z
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20140828/87251f23/attachment-0001.html>