When changing purge->ban in 3.0, should we also expose the VRT_ban_string functionality from VCL instead of relying on magic parsing the difference

[Martin Blix Grydeland]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20110428/8be46aac/attachment-0003.html>