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 <[email protected]> wrote: > > On Thu, Mar 19, 2020 at 10:05 AM Martynas Jusevičius > <[email protected]> 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 _______________________________________________ varnish-misc mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
