Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So, we have some publishers in our department who have a passion for interlinking their MS Office documents (Word and Excel mainly) with relative hyperlinks. Then they publish them on our intranet website.

EDIT - I'm clarifying the issue cause the two answers missed the point.

  • In Excel and other Office documents, the hyperlinks are relatively pathed, and they do not include any explicit protocol.

  • When opened from the file system (Windows Explorer) these paths work (as expected).

  • When a hyperlink to this document is selected from a webpage, all browsers prompt the user to Open or Save the file. In all cases I am discussing here, the user is clicking "Open".

  • In Firefox, Chrome, and Opera, the Excel application is opened, and the relative links now use the file:// protocol and attempt to relative path from the cached copy. They are broken as expected, as the linked files do not exist in cache.

  • However, when opened from the Internet Explorer browser, the Excel client is launched, but floating over the hyperlinks, they are fully qualified addresses using the http:// protocol, as if the file was being served up by IIS like a web page.

So yes... it is something about the Micrsoft products (IIS, IE, and/or Office) and how they work together.

My question is How and Why would Excel be able to map the relatively pathed hyperlinks within itself to the fully qualified web address of where it was linked from?

share|improve this question

migrated from Dec 21 '11 at 2:59

This question came from our site for professional and enthusiast programmers.

On a side note. It is a relative link. By definition, a file opened off the Internet is going to have links relative to the Internet. Should a relative link not be a relative link? – surfasb Dec 21 '11 at 21:34
It's just possible that you might be going at this the wrong way. Save a webpage to the desktop and then open it. Click on those relative links. They are going to break like china. – surfasb Dec 21 '11 at 21:41
If you turn off ActiveX, you don't get this behavior. – surfasb Dec 21 '11 at 22:01
@surfasb you are repeating what I already know... relative links should always break when you move the source document without moving the targets with the same structure... I am trying to figure out why opening an Office doc in IE does not break as it should. I don't know how better to explain. ActiveX is not the issue because the browser is not using it, and there are no ActiveX controls on the HTML page. The magic, can't be entirely in Excel, or it would happen across all browsers. It is something in IE. – one.beat.consumer Dec 21 '11 at 22:33
You are right, it isn't specifically ActiveX. It looks like IE uses a Broswer Helper Object to open Office Documents. Disabling that isn't an idea situation as it makes the UX a bit clumsy. I was specifically trying to nail down which component differentiates IE's handling from Firefox/Chrome's. I'm personally surprised I've never run into this before. Possibly my predecessor did and fixed it. I'm almost certain I will run into this issue again and would like to see a resolution. – surfasb Dec 21 '11 at 23:10
up vote 1 down vote accepted

Though the situation has nothing to do with Subversion, this is the closest answer I could find:

Some combination of Microsoft's "Office Document Cache Handler" browser helper object, and the WebDAV capabilities of the office documents and the web server.

Also the relevant Microsoft support doc that is linked in the Serverfault question.

share|improve this answer
I haven't done any further testing, but I can reproduce your behavior off of a Sharepoint Server. But that is expected behavior in our case. Otherwise the crazy Excel charts people produce would break.Otherwise, we zip up the hierarchy of files. – surfasb Dec 21 '11 at 21:57
@one.beat.consumer, rather than edit an incorrect answer, post the correct answer yourself and you should be able to select that as the correct answer, removing the "Answered" tag from this one. – music2myear Dec 22 '11 at 18:24
@music2myear surfasb provided two answers to the scenario, the second one was correct, the first was incorrect. For clarity to other reasers, my edit was to remove the irrelevant incorrect portion and leave the correct answer up. The suggested edit is the right answer and what surfasb came up with which is why I marked it as correct. Please commit the edit. – one.beat.consumer Dec 22 '11 at 18:54
@surfasb has the ability to approve the edits made to his answer. I'll defer to him in this case. If he approves the edits there will be no issue. – music2myear Dec 22 '11 at 19:09

A URL, even one starting with file:// is still a URL and your default browser for URLs is set to Internet Explorer. I would try linking the file using \\servername\share\filepath\filename or DriveLetter:\filepath\filename.

Using Group Policies, you can set them to automatically map drive letters when logging onto their computer.

share|improve this answer
-1 but I don't have the rep. I am a programmer; I know what a URL is and the different protocols. Read the question again. Referencing a UNC share is not an option here. The files exist within the web applications folder structure and will be linked via http from the page. – one.beat.consumer Dec 21 '11 at 19:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .