Mailing List Archive

--------
Guillaume Quintard writes:

> With 6.6, VFP_Push was made private, but it looks like there's no
> alternative for it. I've seen VCL_StackVFP, but it's equally private.

The alternative is to edit the filter_list variable.

The problem with VFP_Push() is that you cannot control the order in
any usable way, whereas editing the filter_list gives you full control.

At least that's the theory why we did it :-)

If it doesn't work in practice we will have to do something about it...

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

On 25.04.22 11:12, Poul-Henning Kamp wrote:
> If it doesn't work in practice we will have to do something about it...
>
FWIW, we also need to push filters in pesi[1] very similar to how core ESI code
does.

As pesi is so tightly coupled to core code, and, consequently is a "VARNISHSRC"
vmod, that I do not care about API boundaries, but the use case might be more
general:

A filter might determine that it needs/wants to push more filters after
processing of the filter list is finished, if only for modularity.

How relevant this use case is for vmods which could otherwise limit themselves
to just VRT I do not know.

Nils

[1] https://code.uplex.de/uplex-varnish/libvdp-pesi

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

Thank you for both of your answers!

On 25.04.22 11:12, Poul-Henning Kamp wrote:
> The problem with VFP_Push() is that you cannot control the order in
> any usable way, whereas editing the filter_list gives you full control.

The theoretical issue I have with this is that to use filter_list, I need
to register the filter, which opens it to be used by VCL writers, even
though the vmod should be the only one fiddling with it (notably because it
must be the first in line, and only after some internal setup happened).

On Mon, Apr 25, 2022 at 3:03 AM Nils Goroll <slink@schokola.de> wrote:
> As pesi is so tightly coupled to core code, and, consequently is a
"VARNISHSRC"
> vmod, that I do not care about API boundaries,

That's convenient :-) I'm probably going to do the same. The slight
annoyance in my case is that I have to decide whether to expose VFP_Push
(and possibly others) in the rust bindings (breaking the API barrier way
upstream), or if I just let vmods declare the bindings themselves
downstream.
At the moment I don't care because I own the bindings and all the rust
vmods I know of, but it may change at some point (and we can wait until
them until exploring this again).

--
Guillaume Quintard