Forum Discussion

mel_59881's avatar
mel_59881
Icon for Nimbostratus rankNimbostratus
Jun 19, 2007

rewrite .com to .org

First, great site! Good design, good answers.

 

 

My problem: I need an iRule to rewrite .com requests to .org requests so my certs will not give a warning page. The url is www.mysite.org, but people frequently enter www.mysite.com which we have a dns entry for so it works, but when they try to access secure pages, they get a warning page.

 

 

I think what I want to do is the following:

 

 

when HTTP_REQUEST {

 

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

 

{ HTTP::header replace "Host" "mysite.org" }

 

}

 

 

I'm an iRules noob, and I don't have a setup to test this before going live, so if anyone can give me a thumbs up or show me where I went wrong, I'd really appreciate it.

 

 

Thanks!

 

mel

3 Replies

  • Why not just redirect anyone that hits .com to .org? Then you don't have to worry about subsequent connections to .com.

    The problem you'll have doing it the other way is that if LTM is not doing SSL acceleration, you won't have visibility into the SSL traffic to see the host header.

    So I would just do this on your port 80 VIP (I haven't tested syntax here):

    
    when HTTP_REQUEST {
    if { [HTTP::host] contains "mysite.com" }
    { HTTP::redirect http://www.mysite.org }
    }

    Denny
  • Deb_Allen_18's avatar
    Deb_Allen_18
    Historic F5 Account
    I'd say definitely put Denny's iRule in place on the port 80 virtual to redirect those beginning @ an http URL and minimize the likelihood of warnings overall.

     

     

    However, if the cert is for host.site.org, clients are still always going to get the cert mismatch warning if they browse to https://host.site.com, because as Denny hints, the hostname that was requested is not visible until after the handshake completes, so the warning would already have been displayed in the browser by the time the iRule could decide to send a redirect.

     

     

    /deb
  • Thanks Denny. It's working.

     

     

    Our secure pages are only available from the main page of the app, so port 80 should cover it.

     

     

    Thanks again. Great site.

     

     

    mel