iRule to strip port from redirection

Where I work we have a web farm that sometimes uses port numbers other than 80 to distinguish different web applications on a server. We have VIPS set up on our LTMs to redirect requests to port 80 to the specific port required for an application.

 

 

A problem that we have occurs when the application or web service sends a redirection response back to the client. When it does so the web service attaches the port number on the end of the host.

 

 

For example if IIS recieves a GET request for a directory like this:

 

 

http://www.site.com/coolstuff

 

 

It will redirect that to:

 

 

http://www.site.com/coolstuff/

 

 

But if the request comes over any port 81, the response will include this redirection:

 

 

http://www.site.com:81/coolstuff/

 

 

If the LTM allows this response to go to the client unchanged, the client will try to connect to the LTM over port 81, and the connection will fail.

 

 

I wrote the following iRule to handle this problem:

 

 

This works with matching enabled (fixes issue with http converting to https)
when HTTP_RESPONSE {
  set statstr [HTTP::status] 
  if {$statstr == "301" || $statstr == "302"} {
    log local0. "redirect https [TCP::local_port]"
    set rurlstr [HTTP::header location]
    set rurlstr [findstr $rurlstr "://" 3]
    set lefturl [substr $rurlstr 0 ":"]
    if {$lefturl == $rurlstr}
    {
        set lefturl [substr $rurlstr 0 "/"]
    }
    set righturl [findstr $rurlstr "/" 0]
    if {[TCP::local_port] equals "443"}
    {
    }
    else
    {
     HTTP::redirect "http://$lefturl$righturl"
    }
  }
}

 

 

Basically this rule watches for 301 and 302 responses, and strips any port number that might exist in the header, and then does its own redirection without the port number.

 

 

When I first implemented this I wrote the rule to watch for any response beginning with "30." This caught 304 responses as well as 301 and 302, and caused some files to be unavailable.

 

 

Before I implement this again, I thought it would be a good idea to vet it with you all.

 

 

My questions basically are, are there any problems with this rule that might come back to bite me later on, and how can this code be improved?

 

 

Gil