Forum Discussion
Cirrusirule behaviour different after upgrade
Hi,
Hope that somebody can help me with the following:
In release 13.1.1.2 we had the following part of an irule:
set uri [HTTP::uri]
($dg is the data group name constructed of some variables, which contains allowed uri)
if {[class match $uri starts_with $dg] }
{
if { $static::otudebug }{ log local0. "DataGroup $dg URI Match, [IP::client_addr]" }
}
else {
.......
But after the upgrade to 14.1.2.2 the uri didn't match any more.
Even when changing the uri allowed in the datagroup to "/". Which would basically means that all is allowed.
But this still didn't match ????
by changing the irul to :
if {[class match $uri contains $dg] }
This made the whole script working again (also with the original uri..)
Am i missing something or is this a bug in the v14 release?
4 Replies
Ed_MartensAfter debugging and keeping my head clear.
When logging the URI which has been send
set uri [HTTP::uri]
if { $static::debug }{ log local0. "DataGroup $dg URI Match, [IP::client_addr], RECEIVED URI: $uri"
It showed the following:
Jan 22 08:19:33 xxxxinfo tmm3[14209]: Rule /parte/irule <CLIENTSSL_CLIENTCERT>: DataGroup t-DG_www.womewhat.org URI Match, 192.168.10.5%2, RECEIVED URI: https://our.site.nl/abc/123456789/def/
So uri isn't uri anymore but just the whole HTTP request.
F5 says different: https://clouddocs.f5.com/api/irules/HTTP__uri.html
- jaikumar_f5
Noctilucent
I remember seeing an equals bug btw... but starts_with is something new... Interesting.
Bookmarking this to see future answers.
BTW were you able to generate a qkview and upload on the ihealth to see the bugs & fixes.
- Ed_Martens
Yes, I did use the ihealth.
But sadly 0 bugs .
- jaikumar_f5
You can open a F5 case and confirm this. Unfortunately I dont have this version to test and confirm it.
F5 support engineer can spin up one and have this tested and resolve your issue.
