help with Irule to change url from servername

Hi Shawn, it appears that you might be using OHS for this app. This is probably easier if you add a Virtual Hostname directive to the httpd.conf configuration on the server, listening on port 80. Tie that virtual hostname to the DNS FQDN that resolves to the LTM VIP.

Of course, if you want to use an iRule to change the URL ":xxxx" port values, you can, but I think most people prefer the virtual hostname method. If you search on DC for HTTP port re-write, you will find quite a few options.

Good Luck! Chris.

If you're running 11.4, you can use the new rewrite profile that will convert between the two sets of values. If running an earlier version, you can use the ProxyPass iRule to do this conversion.

Please allow me to clear up one more detail. The Redirect Rewrite option in the HTTP profile is NOT used to rewrite URLs. This option, when applied to an HTTPS (SSL) virtual server, will rewrite any redirects, actual 30x type messages, from the server if they contain "http://" instead of "https://".

The challenge in your request is dependent on where and how often this internal URL shows up. If it's simply in a redirect, and/or that Host header needs to be presented to the server to prevent it from redirecting, then that's pretty easy to solve with a quick iRule. If, however, that URL is wrapped around object reference, images, JavaScript, style sheets, then you'll most likely need either a more complex iRule, the ProxyPass iRule, or the rewrite profile in 11.4.

Thanks Kevin for the clarification....

At this point I really don't even know where to start. When it returns http://servername.abc.com:7777/sso/pages/cs_login/login.jsp, is that the HTTP response ?

I have tried a few things so far but nothing has worked. I am starting to wonder if that can be done.

There are a few things to understand in this situation.

1. First and foremost, and HTTP request is what the client sends to the server, and an HTTP response is what the server sends to the client, in response to the request.

    

2. There are potentially many different places where this offending URL can show up at the client, and how you address it depends on where and how it shows up. An HTTP response, sent by the server, can/will contain:

    

   • HTTP headers - these are hidden values that either tell the browser about the server and/or response payload, or command the browser to do something. For instance, an HTTP redirect is usually performed with a 30x type message (301 or 302 mostly) and a Location header. The Location header contains the address that the browser should go to when it receives this message.

      

   • HTML payload - this is the document rendered by the browser, which may contain references to other objects, images, style sheets, JavaScript, etc., and those references could be using the internal URL namespace.

      

   So as you can see, the solution depends on where the URL is showing up in the response. The best thing you can do is to run a client side capture utility like HTTPWatch or Fiddler and watch the HTTP interaction.

    

3. Now, if this internal URL is only showing up in one place, a single redirect for instance, or the server just needs to see this internal Host header (SharePoint does), then a fairly lean iRule can fix it. If the document is riddled with internal object references, however, then you may need something a bit more complicated. The ProxyPass iRule is designed to scrub request and response content and map external to internal URLs and vice versa. You can do the same with 11.4's rewrite profile.

    

The very FIRST thing you need to do though, is to identify WHERE and WHEN the client sees this internal URL. Please report back what you find.

The internal URI stays the same except that when the user logs in the port number changes from 7777 to 8090.

I.E user goes to either http or https://cstest.abc.com/cslogin.html

That gets redirected to http://servername.abc.com:7777/sso/pages/cs_login/login.jsp

After the user logins he gets sent to http://servename.abc.com:8090/portal/page/portal/CSR_GROUP_CS432/CUSTOMER_SUITE

Hopefully this helps in clearing up my issue.

Hi Shawn,

As Kevin told you, an HTTPwatch could help to understand. If you want to rewrite payload, the command is STEAM : https://devcentral.f5.com/wiki/irules.stream.ashx.

If you want to rewrite redirect (30x answer), have a look : https://devcentral.f5.com/articles/rewriting-redirects.UoptfGTN48w

It's not really difficult but you need to know how URL are shown up (redirect, payload CSS JS ...)

Hope this help.

I'm going to have to make a few assumptions, so please tell me if I'm wrong. First, it would appear that authentication happens on port 7777, while everything else happens on port 8090. The best way to handle that, I believe, would be to create two separate pools of servers, one for each listening port. Second, I'll also assume that any URI that starts with "/sso" is going to the port 7777 service, and everything else goes to port 8090. We can use that to switch between the pools. And finally, I'm assuming the server doesn't actually care what Host header you send it, so if the server received a Host header that equaled "cstest.abc.com", the server would ignore this. If that isn't the case, then the following iRule might get a little more complex. Here's what it might look like though:

when HTTP_REQUEST {
    STREAM::disable
    HTTP::header remove Accept-Encoding

    if { [string tolower [HTTP::uri]] starts_with "/sso" } {
        pool my_7777_pool
    } else {
        pool my_8090_pool
    }
}
when HTTP_RESPONSE {
    if { [HTTP::header Content-Type] contains "text" } {
        STREAM::expression {@match@replace@}
        STREAM::enable
    }
}

In the HTTP_REQUEST event we'll switch between the pools based on the URI. In the HTTP_RESPONSE event we'll use a STREAM expression to replace any instance of "servername.abc.com:7777" and "servername.abc.com:8090" in the response payload with "cstest.abc.com".

I should also mention that the above precludes any URI mapping, so if you need a client side "/cslogin.html" URI to translate to "/sso/pages/cs_login/login.jsp" on the server side, then that will take a more complex iRule.

Sorry I have not responded. I have been away for a bit.

Things have changed, since it is being run internally I do not have to remove the port number or change the hostname. What I DO have to do though is create another pool that will be using port 8090.

So here is what I have

User types in https://cstest.abc.com/cslogin.html in the browser

The response back takes the user to the login screen which is running on port 7777 http://servername.abc.com:7777/sso/pages/cs_login/login.jsp

The user logs in to the application and gets taken to the following page. http://servername.abc.com:8090/portal/page/portal/CSR_GROUP_CS432/CUSTOMER_SUITE

I searched around for posts that would handle a wierd situation like this but most of what I found would be where the irule would choose between the two pools, unlike this situation where we are using both pools no matter what.

Thanks Again

Shawn

Ok I finally have something that is workable.

when HTTP_REQUEST {

Disable the stream filter for all requests STREAM::disable

LTM does not uncompress response content, so if the server has compression enabled and it cannot be disabled on the server, we can prevent the server from sending a compressed response by removing the compression offerings from the client HTTP::header remove "Accept-Encoding"

}

when HTTP_REQUEST_SEND {

Need to force the host header replacement and HTTP:: commands into the clientside context as the HTTP_REQUEST_SEND event is in the serverside context clientside {

   Look up the selected server IP in the datagroup to get the host header value
  set host_header_value [class match -value [IP::server_addr] equals ip_to_hostdev_dg]

   Check if the lookup returned a value
  if {$host_header_value ne ""}{

      Replace the host header value
     HTTP::header replace Host "$host_header_value:[TCP::local_port]"
     log local0. "[IP::client_addr]:[TCP::client_port]: Replaced Host header with $host_header_value:[TCP::local_port] to [LB::server]."

}

} }

when HTTP_RESPONSE { Check if server response is a redirect if { [HTTP::header is_redirect]} { Assuming server is including a port in hostname portion of redirect with 4 digits (i.e. hostname:7777) We are going to take the URI path and replace the hostname with our preferred name

  log local0. "trimming [string trimleft [HTTP::header value Location] http:// ]"

  set redirect_uri [findstr [string trimleft [HTTP::header value Location] http://] : 0]
  HTTP::header replace Location https://csdev.abc.com$redirect_uri

} elseif {$host_header_value ne ""} {

     Match an replace strings
    STREAM::expression "@http://$host_header_value@https://csdev.abc.com.us@ @http%3A%2F%2F$host_header_value@https%3A%2F%2Fcsdev.abc.com@ @$host_header_value@csdev.abc.com@"

     Enable the stream filter for this response only  
    STREAM::enable  
}  

}

I had to create 7 vips with the same ip going to the following ports 7777 8090 9001 9002 9003 9004 9005

Created a data group and stream profile and applied the irule to vip using port 7777 and 8090. Everything seems to be working well except for one thing and hopefully someone here can help.

Once the user is logged in and they want to run a report. The report comes up in another browser window (Pop-Up), that doesn't apparently follow the irule and replace the servername with the hostname. I ran HTTPwatch and it it looks like the pop is generated on port 9003.

How would I handle the pop-up window ?

If anyone wants to take a look at my http watch file let me know.

Thanks,

Shawn