Forum Discussion

Arie's avatar
Arie
Icon for Altostratus rankAltostratus
Jun 30, 2008

Multiple redirect/respond invocations not allowed

I keep running into this error:

"Multiple redirect/respond invocations not allowed"

We've got a fair number of web sites that all seem to have their own redirect requirements (often redirecting to other sites), so we've got stacked redirects. Combining the redirects in one large redirect iRule is not an option since different VSs have different combinations of redirects.

Here's the framework for most redirects: 

  
  when HTTP_REQUEST {  
    
  set wwwRedirect true  
    
  if { $wwwRedirect } {  
    
  if { not ([matchclass [string tolower [HTTP::host]] equals $::ExcludeFromWWWRedirect]) and not ([string tolower [HTTP::host]] starts_with "www") } {  
    
  HTTP::respond 301 Location "http://www.[HTTP::host][HTTP::uri]"  
    
  return 0  
    
  }  
    
  }  
    
  }

I assumed that the "return" command would instruct the LTM to abort further processing of iRules at this time and return control to the caller.
application delivery
dev
devops
iRules
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Jul 01, 2008
    Return will stop the processing of that event in that iRule. It won't affect other events or other iRules enabled on the same VIP.

     

     

    Are you checking in other iRules on the same VIP to see if wwwRedirect is true before redirecting? You would also want to set wwwRedirect in any other rule on the VIP which issues a redirect.

     

     

    Aaron
  • Robert_Sutcliff's avatar
    Robert_Sutcliff
    Icon for Nimbostratus rankNimbostratus
    Jul 01, 2008
    Hi,

     

    You may notice that HTTP::respond (and HTTP::redirect) do various wierd things...

     

    They sets the relevant headers and content for the response, and sends the response (once the HTTP_REQUEST event has completed)

     

    Because it is sending the response itself, the HTTP_RESPONSE event will never be triggered (although other later events still are, eg CLIENT_CLOSED)

     

     

    Unless you are doing further processing on the HTTP_REQUEST event (eg logging, setting other headers) I would suggest you also use the "event HTTP_REQUEST disable" statement (before "return"ing from this iRule). This causes TMM to not process any further iRules for this event (or rather, specifically the HTTP_REQUEST event)

     

     

    So your statement block might become something like (set the response, don't process any other rules, exit this rule)

     

     

    HTTP::respond 301 Location "http://www.[HTTP::host][HTTP::uri]"

     

    event HTTP_REQUEST disable

     

    return

     

     

    The other alternative would be to set a variable (binary switch) if a redirect has been issued, and check that this isn't set before doing any other redirects

     

     

    Regards,

     

    Rob.
  • Arie's avatar
    Arie
    Icon for Altostratus rankAltostratus
    Jul 01, 2008
    Good to know that "return" applies to the current iRule only.

     

     

    If I use disable on HTTP_REQUESTS, does that apply to the connection as a whole or merely the current request? My concern is that if it applies to the connection itself and it gets re-used by the client for subsequent requests that those are no longer subject to any of the iRules.

     

     

    I have the same question about using a binary switch - would I run the risk of disabling the redirect iRules for subsequent requests that re-use the same connection?