Redirect Server

[Laxmi]

Hi,

My client has 2 servers, one contains the E-business application tier and the other Oracle portal.
Say for ex, if the user access the 1 server by
i) [a1.xyz.com:8000...] and the 2nd server by
ii) [a2.xyz.com:7777...]

My client wants to introduce one more server which is a3.xyz.com, in which apache is installed and the request and response to the above 2 servers will be redirected through the a3.xyz.com

The user will be typing the source url as follows in their browsers.

i) [a1.xyz.com:8000...] ==> [a1.xyz.com:8000...]
ii) [a2.xyz.com:7777...] ==> [a2.xyz.com:7777...] .....

Something like the above which has to be redirected.

What are the configurations I should do in the httpd.conf file of the a3.xyz.com server
to implement this redirection server.

I'm helpless since I don't know much knowledge about the apache webserver.

Can anybody help me as early as possible.

Thanks.

[edited by: jdMorgan at 2:29 am (utc) on Mar. 24, 2005]
[edit reason] Fixed horizontal scroll due to long line. [/edit]

[sitz]

I'm unclear on the goals here; your client wants to type in a URL like [a3.xyz.com...] and get redirected to the other servers? or the other way around?

[Laxmi]

Hi,

It's the other way round.

My client wants to type like this as I stated in my previous.

i) [a1.xyz.com:8000...] ==> [a1.xyz.com:8000...]
ii) [a2.xyz.com:7777...] ==> [a2.xyz.com:7777...] .....

Or, Is there any other suggestions.

Thanks

[sitz]

The first one should happen automatically. The second can be accomplished with a static Redirect line (see [httpd.apache.org ]), unless the query string changes each time, in which case we'll need to know *how* in changes in order to be able to help you. I'm not entirely clear on what this means:

My client wants to introduce one more server which is a3.xyz.com, in which apache is installed and the request and response to the above 2 servers will be redirected through the a3.xyz.com

[Laxmi]

Hi,

It's basically the end users will be hitting the server a3.xyz.com and from there the request to a2 and a1 will be redirected instead of hitting the a1 and a2 servers directly.

Thanks,

[jdMorgan]

Laxmi,

Welcome to WebmasterWorld!

Do you really want to redirect the client, or are you looking to set up a3 as a proxy for a1 and a2?

Jim

[Laxmi]

Hi,

I want the client to redirect to the redirect server.
From there their request will be redirected to their respective servers a1,a2.

Thanks

[sitz]

So, you've got two options here:

1) as jd suggested, using mod_proxy (either directly, or via mod_rewrite) to proxy the connections back to the other two servers. Under mod_proxy, a request could come in for, say, [a3.xyz.com...] the Apache instance on a3.xyz.com would make an *outbound* HTTP request to, for instance, [a1.xyz.com:8000...] and return the content that URL to the user. All the user sees in their browser is [a3.xyz.com...] There are three potential advantages here:

You've basically mapped the back-end servers into a3.xyz.com's namespace, which *can* be a huge win (or not, depending on your environment).

This enables you to keep your back-end server (a1.xyz.com in this example) in non-publically-routable IP space (192.168.x.x, for instance). You could set up a 192.168.x.x interface on the a3.xyz.com, another on a1.xyz.com, and mod_proxy would be able to do everything it needed to do, but it would be impossible for anyone outside your local network to make direct contact with a1.xyz.com. This can also be a HUGE win, security-wise, but again, it's not practical in all situations. For instance, a1.xyz.com may *need* to be publically routable because it runs other services which the public needs to be able to get to.

use of mod_proxy opens up the possibility of caching data from the back-end servers. This is NOT a good idea if you're dealing with personalized content (email, a specific user's account, etc), but can work wonders for performance if the back-end server serving "semi-dynamic" (or plain static) content. semi-dynamic content is content which is generated dynamically, say, with a database call, but there's nothing in the content which is specific to a particular user. An example of this would be an online catalog, where the items in the catalog may change from day to day, but everyone who requests a page of the catalog will see the same thing. If you cache this data on the front-end webserver for, say, an hour, you've basically guaranteed that no more than one hit for that page will hit the back-end server per hour. The frees up CPU cycles and enables you to serve many more requests per second.

2) Return a redirect to the back-end servers (a 302, for instance). The advantage here is that it's trivial to implement. The *downside* is that since your back-end servers are running on high-numbered ports, not all users will be able to get them (some firewalls block all outbound ports except port 80. Some are less restrictive, but still don't allow outbound requests to most high-numbered ports). You also lose all the potential benefits of front-end server caching.

Once we have a better idea of which implementation is better for your environment, we'll be able to help you more.