The app should be URL-agnostic, for the simple reason that it is not unusual:
A web page contains three types of URLs:
URLs relative to the actual page.
URLs relative to the root, that is the domain name.
An application which is hosted at https://example.com/app1 can point to a relative URL such as
<link href="main.css"> which would lead to https://example.com/app1/main.css, to URLs relative to the root, such as
<a href="/"> which would lead to https://example.com/, and to absolute URLs such as
In all three cases, the actual location of the application doesn't matter: it can be hosted as https://example.com/app1, https://app1.example.com, https://cdn.example.com/oregon/app1/, etc. As soon as the resources relative to the page stay within the app, and the resources relative to the root stay at the root, the app will work.
The problem, however, is when you start using URLs relative to the root in the cases where they are not expected—and this is exactly the situation with static resources. There are two types of static resources:
Common static resources can be used by multiple applications.
In this case, you'd better put them in a CDN and reference them through an absolute URL such as https://s.example.com/something/here/global.css. It doesn't matter if it is a public CDN such as Amazon CloudFront, or something your company hosts and which may not even be technically a CDN; the only thing that matters is that URLs would be absolute, which gives you the flexibility of being able to use them independently of the actual URL of the application.
Application-oriented resources are used exclusively by the application. They are never shared with other web apps.
Here, you can still move them to a CDN (if it's an actual CDN, it will also give you the benefit of better performance and lower impact on your app servers).
If, however, you decide to keep them together with the app (for instance because your favorite framework does the minification and the bundling on the fly), then use URLs relative to the actual page, not the domain. This way, you'll know that it will work no matter how you access your app, would it be https://example.com/, https://app1.example.com/, https://example.com/app1 or https://18.104.22.168/.
For the rare cases where CDN is overly complex to use, and the static resources are shared among several apps, you may solve the problem with a simple URL rewriting. When a page hosted at https://example.com/app1/index.html will point to https://example.com/app1/main.css, the URI will be redirected automatically to, for instance, https://example.com/static/main.css.
Note that accessing the same static resource through multiple URIs won't do any good to client-side caching, so URL rewriting should be reserved only to cases where CDN is actually difficult to use. Another solution is to use redirects. Here, you get the benefits of client-side caching, at the cost of an extra HTTP request.