I referenced all assets in the html with ../img/
, ../css/
, ../js/
paths.
These are client-side URL-paths; not server-side filesystem-paths. If the browser is currently at https://subdomain.example.com/
then a URL such as ../img/myimage.jpg
cannot be resolved as intended from a client-side request. Since the browser cannot "go up" another directory (or rather URL path-segment) level - since it is already at the document root - it will most probably be resolved as https://subdomain.example.com/img/myimage.jpg
- which presumably fails (404).
The same as typing https://subdomain.example.com/../img/myimage.jpg
directly in the browser. The ../
path segment needs to be resolved by the browser before the request can be made.
You are probably better off not using relative URL-paths during development (unless you have specific requirements). Use a root-relative URL-path (starting with a slash) or absolute URL (with scheme + hostname) instead.
You need to rethink your directory structure. What exactly are you trying to achieve? A common repository for all assets or a way to reference assets on the main domain, without explicitly specifying an absolute URL.
There are various workarounds:
Use absolute URL-paths to your main domain. eg.
https://example.com/img/myimage.jpg
Point the subdomain at the same root directory as your main domain and use a root-relative URL-path. eg.
/img/myimage.jpg
.
Point the subdomain at the same root directory as the main domain and use mod_rewrite to internally rewrite requests for pages to the subdirectory (so the subdirectory is hidden from the URL). But all (or some?) static assets to be served from the parent directory (and are not rewritten)? Reference assets using a root-relative URL-path, relative to the main domain. (Or specify a prefix and make the rewrite conditional?) Although this method is naturally far more complex and requires knowledge of conditional URL-rewriting (probably best avoided).
etc.