Forum Discussion
hooleylist
Jul 07, 2009Cirrostratus
That's odd... regexp handles this correctly in an iRule:
when RULE_INIT {
log local0. "\[regexp -inline -all {top\.(?!jpg)} top.test\]: [regexp -inline -all {top\.(?!jpg)} top.test]"
log local0. "\[regexp -inline -all {top\.(?!jpg)} top.jpg\]: [regexp -inline -all {top\.(?!jpg)} top.jpg]"
}
Rule : [regexp -inline -all {top.(?!jpg)} top.test]: top.
Rule : [regexp -inline -all {top.(?!jpg)} top.jpg]:
This might be a bug in the stream filter's handling of the regex. It looks like something is trying to optimize the code by adding a colon. This colon would normally stop the regex engine from saving the matched value into a backreference. In this case though, it's a lookbehind and the ?: breaks the matching:
when RULE_INIT {
log local0. "\[regexp -inline -all {(top\.(?:?!jpg))} top.jpg\]: [regexp -inline -all {(top\.(?:?!jpg))} top.jpg]"
}
01220001:3: TCL error: couldn't compile regular expression pattern: quantifier operand invalid while executing "regexp -inline -all {(top\.(?:?!jpg))} top.jpg"
I'd suggest opening a case with F5 Support on this.
As a workaround, you could replace the regex with
top\.
and then check the STREAM::match output to see if it doesn't end in jpg before performing the replacement.
Aaron