Which combination of base-href, deploy-url, and APP_BASE_HREF correctly serves refreshed deep links from a subfolder?
0 reputation · 10 Jan 2024, 23:22 UTC
0 reputation · 10 Jan 2024, 23:22 UTC
An Angular CLI production build is deployed to a subfolder path such as /app/ behind a CDN. The goal is to ensure that a browser refresh on a deep route like /app/dashboard/42 returns index.html from the server (or CDN edge) so the router can boot and navigate, while all generated asset URLs (scripts, styles, images) resolve to the correct CDN origin.
The CLI accepts --base-href, --deploy-url, and the APP_BASE_HREF DI token, but the documentation does not prescribe a single correct combination for this scenario. A mismatch between the <base href> tag written into index.html and the actual request path can cause the router to compute incorrect internal URLs, while an incorrect deploy-url prefixes asset requests with the wrong origin. Server fallback configuration must also match the chosen base path.
Which flag or token combination guarantees that document.baseURI, the router's internal navigation state, and all asset request URLs align with the deployed subfolder when a deep link is refreshed? Does the answer change if the CDN rewrites the request path before it reaches the origin?
The correct combination for deploying an Angular CLI build to a subfolder like /app/, ensuring deep link refreshes work while assets resolve correctly, is using --base-href /app/ and --deploy-url /app/ during the build process. The APP_BASE_HREF injection token should typically remain at its default value of / unless specific route isolation is required.
--base-href /app/ writes <base href="/app/"> into index.html, correctly setting document.baseURI for the router.--deploy-url /app/ ensures all generated asset URLs (scripts, styles) are prefixed with /app/, preventing 404s when served from a subfolder./app/* to index.html to allow the Angular router to bootstrap on a deep link refresh (e.g., /app/dashboard/42).ng build --prod --base-href /app/ --deploy-url /app/.index.html contains <base href="/app/"> and asset paths start with /app/.index.html for all paths under /app/.If the CDN rewrites the request path before reaching the origin (e.g., stripping /app/), the server fallback must be adjusted to handle root paths (/* to index.html), and the CLI flags should align with the resulting path structure, not the deployment folder name.
To confirm the current setup is correct, verify that a refresh on /app/dashboard/42 returns index.html with a 200 status code, and that all asset requests resolve via /app/.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 11 Jan 2024, 06:08 UTC
If your CDN strips the /app prefix before forwarding to the origin (common with CloudFront, Cloudflare Workers, or nginx rewrite), the origin sees requests at / while the browser still uses /app/. In that case, build with --base-href=/ and --deploy-url=/app/. The <base href="/"> tag lets the router compose internal URLs against the root, while deploy-url prefixes every asset request with /app/ so the CDN can serve them. The server fallback at the origin only needs to rewrite /* to /index.html.
Conversely, if the CDN passes the full path through, use --base-href=/app/ and --deploy-url=/app/ so both navigation and assets share the same prefix. APP_BASE_HREF is only a runtime override; it does not change the <base> tag baked into index.html, so prefer the build flags unless you have a dynamic multi-tenant host header scenario.