mask/hide browser url header after redirect.

This get's a little trickier, but you'd generally replace an HTTP::redirect with an HTTP::uri command to transparently alter the URI path on the ingress traffic flow.

HTTP_REQUEST { 
    if { [class match [string tolower [HTTP::uri]] starts_with Mortgage_iRuler] } {
        HTTP::uri [class match -value [string tolower [HTTP::uri]] starts_with Mortgage_iRuler] 
    } 
}

So the client entering /bob would show up on the server as /mortgage/default.aspx?clientid=1021 (you may have to alter your existing data group entries to just reflect a specific URI and not the entire URL). Where it gets tricky is if 1) the URI pattern for a given user changes from that data group entry during the user's session, and 2) if the application responds with document object references (images, css, js, etc.) that use the real URI path.

ok, im still in staging/testing so id like to try your first recommendation to replace an HTTP::redirect with an HTTP::uri command. Not sure though, is that change on my current irule or a new irule? not sure what you mean. Could use more details please.

Never mind, i see where its changed. Thanks ill try it.

Tried it but doesnt seem to work at all. The page totaly errors out and gives a server error. i'v been looking at samples on dev central. What your your recomendation be? is it a problem because of the way the redirect url formated? due to auditing I have to hide the true path, or is does this have to be fixed on the server?.. Is there a way to save the url are a variable and then just replace it? Im also asking the Web Developers if about the concerns you brought up.

Again, it depends entirely on the application. If, for example, anything "sue" would want to access is under the static "/mortgage/default.aspx?clientid=1021" URI, then it should be pretty straight forward. But if the application starts referencing local URI paths that you don't want the client to see, you have to rewrite those. Those URIs may also not be in the same context of the requesting user, which may still be okay if you can apply some pattern to the external-internal translation. I hesitate to suggest a solution like ProxyPass or an 11.4+ rewrite profile, because I don't know enough about the application to justify any of these. Your best bet I think at this point is to allow the redirects as you have them applied in the current iRule, and then capture client side HTTP interaction and observe URI patterns.

Ok Thank you. This my get a little tricky, if needed we will engage professional services. Thanks for all your help Kevin, we made huge progress.