Rewriting HTTP::host

Hi,

you should try with the command HTTP::header replace

 
 HTTP::header replace "Host" foo.bar.com 
 

HTH

N.

My bad on that one. Sorry about the bad suggestion. For the host header, you'll need to use the "HTTP::header replace" command as suggested here.

 

 

-Joe

...which rewrites the header, but doesn't actually send the request to foo.bar.com, right? I still need a pool with one or more hard-coded ip addresses.

 

 

This is the essential issue: can I take a connection to a virtual, and send it out to some external domain, using standard DNS resolution so I don't have hard-coded ip addresses?

 

 

And thanks for the reply.

Yes the command will only replace the HTTP header but will not route this request to this new domain

 

 

Can you explain a little more what you want to achieve? i'm not sure to understand :s

 

 

Sure. Let's say your company has an app that connects to a web service from an external vendor. And you need to get to that app via "bar.foo.com/widget/some_uri". Now, your internal app server isn't on a routable IP address, so you'd like to go thru the F5, and have it proxy the communication with the external host. However, foo.com may have their own load balancing, or dns round-robin, or decide to change the ip address of host "bar" next week. Therefore, you can't have hard-coded ip address(es) as your pool member(s), or you'll have an outage every time they make a change. Therefore, you'd like to have the F5 resolve this host.domain - and preferably not cache it forever between restarts.

 

 

Again, I can't help but feel I'm missing something basic here. So thanks for bearing with me, and for any suggestions.

Hi,

 

 

I think i understood and i'm not really sure we can do this ... When you add pool members to a pool with a hostname i remember we do a name resolution when it is added and we register the result of this lookup as a pool member.

 

 

what you want to do is every time you receive a new HTTP request you want to do a name resolution (which is feasible: Click here) and then you want to send this request to this IP address. i can't manage to think of a method then to send the packet to this IP which is a Public IP ie not defined as a node or a pool member

 

 

Great, thanks for the tip. Following from your link, there's a thread from 2006 that looks like they got it working exactly as I need. Testing...

if you can post the result if it works i'd be interested in seeing it !

Well, this is looking like "close, but no cigar". There appear to be a few gotchas.

 

 

1. Getting the name to resolve. Older threads (links provided below) suggest that folks have gotten this to work by leaving the default entry in tmm_base.conf: "use server $IP_ADDR_LOCALHOST $service(domain)" . Darned if I can get this to work. Pointing instead to my primary resolver from resolv.conf seems to work, but that's hardly ideal; again, I'm hard-coding a hostname entry. There's also a suggestion of listing the forwarders in named.conf, but this gives an error "forwarders directive is unknown"; seems like another unnecessary duplication of what's already in resolv.conf.

 

 

2. The node isn't defined. Even if all the resolution issues went away and NAME::lookup returned the desired IP address, there's no way to actually send anything to this host. That's because it isn't defined on the system as a node, so the statement "node $resolved_server_ip [TCP::local_port]" doesn't go anywhere. I can't know in advance all the possible addresses that "foo.bar.com" might resolve to, so can't add the nodes directly. Again, I'm puzzled that this approach seems to have worked for people in the earlier threads.

 

 

Seems to me that an iControl script may be the only way to go: periodically resolve the hostname, then add it as a node, and update the pool.

 

 

Links:

 

http://devcentral.f5.com/wiki/default.aspx/iRules/DestinationSnatUsingDNS.html

 

http://devcentral.f5.com/default.aspx?tabid=53&view=topic&forumid=5&postid=6546

 

http://devcentral.f5.com/default.aspx?tabid=53&view=topic&forumid=5&postid=1332

 

 

My thanks again for the info & suggestions.

If name resolution is failing and you've followed the steps which worked for an older LTM version, you could open a support case with F5 to get help.

 

 

On your second point, you don't have to have the destination IP address defined as a node in order to use the node command. The idea behind the command is that it allows you to specify an arbitrary destination IP.

 

 

The iControl route might actually be the best in that it allows more programmatic control over the process and doesn't tie up TMM (and therefore every other connection) if the name resolution takes a while or times out.

 

 

Aaron