In message <[email protected]>, Martin Blix Gr
ydeland writes:
>This will produce a compiler error of missing expected operator, as the
>compiler recognizes the req.http.ban-expression as a variable and goes into
>the mode of recognizing ban-expressions (reads 3 arguments, first a
>variable, 2nd an operator and third a stringval, possibly followed by && and
>other triplets). If the first argument isn't a variable, it will feed a
>string to VRT_ban_string instead for parsing at runtime.
I'm not happy with the way this entire thing turned out. It looked
quite sensible when I started out and then it got ugly on contact
with the reality.
I'm sort of hessitant to mandate the one-string format, because it
will force some people to collect into one string, components which
the BAN code will immediately split back into those components.
One possible, but ugly-ish solution, is to make the VCL::ban function
var-args, and let the number of args steer the interpretation:
ban(req.http.ban-expression);
ban(req.http.foo, '==', req.http.ban-detail);
Not sure how much work that is to implement, if it is 3.0 material
or even a good idea.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[email protected] | 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
[email protected]
http://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
