For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Joe_Pipitone's avatar
Joe_Pipitone
Icon for Nimbostratus rankNimbostratus
Apr 07, 2010

Combining various iRules

I have an interesting issue - I saw in the F5 traffic logs that an iRule was triggering an error - and I believe the problem is because I have 5 iRules applied to a virtual server, all of which do different things - the one thing they all have in common is their HTTP::redirect. From what I've read on the forums, having multiple instances of HTTP::redirect will trigger the error. The error is: 
TCL error: my-rewrite HTTP_REQUEST - Operation not supported. Multiple redirect/respond invocations not allowed line 2 invoked from within HTTP::redirect http://oursite.com[HTTP::uri] default arm line 1 invoked from within switch -glob [HTTP::host] { / { HTTP::redirect http://oursite.com } default { HTTP::redirect http://oursite.com[HTTP::uri]...
I've tried my hardest to combine multiple iRules which mostly consist inside of a switch statement. Here's the current iRule: 
when HTTP_REQUEST {  
    switch [string tolower [HTTP::uri]] {  
      "/login/default-login.aspx" {  
        HTTP::redirect "https://oursite.com[HTTP::uri]"  
      } 
      "/forms/buy.aspx" {  
        HTTP::redirect "https://oursite.com[HTTP::uri]"  
      }
     "/forms/changeform.aspx" {  
        HTTP::redirect "https://oursite.com[HTTP::uri]"  
      } 
     "/forms/registrationform.aspx" {  
        HTTP::redirect "https://oursite.com[HTTP::uri]"  
      }
     "/forms/changepassword.aspx" {  
        HTTP::redirect "https://oursite.com[HTTP::uri]"  
      } 
     "/forms/renewform.aspx" {  
        HTTP::redirect "https://oursite.com[HTTP::uri]"  
      } 
     "/redirects/marketing/campaignstart.aspx?campaignid=2493" {  
        HTTP::redirect "http://subdomain.oursite.com/events/las-vegas-world-conference-2010/home.aspx"  
      } 
     "/redirects/marketing/campaignstart.aspx?campaignid=2494" {  
        HTTP::redirect "http://subdomain.oursite.com/events/las-vegas-world-conference-2010/home.aspx"  
      } 
     "/redirects/marketing/campaignstart.aspx?campaignid=2495" {  
        HTTP::redirect "http://subdomain.oursite.com/events/las-vegas-world-conference-2010/home.aspx"  
      }
     "/redirects/marketing/campaignstart.aspx?campaignid=2496" {  
        HTTP::redirect "http://subdomain.oursite.com/events/las-vegas-world-conference-2010/home.aspx"  
      } 
     "/redirects/marketing/campaignstart.aspx?campaignid=2497" {  
        HTTP::redirect "http://subdomain.oursite.com/events/las-vegas-world-conference-2010/home.aspx"  
      }
      "/redirects/marketing/campaignstart.aspx?campaignid=2498" {  
        HTTP::redirect "http://subdomain.oursite.com/events/las-vegas-world-conference-2010/home.aspx"  
      }
      "/redirects/marketing/campaignstart.aspx?campaignid=2499" {  
        HTTP::redirect "http://subdomain.oursite.com/events/las-vegas-world-conference-2010/home.aspx"  
      }
      "/redirects/marketing/campaignstart.aspx?campaignid=2500" {  
        HTTP::redirect "http://subdomain.oursite.com/events/las-vegas-world-conference-2010/home.aspx"  
      }
      "/redirects/marketing/campaignstart.aspx?campaignid=2501" {  
        HTTP::redirect "http://subdomain.oursite.com/events/las-vegas-world-conference-2010/home.aspx"  
      }
      "/redirects/marketing/campaignstart.aspx?campaignid=2502" {  
        HTTP::redirect "http://subdomain.oursite.com/events/las-vegas-world-conference-2010/home.aspx"  
      }
      "/redirects/marketing/campaignstart.aspx?campaignid=2503" {  
        HTTP::redirect "http://subdomain.oursite.com/events/las-vegas-world-conference-2010/home.aspx"  
      }
 "/redirects/marketing/campaignstart.aspx?campaignid=2504" {  
        HTTP::redirect "http://subdomain.oursite.com/events/las-vegas-world-conference-2010/home.aspx"  
      }
 "/redirects/marketing/campaignfinish.aspx?campaigngroupid=17" {  
        HTTP::redirect "http://subdomain.oursite.com/events/las-vegas-world-conference-2010/home.aspx"  
      }  
     }
    }
What I am having trouble with is incorporating the following iRules into the master iRule: 

switch [string tolower [HTTP::path]] {  
      "/info.aspx" {  
        HTTP::redirect "http://info.anothersite.com/default.aspx?[HTTP::query]"  
      }
And 

      if {[HTTP::uri] starts_with "/admin" } {
        HTTP::redirect "http://legacy.oursite.com[HTTP::uri]"
      }
Can anyone help?
application delivery
dev
devops
iRules

6 Replies

  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Apr 07, 2010
    A couple of suggestions...

     

     

    1. Instead of using a huge switch statement, I think I'd use a Data Group and lookup the URL's in it (No wildcards in the examples above, so that;ll work fine). It'll scale better that way. And be way more readable

     

    2. I had the same problem. From memory (Sorry, in transition between jobs ATM) the solution was to disable event processing for the connection after the first redirect, and close the connection.

     

     

    H
  • Joe_Pipitone's avatar
    Joe_Pipitone
    Icon for Nimbostratus rankNimbostratus
    Apr 07, 2010
    I appreciate your response.

    I've figured out how to do this, however now I'm having trouble combining two switch statements into one - can anyone help with this syntax? If I don't have the HTTP::path in there, the iRule won't pass the search string, for example info.aspx?id=1 

     when HTTP_REQUEST {
    switch [string tolower [HTTP::path]] {  
      "/info.aspx" {  
        HTTP::redirect "http://subdomain.oursite.com/default.aspx?[HTTP::query]"  
      }
    switch [string tolower [HTTP::uri]] {  
      "/login/default-login.aspx" {  
        HTTP::redirect "https://oursite.com[HTTP::uri]"  
      } 
      "/forms/buy.aspx" {  
        HTTP::redirect "https://oursite.com[HTTP::uri]"  
      }
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Apr 08, 2010
    Maybe this? 

    
when HTTP_REQUEST {
   switch [string tolower [HTTP::path]] {
      "/info.aspx" {
         HTTP::redirect "http://subdomain.oursite.com/default.aspx?[http::query]"
      }
      "/login/default-login.aspx" {
         HTTP::redirect "https://oursite.com[HTTP::uri]"
      }
      "/forms/buy.aspx" {
         HTTP::redirect "https://oursite.com[HTTP::uri]"
      }
   }
}

    I think it's better to try to combine all of the iRules which could send a redirect into one as this forces you to consider each piece of logic together. Disabling the HTTP_REQUEST event can be problematic if the client could make multiple HTTP requests over the same TCP connection. If they do, and you disable the HTTP_REQUEST event, no other HTTP requests are processed in the iRule for the duration of the client's TCP connect to the VIP.

    Aaron
  • Joe_Pipitone's avatar
    Joe_Pipitone
    Icon for Nimbostratus rankNimbostratus
    Apr 08, 2010
    What I was confused about was the HTTP::uri vs HTTP::path - i'll apply this to my test VIP and see how it runs and respond with the results here.
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Apr 08, 2010
    HTTP::uri returns the full URI including the path and the query string (/path/to/file.ext?param=value). HTTP::path returns just the path portion (/path/to/file.ext). As it doesn't look like you want to check the query string, it's more exact to use HTTP::path.

     

     

    Aaron
  • Joe_Pipitone's avatar
    Joe_Pipitone
    Icon for Nimbostratus rankNimbostratus
    Apr 08, 2010
    Actually - this request should catch the query string and pass it along, while redirecting and just appending the query string. Your explanations helped - thank you. 

    
"/info.aspx" {
         HTTP::redirect "http://subdomain.oursite.com/default.aspx?[http::query]"
      }