fix(@angular/ssr): resolve parameters in redirect targets by bschaeublin · Pull Request #34321 · angular/angular-cli

bschaeublin · 2026-10-12T15:39:50Z

PR Checklist

Please check to confirm your PR fulfills the following requirements:

The commit message follows our guidelines: https://github.com/angular/angular-cli/blob/main/CONTRIBUTING.md#-commit-message-guidelines
Tests for the changes have been added (for bug fixes / features)
Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

What is the current behavior?

Parameters in a redirectTo target are sent unchanged in the server's Location header, while the router replaces them:

Route	Request	Server `Location`	Router navigates to
`user/:id` → `profile/:id`	`/user/7`	`/profile/:id`	`/profile/7`
`search/:term` → `/find?q=:x`	`/search/cats?x=dogs`	`/find?q=:x`	`/find?q=dogs`

What is the new behavior?

The server resolves both, one commit each, like the router does:

Route parameters: during route extraction, :name in the redirect path becomes *<n>, the position of that parameter in the request path, which buildPathWithParams resolves at request time. Prerendered routes get the value from getPrerenderParams. Only parameters of the redirecting route's own path can be used; any other :name is reported as an extraction error, matching the router's NG04001.
Query placeholders of absolute redirects: q=:x takes the values of x from the request query, or undefined if it is missing.

Does this PR introduce a breaking change?

Yes
No

Other information

The new extraction error only affects configs that the router already rejects with NG04001. Routes with a custom matcher are left unchanged, since their parameters are only known at runtime.

Closes: #34410

gemini-code-assist

Code Review

This pull request enhances Angular SSR's redirect handling by resolving route and query parameter placeholders in redirect targets, aligning its behavior with the Angular router. It introduces buildQueryWithParams to resolve query placeholders, supports positional placeholders (*) in buildPathWithParams, and adds corresponding unit tests. The review feedback highlights a potential runtime error in buildPathWithParams when positional placeholder indices are out of bounds, suggesting a fallback to empty strings. Additionally, it recommends using .startsWith(':') instead of direct index access [0] in both replaceRedirectParams and buildQueryWithParams to safely handle empty strings.

gemini-code-assist · 2026-10-12T15:42:45Z

  const resolvedParts = toPathParts.map((part, index) =>
-    toPathParts[index] === '*' ? fromPathParts[index] : part,
+    part === '*'
+      ? fromPathParts[index]
+      : part.replace(POSITIONAL_PLACEHOLDER_REGEXP, (_, position) => fromPathParts[position]),
  );


If fromPath has fewer segments than toPath, or if the positional placeholder index is out of bounds, fromPathParts[index] or fromPathParts[position] will be undefined. This will cause joinUrlParts to throw a TypeError when accessing part.length on the undefined value, or result in the string 'undefined' being inserted into the path. Adding a fallback to an empty string prevents these runtime errors.

Suggested change

const resolvedParts = toPathParts.map((part, index) =>

toPathParts[index] === '*' ? fromPathParts[index] : part,

part === '*'

? fromPathParts[index]

: part.replace(POSITIONAL_PLACEHOLDER_REGEXP, (_, position) => fromPathParts[position]),

);

const resolvedParts = toPathParts.map((part, index) =>

part === '*'

? (fromPathParts[index] ?? '')

: part.replace(POSITIONAL_PLACEHOLDER_REGEXP, (_, position) => fromPathParts[position] ?? ''),

);

Not reachable: each */*<n> placeholder is derived from the position of a parameter in the matched route, and the route tree only matches when the request has a segment at each of those positions.

alan-agius4

Thanks for working on this! I left a few comments where the behavior diverges from @angular/router or introduces extra behavior.

alan-agius4 · 2026-10-20T07:21:44Z

+      const fullRoute = joinUrlParts(baseHref, route);
+
      if (metadata.redirectTo !== undefined) {
-        metadata.redirectTo = joinUrlParts(baseHref, metadata.redirectTo);
+        // Reference the route parameters by their position in the URL (see `buildPathWithParams`).
+        const routeSegments = fullRoute.split('/');
+        metadata.redirectTo = replaceRedirectParams(
+          joinUrlParts(baseHref, metadata.redirectTo),
+          (parameter) => {
+            const position = routeSegments.lastIndexOf(parameter);
+
+            return position === -1 ? undefined : `*${position}`;
+          },
+        );
      }


Doing this in extractRoutesAndCreateRouteTree against fullRoute (and in handleSSGRoute against params) differs from @angular/router in a few ways:

Parent route parameters: In @angular/router (Recognizer.expandSegmentAgainstRouteUsingRedirect), positionalParamSegments (posParams) only contains parameters from the redirecting route's own path, not ancestor routes (parentRoute). Resolving against fullRoute (or all params in handleSSGRoute) allows redirectTo on a child route to reference :param from a parent route, whereas the client router throws NG04001: Cannot redirect to '...'. Cannot find ':param'.

Double replacement for SSG routes: Prerendered routes already run replaceRedirectParams inside handleSSGRoute, and then run through replaceRedirectParams a second time here (which would re-process any prerender parameter value that happens to start with :). Conversely, getRoutesFromAngularRouterConfig (which is exported) returns unresolved :param in redirectTo for non-prerendered routes.

Unknown parameters: When redirectTo contains a :param not present in the route's own path, @angular/router throws NG04001 (Cannot redirect to '${redirectTo}'. Cannot find '${redirectToUrlSegment.path}'.), whereas replaceRedirectParams silently keeps :param as a literal segment.

Can we resolve redirectTo parameters inside handleRoute / handleSSGRoute where route.path and parentRoute are still distinct, only matching parameters defined in route.path and reporting an extraction error when a :param in redirectTo is not found in route.path?

Done. redirectTo parameters are now resolved in handleRoute/handleSSGRoute against the redirecting route's own path only, so getRoutesFromAngularRouterConfig returns them resolved and extract() no longer touches them. A :param that is not in the route's own path (including parent parameters) now reports the router's error: Cannot redirect to '…'. Cannot find ':param'.

One exception: routes with a custom matcher are left as is, since their positional parameters are only known at runtime and an error would reject a valid config.

alan-agius4 · 2026-10-20T07:21:45Z

  const fromPathParts = fromPath.split('/');
  const toPathParts = toPath.split('/');
  const resolvedParts = toPathParts.map((part, index) =>
-    toPathParts[index] === '*' ? fromPathParts[index] : part,
+    part === '*'
+      ? fromPathParts[index]
+      : part.replace(POSITIONAL_PLACEHOLDER_REGEXP, (_, position) => fromPathParts[position]),
  );

  return joinUrlParts(...resolvedParts);


Because toPath can include a query string or fragment (for absolute redirects), calling toPath.split('/') and joinUrlParts(...resolvedParts) on the entire string will also split the query/fragment on /.

For example, /user/*1?returnTo=/a//b/ would have its query string split into parts, // collapsed, and trailing / stripped by joinUrlParts (and any /*<n> in the query/fragment replaced).

We should split off the query/fragment before splitting the path on / (similar to replaceRedirectParams), resolve the path segments, and then re-attach the suffix. That also removes the need for (?=[?#]|$) in POSITIONAL_PLACEHOLDER_REGEXP.

Good catch, fixed. buildPathWithParams now splits off the query/fragment first, only resolves the path segments and re-attaches the suffix unchanged. The lookahead in POSITIONAL_PLACEHOLDER_REGEXP is gone.

alan-agius4 · 2026-10-20T07:21:45Z

+export function buildQueryWithParams(toUrl: string, fromParams: URLSearchParams): string {
+  const [, path, query, fragment] = /^([^?#]*)\?([^#]*)(.*)$/.exec(toUrl) ?? [];
+  if (query === undefined || !query.includes('=:')) {
+    return toUrl;
+  }
+
+  const resolvedParams = new URLSearchParams();
+  for (const [name, value] of new URLSearchParams(query)) {
+    if (value[0] === ':') {
+      for (const sourceValue of fromParams.getAll(value.slice(1))) {
+        resolvedParams.append(name, sourceValue);
+      }
+    } else {
+      resolvedParams.append(name, value);
+    }
+  }
+
+  const resolvedQuery = resolvedParams.toString();
+
+  return path + (resolvedQuery ? `?${resolvedQuery}` : '') + fragment;
+}


There are a few behavioral differences here compared to @angular/router's ApplyRedirects.createQueryParams:

Repeated target query keys (?q=:a&q=:b): In @angular/router, DefaultUrlSerializer.parse groups repeated keys into an array ([':a', ':b']), and createQueryParams checks typeof v === 'string' && v[0] === ':', so repeated keys are not resolved as placeholders. Iterating over URLSearchParams entries resolves each occurrence individually.

Missing source query parameter (?q=:missing): In @angular/router, res[k] = actualParams[sourceName] assigns undefined, which serializes as q=undefined, whereas fromParams.getAll(...) omits q completely.

Query string re-encoding: URLSearchParams.toString() uses application/x-www-form-urlencoded encoding (e.g. spaces become +, and :, @, $, ,, ; are percent-encoded), whereas Angular Router's DefaultUrlSerializer encodes spaces as %20 and preserves @, :, $, ,, ;. Also, !query.includes('=:') will false-positive if a static query value contains =: mid-value (e.g. ?filter=a=:b), re-encoding the entire query string unnecessarily.

Done:

Placeholders of repeated target keys are no longer resolved.

A missing source parameter results in undefined.

Only the name=:x pairs are replaced; everything else stays as written. Resolved values are encoded like DefaultUrlSerializer (%20 for spaces, @ : $ , ; kept).

Static values are kept as written, following your note that re-encoding the entire query is unnecessary. The router itself would normalize them too (e.g. ?a=b+c becomes a=b%20c), so let me know if you'd rather have full parity there.

alan-agius4 · 2026-10-20T07:21:45Z

+      it('should resolve query parameters in absolute redirect targets', async () => {
+        const response = await app.handle(
+          new Request('http://localhost/redirect-query-placeholder?term=cats&term=dogs'),
+        );
+        expect(response?.headers.get('location')).toBe('/home?q=cats&q=dogs&static=value');
+        expect(response?.status).toBe(302);
+      });


Note that with @angular/router, id=:missing when missing is not in the request query string produces id=undefined (/home?q=cats&q=dogs&id=undefined&static=value) rather than omitting id.

Updated, the test now expects /home?q=cats&q=dogs&id=undefined&static=value.

Route parameters in the path of a `redirectTo` target, such as `:id` in `profile/:id`, were sent unchanged in the `Location` header by the server, while the router replaces them with the matching parameters of the current URL. The server now does the same.

…argets Query parameters of an absolute `redirectTo` target whose value is a placeholder, such as `q=:term`, were sent unchanged in the `Location` header by the server, while the router replaces them with the values of the matching query parameters of the current URL. The server now does the same. Query parameters whose source parameter is missing in the current URL are left out, which matches the `undefined` value that the router assigns to them.

…irect targets

angular-robot Bot added the area: @angular/ssr label Oct 12, 2026

gemini-code-assist Bot reviewed Oct 12, 2026

View reviewed changes

alan-agius4 self-requested a review October 19, 2026 19:43

alan-agius4 added the action: review The PR is still awaiting reviews from at least one requested reviewer label Oct 19, 2026

alan-agius4 mentioned this pull request Oct 20, 2026

fix(@angular/ssr): substitute route parameters used in redirectTo #34411

Closed

alan-agius4 requested changes Oct 20, 2026

View reviewed changes

bschaeublin added 4 commits October 20, 2026 18:55

fixup! fix(@angular/ssr): resolve route parameters in redirect targets

4df24ec

fixup! fix(@angular/ssr): resolve query parameter placeholders in red…

1281fa8

…irect targets

bschaeublin force-pushed the fix/ssr-redirect-target-params branch 2 times, most recently from 7661712 to 1281fa8 Compare October 20, 2026 17:21

bschaeublin requested a review from alan-agius4 October 20, 2026 17:26

alan-agius4 added action: review The PR is still awaiting reviews from at least one requested reviewer and removed action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews labels Oct 20, 2026

Navigation Menu

Repository navigation

fix(@angular/ssr): resolve parameters in redirect targets - #34321

fix(@angular/ssr): resolve parameters in redirect targets#34321
bschaeublin wants to merge 4 commits into
angular:mainfrom
bschaeublin:fix/ssr-redirect-target-params

bschaeublin commented Oct 12, 2026 •

edited

Loading

Uh oh!

gemini-code-assist Bot left a comment

Uh oh!

gemini-code-assist Bot Oct 12, 2026

Uh oh!

bschaeublin Oct 12, 2026

Uh oh!

Uh oh!

Uh oh!

alan-agius4 left a comment

Uh oh!

alan-agius4 Oct 20, 2026

Uh oh!

bschaeublin Oct 20, 2026

Uh oh!

alan-agius4 Oct 20, 2026

Uh oh!

bschaeublin Oct 20, 2026

Uh oh!

alan-agius4 Oct 20, 2026

Uh oh!

bschaeublin Oct 20, 2026

Uh oh!

alan-agius4 Oct 20, 2026

Uh oh!

bschaeublin Oct 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

bschaeublin commented Oct 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Checklist

PR Type

What is the current behavior?

What is the new behavior?

Does this PR introduce a breaking change?

Other information

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist Bot Oct 12, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

alan-agius4 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

bschaeublin commented Oct 12, 2026 •

edited

Loading