Forum Discussion

Justin_Haggerty's avatar
Justin_Haggerty
Icon for Nimbostratus rankNimbostratus
Dec 21, 2006

redirect works on some machines, doesn't on others

I've got the following rule in place:

 

 

when HTTP_REQUEST {

 

if { [HTTP::host] contains "old.com" } {

 

HTTP::redirect "https://new.com"

 

}

 

}

 

 

What I'm trying to accomplish is if a user enters our old hostname they automatically get redirected to the new hostname, using ssl. Both of the hostnames have the same IP address in DNS. This rule is kind of hit or miss. We are having the most problems on clients that are using Windows PC's. They never get redirected, and are getting a page can't be displayed in IE, and "The connection has been reset" in Firefox.

 

 

It seems to work 100% of the time from my Mac and Ubuntu boxes.

 

 

Is there something I'm missing?

4 Replies

  • Try logging the client IP address, HTTP host header and URI in the rule and see what the client is sending. As someone pointed out recently, the Host header is only required in HTTP 1.1, so some clients might not send it when using HTTP 1.0.

    You can use something like this:

    
    when HTTP_REQUEST {
       log local0. "client [IP::client_addr] -> [HTTP::host][HTTP::uri]"
       if { [HTTP::host] contains "old.com" } {
          HTTP::redirect "https://new.com"
       }
    }

    The log output will be written to /var/log/ltm.

    Aaron
  • Deb_Allen_18's avatar
    Deb_Allen_18
    Historic F5 Account
    The clients are most likely being redirected, but are unable to follow it completely. You can see if LTM is sending the redirect and whether it is being followed by looking at a packet trace between the client and LTM, and you can see if the browser received & followed it using HTTPWatch (IE) or LiveHeaders (FireFox).

     

     

    It's worth noting that your target URL is actually not complete, as it doesn't contain a URI (the object being requested), so in following the redirect, the browser and the server both have to do a bit of extra work: The server will send a redirect to the "/" URI (which may or may not be passed along properly through LTM, depending on whether the iRule is applied to a SSL virtual server and whether Rewrite Redirects is enabled), and the browser will have to follow it.

     

     

    I'd recommend adding a URI to the redirect (if nothing else at least add a trailing "/" to the redirect string) to prevent the above mentioned additional request/response logistics. You might also want to set "Rewrite Redirects" to Matching in the related http profile.

     

     

    HTH

     

    /deb

     

     

  • Deb_Allen_18's avatar
    Deb_Allen_18
    Historic F5 Account
    (Oops, didn't mean to cross-post hoolio. He may be onto something there as well...)
  • I got it working, it was a problem with another iRule assigned to the virtual server interfering.

     

     

    Thanks for the tips.