iRule URI Matching Not Working as expected.

We have a virtual server that has these three requirements:

1. mTLS negotiation
2. Match start of URI
3. Match CN of certificate

Note: The the virtual server where this iRule is applied does not have a pool configured as I learned that the 'reject' command doesn't necessarily do what I thought it did.

Testing has proven mTLS works and I think the CN validation does too.  The problem is with URI matching.  Using Postman, we've found that using a bogus URI fails indefinately until a valid URI is accessed by the same source.  After that, the bogus URI works too.  We just found this so haven't done extensive testing.

Below is a simplified version of the iRule and this is the sequence of events:

https://virtualserver/bogus - fails

https://virtualserver/uri-a-yaddi-yaddi - works

https://virtualserver/bogus - This works for I don't know why!!!

Note: Not sure the bogus URI has to be used first but that's what the tester reported.

when CLIENTSSL_CLIENTCERT {
		set subject_dn [X509::subject [SSL::cert 0]]
		if { $subject_dn != "" }{
		}
}

when HTTP_REQUEST {
		if { [HTTP::uri] starts_with "/uri-a" } {
				if { $subject_dn contains "mauth-a" } {
						pool serverpool-a-443
				} else {
						reject
				}
		} elseif { [HTTP::uri] starts_with "/uri-b" } {
				if { $subject_dn contains "mauth-b" } {
						pool serverpool-b-443
				} else {
						reject
				}
		}
}

The bogus URL does get rejected by the server but it should not have made it there to begin with.  I'm no expert on iRules so I thought I'd post this before searching for a solution.  If you happen to know what the problem is I'd be happy to save the time.

Also, I'm guessing there may be a better way to do this iRule but it was created by a consultant and thought to be working properly until today.

Thanks!