Excel hyperlink not redirecting properly (bug?)
I have an Excel hyperlink problem: I click on, let's say A1, copy the link in it (http://www.godaddy.com/domains/searchresults.aspx?ci=54814), right click on hyperlink and copy that SAME URL as the link (if it is not automatically detected and changed).
When I go to click on it, I am redirected to http://www.godaddy.com/domains/search.aspx?ci=53972.
If I copy and paste the link directly into the browser, it works fine (i.e., I am not redirected to a different URL).
Does anyone know what's going on?
The URL you're using needs some more information from a cookie to display the search results rather than the search page. Paste the URL into a different browser (or remove your cookies) and you'll get the same results.
Clicking a URL in Excel seems to open it in your default browser. But that's not really true. Before opening it in your browser, Excel first runs Microsoft Office Protocol Discovery. This uses a Windows/Internet Explorer component to determine if the URL works. (It does not identify itself as Internet Explorer, but as "User Agent: Microsoft Office Existence Discovery".) And if the results are (somehow) okay then it will open the result of that check in your default browser.
Lacking the cookies (more precisely: lacking a session), GoDaddy gives that Internet Explorer component some redirect. And the result of that is opened in your default browser. That's the URL you're seeing.
Most likely your default browser is not Internet Explorer? Then pasting the URL into IE directly and clicking it, to get the cookies, might then also make the link work from Excel. (Just for testing; it's not a permanent solution.)
You will have more luck using a URL that does not rely on some hidden information from a cookie, like http://www.godaddy.com/domains/search.aspx?domainToCheck=superuser.com
This is Excel fault. If you paste the link in Outlook email or WordPad and you open the link from there it will work correctly.
Excel should never create hidden session to verify the hyperlink. what's the point of it. It just needs to open it, nothing else. They use the same logic in MS Word. It doesn't work from there neither. When Excel tries to verify the link in the background, new session is created that is not authenticated so it gets redirected to login page or something. After that instead of opening the original URL in the browser, Excel is opening the redirection url. They really know how to make simple thing complicated.
This is a known Microsoft bug where hyperlinks are redirected to another page if:
- You are using Microsoft Internet Explorer:
- with a proxy server
- while using a firewall that does not allow HTTP requests on your local network
- Internet Explorer is not your default browser.
- The
ForceShellExecuteregistry key is not present or is not set to 1
You can apply the fix from here:
http://support.microsoft.com/kb/218153
It's definitely annoying. One workaround is to make link to a local file that redirects to the hyperlink. For example, something like:
<HTML>
<HEAD>
<TITLE>Redirect</TITLE>
<META HTTP-EQUIV="refresh" CONTENT="0;URL=http://www.google.com">
</HEAD>
<BODY>
Redirecting...
</BODY>
</HTML>
I don't know much about HTML, but it would be nice to be able to pass an argument (ie, the URL) to this local html file.
Too much here to add as a comment I'm afraid.
The initial link returns a 302 status code
From the w3c standards:
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.
So as @xlm stated, this is GoDaddy doing a temporary redirect.
It would seem that, when called from Excel, the redirect is not always being honoured.