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