Thinking about 4.1 softban/purges (yes, already...)

Martin Blix Grydeland martin at
Wed May 7 16:56:41 CEST 2014

I think this sounds great!. As this change became a blocker for my current
project, I ended up implementing the change. Patch sent to the -dev list.

In my patch I didn't implement any additional oc->method() for the exp
changes, AFAICS the existing updatemeta() function suffices.


On 6 May 2014 23:45, Poul-Henning Kamp <phk at> wrote:

> I'm starting to think about 4.1 and one of the first things that
> pop up is the "softbans" and the purge ticket in #1139
> I also noticed that we forgot to move the "purge" direct
> action (ie: from vcl_hit{}) in 4.0 to VMOD.std.
> Today a ban basically expires anything which it hits, but in
> general that doesn't have to be the case, the ban mechanism
> could be used to do any useful thing to the set of matching
> objects, for instance extend the grace period by 10 minutes.
> That's basically what "softbans" covers, the abilit to do something
> like:
>         ban -grace +10m req.url ~ [.]jpeg$
> There are outstanding design issues with respect to specifying
> the arguments, because of the "delayed action", those need to
> be sorted out.
> I want to do something similar for purge.
> If you return(purge) from vcl_recv{}, the stuff's going to be
> gone.
> But I want to add a std.purge(ttl, grace, keep) where you can
> modify all three as you like.
> Both of these pressume that you can modify ttl/grace/keep on
> an object and let it survive, and that's somewhat contrary
> to our pre-4 decision to make objects read-only.
> That decision in turn changes the previous calculus on where the
> ttl|grace|keep timers live and I think they should move from obj
> to objcore in 4.1.
> That increases the size of objcore by 24 bytes or so, and since
> it is magically 128 bytes right now I'm not happy about that,
> but I think it will be worth the cost.
> It also means adding a oc->method() so we can tell -spersistent
> that we muked about with exp.*.
> Comments ?
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at

<>*Martin Blix Grydeland*
Senior Developer | Varnish Software AS
Cell: +47 21 98 92 60
We Make Websites Fly!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the varnish-dev mailing list