Redirecting and masquerading the result for the client.

Technically speaking, the HTTP::header replace Host command replaces the Host header in the ingress request, which the client wouldn't see. If the back end server is somehow reflecting that value, then that's a different issue. There isn't usually a Host header in an HTTP response, so where might the client be seeing this replaced value? I ask because the fix is dependent on where the value is coming through.

Depending on how complex the masquerade, you have a few options from a fairly simple iRule and STREAM replacement, to a much more elaborate ProxyPass or 11.4 rewrite profile. So is it just the Host header that needs to be replaced, or the URI as well?

The header response headers contains the location which is the rewritten one.

Request headers: host: is rewritten origin: is not rewritten Referer: is not rewritten

Response Headers: Location: is rewritten

Hope this answers your questions (the traffic is over ssl, terminated in the f5 and created again towards the webservers)

Here's a very basic iRule that will catch headers and payload data. Apply an empty STREAM profile to the virtual server to enable STREAM processing in the iRule. If you don't need to catch payload, then you can remove the STREAM profile and all of the STREAM statements.

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

     inbound: replace Host header with internal name
    HTTP::header replace Host "foo.example.com"
}
when HTTP_RESPONSE {
     outbound: replace Host value (if it exists) in all headers
    foreach x [HTTP::header names] {
        if { [HTTP::header $x] contains "foo.example.com" } {
            HTTP::header replace $x [string map {"foo.example.com" "external.domain.com"} [HTTP::header $x]]
        }
    }

     outbound: replace Host value in payload
    STREAM::expression {@foo.example.com@external.domain.com@}
    STREAM::enable
}

If you are just trying to get content from another location when a client makes a request then you can simply point to a pool with the web server and use rules, HTTP profiles, and/or HTTP_classes to mangle the traffic as needed. You can also pipe in content via sideband if you want to glue some things together in response to requests.

From my response I'm obviously having issues with the request to redirect and the use of HTTP::header other than to mask what you did after getting the request.

Are you using host-header based instances on the web servers? There's probably no need to fiddle with the host header if the host doesn't matter.