In message <87liyte4a5@qurzaw.varnish-software.com>, Tollef Fog Heen writes
:
>looks a whole lot more sane than:
>
>ban("req.url == req.url");
It would be:
ban(req.url, '==', req.url)
Or possibly even
ban("req.url", '==', req.url)
>Or are you worried about the case of req
]] "Poul-Henning Kamp"
| In message <8762pxfyhi@qurzaw.varnish-software.com>, Tollef Fog Heen
writes
| :
| >| 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 b
In message <8762pxfyhi@qurzaw.varnish-software.com>, Tollef Fog Heen writes
:
>| 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.
>
>Apart
]] "Poul-Henning Kamp"
| 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.
Apart from the slight silliness and inelegance of this, does it caus
In message , 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 thir
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 b
