How can I make all relative URLs on a HTML page be relative to a different domain then it's on (in HTML elements as well as JS HTTP Requests)?

Question

I have a page that has "domain relative URLs" such as ../file/foo or /file/foo , in a href attributes, img src attributes, video, audio, webcomponents, js ajax calls, etc.

Now here's the thing, when the page gets such URLs I want them to be relative to a single specific and different domain then it's actually on, so say the page is on http://localhost:8081/page/ the browser will translate them to:

• http://localhost:8081/page/../file/foo
• http://localhost:8081/file/foo

But what I really want is for all relative URLs to have no relationship to the domain that their on, but rather be in a relationship with another domain, ex http://localhost:5462/ , and therefor translate to:

• http://localhost:5462/page/../file/foo
• http://localhost:5462/file/foo

In other words: I want a page where the URLs it contains, in a-href, ajax calls, etc, never change no matter where you are viewing the page from (so that the page always fetches the same content from the same source), which works out of the box for complete URLs but not for relative URLs. A way to define and enforce a domain that URLs are relative to so that no matter where the page goes its content and behavior stays the same.

So, what options do I have to solve this and which is the best one? Some ideas:

• Frontend Solutions
  1. The page is generated from markdown, so I can make a plugin for the markdown to html converter that detects domain relative links and convert them to complete urls, but I've yet to experiment to see if it's really that simple, maybe it will miss links on complex markdown components, or a href and img src defined not using markdown but html, or various types of links inside webcomponent elements, etc (also, this isn't a very universal solution and doesn't work with js)
  2. Load the page, then load a js that goes over all the links on the page and converts domain relative links to complete urls with correct domain. This might be better but it doesn't change the relationship at a "fundamental level" so it will miss domain relative links in javascript, such as ajax calls, or URLs added later in the lifetime of the page.
  3. Instead of manipulating the dom I could maybe intercept all http calls, clicks, and requests by using js somehow, check if they are domain relative, and alter the call if necessary (this would brake user facing behavior though, like the preview of where the user will go when hovering a link)
  4. Maybe there exist some kind of a tag like meta with options that I can put in the header of the html that changes the relationship between domain relative links/calls and the domain? I recently discovered the base tag but it seems to only work with HTML elements and not js scripts.
• Backend Solutions
  5. Route localhost:5462 behind localhost:8081 so that all the data from localhost:5462 is accessible at localhost:8081 , this is very clean and plainly just works , even for js http calls, and I will and already use this in allot of cases with zero problems, but sometimes I don't want to use routing and then I'm back to square one. So this is the result that I want, but I need it without routing as well (that the http requests from the frontend don't go through the backend but to the same URLs as on the original or "correct" domain).
  6. Maybe it's possible to inject some kind of domain info in the response object/header/? when requesting the page from the backend which tricks all http requests on the page to use the "correct" domain for domain relative URLs?
• Other Solutions
  7. I could ban the use of domain relative links but I need to support file:/// as well, which needs relative links, and how would I go about banning it in the first place and do I really want to ban a form of links?
• What more solutions are there?

Some things to consider

• This isn't limited to localhost, it could be domain1.com and domain2.com or any combination of domains, or inside an Electron app, etc.
• Ideally when viewing the source code of the page, "live inspecting" it, etc, the links would be unmodified / still look relative, but when you hover a link the indicator of where it goes would show the desired translation of the relative link rather then the default behavior of domain relative links, this "ideal" is definitely not attained with some of my suggested solutions.
• Another ideal would be that all user facing behavior would "just work" but when viewing source code or any developer facing behavior could be funky (the only user facing behavior I can think of is the preview of where you'll go when hovering a link).
• CORS is not an issue.
• It would be great if it worked with any backend setup (a completely frontend solution), but it would also be acceptable if it only works with my particular backend due to technical impossibility or frontend solution being too much of a hack and error prone, or it could require a universally doable modification to any backend.
• My backend is written in Node/Koa.

---

What seems like should be the best solution is something like the base tag but which also works for any arbitrary unmodified javascript, instead of just HTML elements.

But if that doesn't exist maybe it's possible to use the base class just for HTML elements, and in conjunction with that use some very neat and non-hacky javascript that successfully intercepts all possible javascript and webassembly http (or any other protocol) requests and directs them to the correct domain if they are using domain relative URLs? And if that really is the best solution and technically feasible, how would I do it?

Answer 1

After experimenting a bit I've come to the conclusion that HTTP redirects are the best solution, essentially making the backend serve as nothing more but a way to bounce off of to the right URLs. There are some problems with POST requests though which might be possible to fix with frontend javascript modifications, but if it's really a problem it's always possible to switch redirects with "forwards" instead.