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.<div><br></div><div>
The use case was like this:</div><div>sub vcl_recv {</div><div>    # Incoming header ban-expression is a complete ban expression containing e.g. "req.url ~ \.gif"</div><div>    if (req.method == "BAN" && req.http.ban-expression) {</div>
<div>        ban(req.http.ban-expression);</div><div>    }</div><div>}</div><div><br></div><div>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.</div>
<div><br></div><div>So a work around for the above is to instead do the ban like this:</div><div>ban("" + req.http.ban-expression);</div><div>This tricks the VCL compiler into doing runtime parsing of the expression instead, but it's not pretty and intuitive.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Regards,</div><div>Martin Blix Grydeland</div><div><br>-- <br>Martin Blix Grydeland<br>Varnish Software AS<br><br>
</div>