Changing host name to web servers

If I use the technique of replacing the host name, as in

 

 

when HTTP_REQUEST {

 

Replace the existing host header with new_domain.com.

 

If there isn't an existing host header it will be inserted

 

HTTP::header replace Host "www.mysite.com" }

 

 

This works for the first page, but all subsequent pages revert to the original host. Will a streams profile help here?

 

tried creating a streams profile and also used streams in an iRule as I found on DevCentral. Still having issues before and I thought I had it!

 

 

when HTTP_RESPONSE {

 

if {[HTTP::status] ==200}{

 

STREAM::enable

 

STREAM::expression \

 

"@www.testsite.com@www.mysite.com@"

 

}

 

}

Have you included some logging to make sure the iRule is being processed for each client request? If you are issuing a header replace and the header is not getting replaced then it sounds like you've found a bug. Do you have rechunking enabled in your HTTP profile? If not, you might want to try to give that a shot.

 

 

-Joe

Also, you could change the stream rule a bit to fix a couple of potential issues:

1. You might want to rewrite response content if the response type is text-based--not a 200.

2. You should set the stream expression before enabling the stream filter as noted in SOL8207 (Click here). If you're running 9.4.2 or later, you'll get a TCL error in the HTTP_RESPONSE event using enable then setting the expression.

 
 when HTTP_RESPONSE { 
    if {[HTTP::header value "Content-Type"] starts_with "text"}{ 
       STREAM::expression "@www.testsite.com@www.mysite.com@" 
       STREAM::enable 
    } 
 } 
 

Also, if the web server is using compression, LTM won't uncompress the responses and the stream profile won't match. You could either disable compression on the web server or set the Accept-Encoding header in requests to a null value.

If you try these changes and still see issues when trying to access the application, try using a browser plugin to view the response headers and content like Fiddler for IE or HttpFox for FF. This should give you an indication as to where the problem is occurring. As Joe suggested, debug logging would also help.

Aaron