Tricking a website to interpret root-relative paths as belonging to another domain?

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Tricking a website to interpret root-relative paths as belonging to another domain?

Hi,

I was wondering if it was possible to tell a server (or a browser) to interpret all root-relative paths (ie, href="/folder/file.htm" or src="/images/image.jpg") as belonging to a different domain?

Currently, if I'm on domain.com, the path "/folder/file.htm" will be interpreted by the browser as "http://domain.com/folder/file.htm". But can the code be tricked into pointing all those links on a different domain than the one the HTML file is on? Something universal that would encompass ALL path references, even the paths located in the .js files... without actually modifying them in the code (hard-coding "http://alernatedomain.com" as a prefix to all those paths via search/replace is the long and clumsy way of achieving the same result, but I'd rather leave the bulk of the code unmodified).

I won't bore you with a detailed explanation of my reasons for asking this, but I'm essentially hot-linking everything between two domains I own. One domain has the HTML file only, while another has everything else from stylesheets to scripts to images to other HTML pages to link to. Since I own both, there's no danger of one side shutting down hot-linking to the other.

Again, the most important restriction here is that the HTML file containing root-relative paths not be modified in any way, except maybe to add a line of code at the top (if it turns out that that's all that's required). I'm not sure if there's a javascript solution to this per se, maybe the solution is in the .htaccess file..?

This is technically possible, but whenever you consider schemes like this there should be a voice in your head screaming, "This is a bad idea!". The result will never be worth the effort, and you'll be abandoning about 5% of your traffic because they have disabled JavaScript.

There are some good reasons to keep some resources on a second domain (stylesheets and other common graphic elements), but its best to hard-code the domain names if you do.

This is technically possible, but whenever you consider schemes like this there should be a voice in your head screaming, "This is a bad idea!". The result will never be worth the effort, and you'll be abandoning about 5% of your traffic because they have disabled JavaScript.

there is no way in the world that 5% of folks have no JS in their browser.
i doubt 5% of users have even heard of it, or that even 2% of users actually know what javascript is, much less how or why to disable it.

MAYBE 7-10 years ago that was the case, but it's a lot harder to 1. disable it and 2. use any good site without it.

Create, Share, and Debug HTML pages and snippets with a cool new web app I helped create: pagedemos.com

Wait, could it possibly be this simple? This is awesome, if it really works! Any compatibility issues, or is it supported as widely as standard HTML?

Also, what happens to full http paths that are mixed in with the root-relative ones? Your solution seems to transform src="/image.jpg" into src="domain.com/image.jpg" in the eyes of the browser, but what happens to src="http://domain.com/image.jpg" in the same context? Does it become src="http://domain.com/domain.com/image.jpg", or is the code smart enough to ignore full-path urls and affect only the root-relative ones?

Having tried the <base> method, I can confirm that it appears to work near-flawlessly. I say "near", because the only downside I can see is that Adobe Dreamweaver doesn't seem to recognize its meaning, so the preview screen looks nothing like it's supposed to. Not a very big deal, since (in my case) this will typically be the last step of the web design process... but it was worth mentioning nonetheless.

If you use the <base> tag, you'll need to use complete URLs for all of your <a>nchor tag 'href' values. If you use relative URLs, they'll also be converted to point to the domain in the <base> tag and your site navigation will fail.

@rnd me: You're right that the actual figure isn't 5%, but it's been difficult to find reliable data on this. The last time I was able to find any reliable data, it came from an experiment that Yahoo! did about 10-12 years ago that showed roughly 7-8% of users ran with JavaScript disabled. And I estimated that figure had gone down 20-30% since then. I just found a 2010 study also done by Yahoo! that showed the figure to be about 2% in the US and about 1.25% in European countries they examined. So, it's a very low number - much lower than I expected. But it's still bad practice to construct a site that becomes fundamentally broken without JavaScript support, which is what I was talking about.

@rnd me: You're right that the actual figure isn't 5%, but it's been difficult to find reliable data on this. The last time I was able to find any reliable data, it came from an experiment that Yahoo! did about 10-12 years ago that showed roughly 7-8% of users ran with JavaScript disabled. And I estimated that figure had gone down 20-30% since then. I just found a 2010 study also done by Yahoo! that showed the figure to be about 2% in the US and about 1.25% in European countries they examined. So, it's a very low number - much lower than I expected. But it's still bad practice to construct a site that becomes fundamentally broken without JavaScript support, which is what I was talking about.

Most websites who measure things like this use their own website analytics to base the findings on. Which isn't a bad thing in theory, since it eliminates all the middle-men and the information isn't filtered in any way. The only problem is that in practice, these websites tend to cater to tech-minded folk. And tech-minded folk are more likely to do things like disable javascript, or use any browser except IE, etc.

Believe me when I say the average person doesn't even know how to turn it off, much less have any inkling of why they would want to do so in the first place.