Mailing List Archive

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

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@varni.sh> wrote:
>
> On Thu, Mar 19, 2020 at 10:05 AM Martynas Jusevi?ius
> <martynas@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
_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

On Thu, Mar 19, 2020 at 10:28 AM Martynas Jusevi?ius
<martynas@atomgraph.com> wrote:
>
> 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"?

That's because bans using req criteria (as opposed to obj) need a
request to happen to test the ban on a given object. And even bans
with obj criteria don't happen immediately, they eventually happen in
the background.

But once a ban is in the list, an object is not served from cache
before confirming that it isn't invalidated by a newer ban during
lookup, so you shouldn't worry about that.

Dridi
_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc