Imagine the following scenario. You are typing some rich text entry on your SharePoint intranet with the internal URL http://intranet/. It might be a blog post, a discussion board, or just a content editor web part. You insert a link to other intranet site, like http://intranet.client.com. When you test the link, it looks like you want, but it works as just http://intranet/.
If the site has alternate access mapping (AAM) with several web applications (for example, with different authentication), and default or intranet AAM has such short form (in the following example it’s http://portal/), all instances of the website convert the link this way:
(normally it ends with 404 error)
So SharePoint converts internal links to relative and overrules the conversion for such external links. The links which have the same beginning as default or intranet site URL are converted to relative ones, and then they are interpreted as being located on the default URL:
How does SharePoint do the translation? Possible scenarios:
a) In real time every time the page is loaded. This means that in the database, the absolute link is still there.
b) in the background process (database) (not very probable).
c) When the user saves the content.
Shortly after saving, on the back end (in the content database, table AllUserData, field ntext2) the links are already relative:
<div class=ExternalClass97C68512A4184122B15D3302EC759305>
<div><a href="http://portal.client.org">http://portal.client.org</a></div>
<div><a href="/">http://intranet.client.com</a> </div></div>
What happens when you add additional alternative access mappings AFTER you already entered content? The relative URL’s are no more updated, they stay as they were with an old AAM.
So this conversion takes place when the user saves the content (scenario c).
Cheating like trying to put a slash next to short URL in AAM doesn’t work, the extra slash is cleaned on saving.
This behavior was noticed a long time ago and not fixed by now in SP 2007:
http://www.eggheadcafe.com/software/aspnet/30556472/directrelative-links-in.aspx
http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=57
http://blog.mastykarz.nl/inconvenient-content-editor-web-part/
Luckily in SharePoint 2010 this bug is fixed.