Purging on PUT and DELETE

[Martynas Jusevičius]

Thank you  Dridi.

But what I'm reading here
https://docs.varnish-software.com/tutorials/cache-invalidation/
> Unlike purges, banned content won’t immediately be evicted from cache freeing up memory, instead it will either stay in cache until its TTL expires, if we ban on req properties, or it will be evicted by a background thread, called ban_lurker, if we ban on the obj properties

Which means that using your example, if immediately follow up
PUT/DELETE with a GET, it is not certain to get a fresh copy? Because
"banned content won’t immediately be evicted from cache"?

On Thu, Mar 19, 2020 at 11:21 AM Dridi Boukelmoune <dridi at varni.sh> wrote:
>
> On Thu, Mar 19, 2020 at 10:05 AM Martynas Jusevičius
> <martynas at atomgraph.com> wrote:
> >
> > Hi,
> >
> > upon receiving a PUT or DELETE request, I'd like Varnish to invalidate
> > the current object (and its variants) *and* to pass the request to the
> > backend.
> >
> > Essentially the same question as here:
> > https://serverfault.com/questions/399814/varnish-purge-on-post-or-put
> > The answer seems outdated though.
>
> I would do it like this:
>
> > sub vcl_backend_response {
> >     if (beresp.status == 200 && bereq.method ~ "PUT|DELETE") {
> >         ban("req.url == " + bereq.url + " && req.http.host == " + bereq.http.host);
> >     }
> > }
>
> Or at least, I would do it in vcl_backend_response, there's no point
> in invalidating if the client wasn't allowed to change a resource for
> example.
>
> > I consider this a common use case for REST CRUD APIs, so I was
> > surprised not to find a single VCL example mentioning it.
>
> The problem is that so many things can go wrong. For example my
> snippet doesn't allow the ban to be processed in the background, so
> further adjustments are needed to make that happen. It also assumes
> that bereq's URL and Host are identical to req's, and isn't subject to
> client noise (spurious query parameters and whatnots).
>
> So indeed, I wouldn't want to advertise that kind of snippet without a
> heavy supply of red tape.
>
>
> Dridi