SSL mutual authentication against the pool

The issue here is that you cannot make a layer 6 (SSL) decision based on layer 7 (HTTP) information, simply because you don't have the layer 7 information until you've already made the layer 6 decision. At best you can make a decision based on layer 3 and 4 information (IPs and port) and potentially even layer 6 information (SNI).

You could simply force requests to a specific URI to redirect to another VIP that does mutual auth.

The point is, at the moment that you need to make an SSL decision, whether or not to require a client certificate, you haven't yet decrypted the application layer (HTTP), so you don't have access to the URL. iRule events work just like the OSI model. So at layer 6, you have access to all of the information available at layers 6 and below, which would include ClientHello SNI, ports, IP addresses, etc.

So you could make an SSL handshake decision based on the source or destination address, or the SNI in the client's ClientHello message. Or, you could direct all traffic to your regular VIP with the above iRule, and then redirect requests to a specific URL to another VIP that does mutual authentication.

when HTTP_REQUEST { 
    switch -glob [string tolower [HTTP::uri]] { 
        "/ABC" { 
            pool ABC 
            HTTP::uri [string range [HTTP::uri] [string first "/" [HTTP::uri] 1] end] 
        } 
        "/DEF" { 
            pool DEF 
            HTTP::uri [string range [HTTP::uri] [string first "/" [HTTP::uri] 1] end] 
        } 
        "/GHI*" { 
            HTTP::redirect "https://mutual-auth-vip.domain.com"
        }
    }
}

The idea here is that all users will initially go to your "proxy-pass" application VIP, and as soon as someone requests "/GHI*", they'd get redirected to a second VIP that performs mutual authentication. You're just adding a separate VIP and separate client SSL profile, and probably a second DNS entry to point to this separate VIP.

I did make a typo in the last code example though. I added [string tolower ] in the switch condition, but didn't make the conditions lower case. Here's a better example:

when HTTP_REQUEST { 
    switch -glob [string tolower [HTTP::uri]] { 
        "/abc" { 
            pool ABC 
            HTTP::uri [string range [HTTP::uri] [string first "/" [HTTP::uri] 1] end] 
        } 
        "/def" { 
            pool DEF 
            HTTP::uri [string range [HTTP::uri] [string first "/" [HTTP::uri] 1] end] 
        } 
        "/ghi*" { 
            HTTP::redirect "https://mutual-auth-vip.domain.com"
        }
    }
}

Right, so you're going to direct (some?) traffic to this new VIP, and then direct the rest to the other VIP? So let's say you have an application at

www.application.com    

And you're aforementioned iRule uses a proxy-pass-like iRule to direct requests to different pools based on the request URI. But then for one specific URI you need to prompt for client certificate. So when the user is navigating the first app, and makes a request to this special URI, you redirect them to a second VIP, we'll call it

www.auth.application.com    

in which case you have a separate VIP, on a separate IP, with DNS pointing this hostname to that IP address, and a (separate) certificate that matches the hostname.

That's if you want some requests to do client authentication. You'd probably have a similar iRule on the auth VIP that redirects to the first VIP if any of the other URIs are requested.