Forum Discussion

Rich_L's avatar
Rich_L
Icon for Nimbostratus rankNimbostratus
Apr 06, 2017

iRule not going to pool

I have an iRule that if the HTTP::header User-Agent contains "iPhone", and if the HTTP::URI contains "INV", then I want it to go to a specific pool. If the iPhone tries to access any other URI on that pool, it should be redirected to a different web page. The problem I am having is that if I have both of these conditions, the iPhone goes straight to the redirect page and does not go to the pool. Last week I submitted a similar request to this. Any help is appreciated very much! Here is my iRule:

when HTTP_REQUEST {
if {([HTTP::header User-Agent] contains "iPhone") or
     ([HTTP::header User-Agent] contains "iPod")} {
    if {([HTTP::uri] contains "LEAD") or
    ([HTTP::uri] contains "INV")} {
        pool vspool
    } else {
        HTTP::redirect http://www.mysite.com
    }
    } }

6 Replies

  • Rich_L's avatar
    Rich_L
    Icon for Nimbostratus rankNimbostratus

    Thank you for your quick reply, snl I included log local0. "Found uri: [HTTP::uri]" into my iRule.

     

    I'm testing the iRule from an iPhone right now and I have a different situation than what was being observed yesterday. Now when I go to the URI that contains INV, it is actually going to the pool as it should, which is good. However, the pool is a server that requires a login. Once I log in, I am now going to the redirect page set in the iRule instead of the application. Which is not correct.

     

    The log shows this activity up until I log into the pool/server. It doesn't show anything after that (i.e. me being redirected to the redirect page).

     

  • Hi, Can you try below one..

    when HTTP_REQUEST { 
        if {([HTTP::header User-Agent] contains "iPhone") or ([HTTP::header User-Agent] contains "iPod")} { 
            if { ( [string tolower [HTTP::uri]] contains "lead" ) or ( [string tolower [HTTP::uri]] contains "inv" ) } { 
                pool vspool
            } else { 
                HTTP::redirect "http://www.mysite.com"  
            } 
        } 
    
    }
    

    -Jinshu

  • try to put some logs on the Irule to see the data. May be the server is redirecting your session and not the bigip. Also If the server is asking you to login you are getting new URI. The new page may not have LEAD or INV in the URL and this will triger the redirect after you hit enter to login.

    when HTTP_REQUEST { if {([HTTP::header User-Agent] contains "iPhone") or ([HTTP::header User-Agent] contains "iPod")} { if {([HTTP::uri] contains "LEAD") or ([HTTP::uri] contains "INV")} { log local0.alert "Accessing the pool" log local0.alert "HTTP::header User-Agent= [HTTP::header User-Agent]" log local0.alert "HTTP::uri= [HTTP::uri]"

        pool vspool
    } else {
        log local0.alert "Redirection is being done by BIGIP"
        log local0.alert "HTTP::header User-Agent= [HTTP::header User-Agent]"
        log local0.alert "HTTP::uri= [HTTP::uri]"
        HTTP::redirect http://www.mysite.com
    }
    } }
    
  • Hello Rich_L,

     

    Maybe by now you have already solved the problem. But, after going through your iRule, I felt that you need to rewrite it. The reason you are being redirected to [http://www.mysite.com] is because, when you login, I guess your iRule check doesn't find "LEAD" or "INV" in your URI. As a result, it doesn't enter the IF statement and gets you to the redirection page.

     

    I will try and write the iRule for you if you provide me with the details regarding your URI.

     

    Thank you

     

  • Rich_L's avatar
    Rich_L
    Icon for Nimbostratus rankNimbostratus

    I want to thank everybody that provided suggestions on how to get this issue resolved. The issue is resolved. After enabling the detailed logging as suggested by Hectorm, I was able to see what was happening. What is happening is that there is logic on the server itself that after logging in, it then loops back. When it loops back, the header no longer contains the required URI and therefore goes to the redirect page. After putting in the logging suggested by Hectorm, we were able to see this happen and take measures to correct it.

     

    Thanks again to everybody that replied!