Novell is now a part of Micro Focus

Setting Up Multi-Homing Accelerators in iChain

Novell Cool Solutions: Feature
By Timothy Loveridge

Digg This - Slashdot This

Posted: 5 Jul 2006


A Forum reader asked the following question:

"I'm setting up some path-based multi-homing accelerators, and I wanted to know:

1. Do I have to set up a master and then the child accelerators?

2. What's the situation with alternate host names - do I need to use them, and if so, which should the client point to, or does it matter?"

And here's the response from Timothy Loveridge ...


1. Yes, in order to do path-based multi-homing (PBMH) you need to have a Master accelerator defined first, then the PBMH children will all reference that parent.

2. There appears to be (generally) much confusion about the "Alternate host name" field and its proper use. Here is an attempt at a useful explanation:

When you are accelerating a website, you have two sides you are dealing with: browser-to- iChain, and iChain-to-origin server. The "DNS name" field of an accelerator deals with the Browser-to-iChain side of things. This field answers the question: "What does the user type into their browser to access the site?"

Once iChain receives the request from the browser, it needs to forward that request to the back-end (origin) server to be fulfilled. The other two host name options determine what host name the origin server will see, and what (if any) rewriting will be done in the process. This is the iChain-to-Origin side of things. The use of these fields answers the question: "If I were to request content directly from the origin server, what DNS name would you type in your browser?" or "What does the origin server expect to see in the HTTP Host: header for this site?"

Option 1: "Forward host name sent by browser to the web server"

If this option is selected, the DNS name received by iChain is forwarded to the origin server unmodified. For example, if the user typed in "" to access the site, then iChain passes "" back to the origin server with the request.

Option 2: "Alternate host name"

If the origin server expects a different DNS name than iChain receives, you can supply the expected value here. This value will replace the accelerator "DNS name" value in the HTTP Host: header when requests are sent to the origin server. For example, the back-end server expects "" for the public site. The "DNS name" of the accelerator is "". User types "" into their browser to access the site. iChain replaces (rewrites) "" with "" before the request is forwarded to the origin server.

Rewriting is also performed on the way out. Once a page has been retrieved from the origin server, iChain looks for occurrences of "Alternate host name" (and the values specified in the "Web server addresses" field) in the HTML page. If any are found, those occurrences are rewritten to be the value of the "DNS name" field of the accelerator. This is done to ensure that the user sees "" in all links instead of "".

Here's a different example (not that I recommend this ...)

You have noticed that people in your company access a particular site a LOT, and want to cache more of the content locally. You have decided to accelerate that site with iChain. For the purpose of this example we will use as the site you will accelerate. You create a DNS name for your user of that your users can use to access this site.

In your accelerator configuration you have the following options:

DNS name:
Alternate host name:
Web server addresses: <appropriate IP(s) of>

When users type in "" the request goes to iChain. iChain changes the host name to be "" before forwarding the request to the origin server(s). (This way CNN always sees the requests properly, as, instead of Any pages that come back from the site are rewritten by iChain so that the links and images on the page appear (to the user) to be from

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates