I noticed while working on a case that when implementing general ban
expressions through VCL you have to trick the VCL compiler into accepting to
read the whole ban expression through a header variable.
The use case was like this:
sub vcl_recv {
# Incoming header ban-expression is a complete ban expression containing
e.g. "req.url ~ \.gif"
if (req.method == "BAN" && req.http.ban-expression) {
ban(req.http.ban-expression);
}
}
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.
So a work around for the above is to instead do the ban like this:
ban("" + req.http.ban-expression);
This tricks the VCL compiler into doing runtime parsing of the expression
instead, but it's not pretty and intuitive.
So I was wondering if we now that we make changes to the purge->ban naming
for 3.0, should also do away with the automagic context guessing. I suggest
adding a ban_string() function that always does the expression parsing at
runtime, and make the ban() function always do the expression parsing at
compile time.
Regards,
Martin Blix Grydeland
--
Martin Blix Grydeland
Varnish Software AS
_______________________________________________
varnish-dev mailing list
[email protected]
http://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
