# Problem with redirecting



## julythirteenth (Oct 2, 2012)

We've some www addresses supposed to be redirected to one of them. This works ok with every other browser, but IE doesn't redirect any of the addresses to the one with the actual content. IE does find the actual site, but claims the other addresses don't exist. What could be the problem?


----------



## Corday (Mar 3, 2010)

Are you the end user or is this your site you're referring to?


----------



## julythirteenth (Oct 2, 2012)

It's my site, which several end users have tried to reach through the redirecting addresses with IE without succeeding. The redirecting is supposed to happen at the name servers with the "stealth" function chosen.


----------



## Corday (Mar 3, 2010)

Moving to site mgmt. for more expertise.


----------



## Fjandr (Sep 26, 2012)

How exactly did you configure these redirects? In what software, web management tool, etc?


----------



## julythirteenth (Oct 2, 2012)

The extra domains are located at domain.com name servers, while the actual address is on the name servers of the home page service provider. It's possible to use the domain.com user account to redirect those addresses to an address located on another name server, and all the other browsers except for IE (any version) do redirect correctly.


----------



## Fjandr (Sep 26, 2012)

Since you mention the "stealth" option, I assume you intend for altdomain.com to display the content of domain.com but still appears in the address bar as altdomain.com, correct?

Do these redirects fail universally, for all users, regardless of their location?

Is the domain management package Cpanel, custom, or something else?


----------



## julythirteenth (Oct 2, 2012)

Well, now I've managed to locate the three factors causing the problem.

1. IE (any version on any computer we've tried)
2. domain.com "stealth" redirecting (we've two addresses on the website providers own name servers, and that "stealth" redirecting works fine also with IE.
3. Our site's CSS file. If I remove the address to that file, the redirecting from domain.com name servers start working also in IE.

So if one of the factors IE + domain.com redirecting + our CSS file is changed, the problem goes away. The easiest way to vanish the problem would be to change the domain.com name servers to the website providers name servers, but domain.com doesn't accept this change.

And the white page IE shows is caused by a frame named blank.html which IE adds on top of the actual "stealth" frame with the actual address.


----------



## Fjandr (Sep 26, 2012)

I'm stumped. I can't explain how a site won't resolve if there's a CSS link in the code. If the server is actually parsing the file to hit the CSS link, there had to be a connection made to get to that point.

Are you sure the error is actually one saying the site was not found, rather than some sort of server error (500, 503, etc)?


----------



## julythirteenth (Oct 2, 2012)

As I tried to correct in my latest answer, in fact IE finds the site, IE just puts a frame called blank.html on top of it, so the only content on the page is a white frame.

The situation got even more weird after I tested to cut out some content from the CSS to find out where the problem is. The redirecting started to work by removing the line: 

_position: relative;_

All other browsers do still center the page content with that line removed, but IE centers the content only if the two addresses which are located on the site ISP:s own name servers are used. The three addresses which are redirected via domain.com name servers align the page content on the left.

Domain.com has to have some bug in their system, which disadvantages only IE.


----------



## Fjandr (Sep 26, 2012)

After a bit of looking, it appears IE doesn't function well with stealth forwarding. I'm guessing it's because of the variability of its anti-phishing settings.

The problem isn't a bug in the domain, it's entirely within the way IE is designed. IE is well-known for having odd behavior that must be explicitly checked for and fixed. Since CSS is rendered entirely within the browser, a CSS line being the culprit means the browser's interpretation of that line is 100% the cause, whether the output is considered a fault according to the standard or not.


----------



## julythirteenth (Oct 2, 2012)

"Domain.com" is the actual name of the service where we bought the .com, .net and .org domains. The two .fi addresses are bought in Finland and uses other name servers than the ones bought from "Domain.com". The weird thing is that IE works properly with stealth redirecting from the one .fi domain to the other. It's just the .com, .net and .org that causes this misbehavior, so this must have something to do with the "Domain.com" stealth redirecting also, not just IE.


----------



## Fjandr (Sep 26, 2012)

Interesting. Maybe it is an intentional use case of their anti-phishing technology then. I'm not clear on the extent of what it does, so perhaps it has problems with cross-domain frames that don't use the same name servers.

I can really only guess at this point without actually looking at the redirection and NS setups.

Out of curiosity, do you mind me asking why you are using stealth redirects in the first place? The only place I've seen them used is to disguise free hosting URLs. For fully hosted domains, I haven't encountered a use for them that was anything but very temporary. Maybe there's a better way to accomplish whatever your actual end goal is.


----------

