GeezerVison

Code Review

This pull request introduces HTML escaping for redirect URLs in static pages to prevent HTML injection vulnerabilities. It adds an escapeHtml utility and updates the generateRedirectStaticPage function to apply this escaping to both the meta refresh tag and the fallback link. Additionally, E2E tests have been included to verify the fix. The reviewer pointed out that while HTML escaping prevents tag injection, it does not protect against malicious URI schemes like javascript:, and recommended adding protocol validation for the redirect URL.

I have reservations about this change.

It assumes the attacker can already modify the source code on your machine or alter the database if the routes are built dynamically. If an attacker already has that level of access, they could inflict far worse damage anyway.

[Gemini Review]: Thanks for working on this! Securing the static redirect HTML generation and fixing the ESM manifest syntax errors with JSON.stringify are great fixes.

However, there are several architectural and DX issues with the current implementation that need to be addressed before we can merge:

1. DX Breaking Change in getPrerenderParams: Rejecting characters like ', ", and spaces on individual parameter values will break existing applications prerendering slugs like { id: "customer's-choice" } or search terms with spaces. In fact, RouteTree.getPathSegments() already calls .map(decodeURIComponent), so percent-encoded values like %27 get immediately decoded back anyway. Instead of validating isolated parameter segments in handlePrerenderParamsReplacement, we should validate and normalize the entire generated route path (routeWithResolvedParams) using the WHATWG new URL parser. This allows legitimate apostrophes to work naturally while automatically percent-encoding spaces and <script> tags into %20 and %3Cscript%3E.
2. Move Redirect Validation to Route Extraction: validateExtractedStaticRedirect is currently placed in prerender.ts in @angular/build. This is too late in the pipeline and misses runtime redirects produced by guards in render-worker.ts. All redirect validation and normalization (redirectTo) should happen upfront during route discovery in @angular/ssr (ng-routes.ts).
3. Eliminate Duplication & Leverage Web Standards: hasUnsafeStaticRedirectCharacters in @angular/build and hasUnsafeUrlCharacters in @angular/ssr duplicate nearly identical regexes and character loops. We can replace these with a unified WHATWG new URL check in @angular/ssr.
4. Clean Up Fragmented Error Messages: Error strings are currently spliced across prerender.ts/ng-routes.ts, utils.ts, and redirect.ts. Centralizing validation in ng-routes.ts allows emitting clean, cohesive error messages.
5. E2E vs Unit Tests: The 3 negative build failure assertions in server-routes-output-mode-static.ts add 3 full CLI builds to CI (~15–30s). These negative validation cases belong in fast in-memory unit tests in ng-routes_spec.ts.

See inline comments for details on each file.

Thanks for working on this.

This PR currently bundles two unrelated changes together:

1. Escaping redirect URLs in generateRedirectStaticPage (packages/angular/build/src/utils/server-rendering/utils.ts).
2. Serializing server manifest asset paths and hashing asset chunk filenames (packages/angular/build/src/utils/server-rendering/manifest.ts).

Could you please split the manifest.ts changes (manifest.ts, manifest_spec.ts, and server-routes-output-mode-server.ts) into a separate PR so we can land that independently? (Also please remove Fixes #34474 from the commit messages as that issue does not exist.)

For the redirect changes in this PR, the @angular/build changes (utils.ts, utils_spec.ts, and server-routes-output-mode-static.ts) look great, but the URL normalization and redirect validation changes in @angular/ssr (redirect.ts and ng-routes.ts) are overly complex and have a few issues:

1. normalizeAndValidateRedirect is only called from resolveRedirectTo, where the path always starts with / (either redirectTo[0] === '/' or the result of joinUrlParts). Because of that, branches like URL.canParse(target) and ALLOWED_REDIRECT_PROTOCOLS are unreachable, and protocol relative paths (//...) are already collapsed to a single leading / by joinUrlParts in extractRoutesAndCreateRouteTree and app.ts.
2. In normalizeAndValidateRoutePath, running new URL() percent encodes prerendered route paths (for example /produits/café becomes /produits/caf%C3%A9), which is why routeDeduplicationKey had to be added to decode segments again for seenRoutes, and RouteTree.insert immediately runs decodeURIComponent on every segment anyway.
3. Validating the composed route path instead of validating parameter values in handlePrerenderParamsReplacement allows a :param to contain / on nested routes like store/:slug (turning { slug: 'a/b' } into /store/a/b), while rejecting { slug: 'a%2Fb' }.

Please revert the @angular/ssr changes (redirect.ts, redirect_spec.ts, ng-routes.ts, and ng-routes_spec.ts) in this PR so that this PR only contains the generateRedirectStaticPage HTML escaping fix in @angular/build. If we still want parameter validation in handlePrerenderParamsReplacement, we can do that in a separate follow up PR once #34467 lands.

Code Review

This pull request introduces HTML escaping for URLs interpolated into static redirect pages (such as meta refresh tags and fallback links) to prevent potential injection vulnerabilities, along with corresponding unit and E2E tests. The review feedback suggests adding a defensive check within the escapeHtml function to gracefully handle non-string or falsy values and prevent potential runtime crashes.

LGTM