Other than fixing this obviously unintended “feature” of Excel/Office trying to verify links as others have posted, the only workaround that I found was to create a local redirect page which could take my unique parameters within the URL and open a new window as follows (thanks to others for the JavaScript code)
#Hyperlink not working in excel pdf pdf#
The problem is clearly coming from Excel, because if I take that exact spreadsheet, save it as a PDF, the hyperlinks that display in the PDF work perfectly fine when clicked. However, If I’m not logged in to the site, I will get redirected to the login page, as expected.īut when clicking the exact same URL in Excel, with the same conditions, I either get the login page only, or my remote site just tells me it is an unsupported browser. If I cut and paste the URL in a new tab or window, Chrome is smart enough to find that I have already authenticated and opens the new page properly. Even though I am logged in already in a different window, it will not work properly. I found this problem crops up when the target URL is a secure site that required a login. It would seem that, when called from Excel, the redirect is not always being honoured. So as stated, this is GoDaddy doing a temporary redirect. Kind of reaction is expected of the client. The status codes 303 and 307 haveīeen added for servers that wish to make unambiguously clear which Response, performing a GET on the Location field-value regardless
However, mostĮxisting user agent implementations treat 302 as if it were a 303 To change the method on the redirected request. Note: RFC 1945 and RFC 2068 specify that the client is not allowed Request unless it can be confirmed by the user, since this mightĬhange the conditions under which the request was issued. GET or HEAD, the user agent MUST NOT automatically redirect the
#Hyperlink not working in excel pdf code#
If the 302 status code is received in response to a request other than Response SHOULD contain a short hypertext note with a hyperlink to the Unless the request method was HEAD, the entity of the The temporary URI SHOULD be given by the Location field in the Only cacheable if indicated by a Cache-Control or Expires header Since the redirection might be altered on occasion, the client SHOULDĬontinue to use the Request-URI for future requests. The requested resource resides temporarily under a different URI. The initial link returns a 302 status code Too much here to add as a comment I'm afraid. You will have more luck using a URL that does not rely on some hidden information from a cookie, like (Just for testing it's not a permanent solution.) 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.
And the result of that is opened in your default browser. Lacking the cookies (more precisely: lacking a session), GoDaddy gives that Internet Explorer component some redirect. (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. This uses a Windows/Internet Explorer component to determine if the URL works. Before opening it in your browser, Excel first runs Microsoft Office Protocol Discovery.
Paste the URL into a different browser (or remove your cookies) and you'll get the same results.Ĭlicking a URL in Excel seems to open it in your default browser. The URL you're using needs some more information from a cookie to display the search results rather than the search page.
0 kommentar(er)
