Regex-style API endpoint route does not match requests, while equivalent documented :variable routes work

[RubenT91]

Description of Issue

A customer upgrade investigation isolated an API routing issue where an endpoint defined with a regex-style URL pattern is accepted/registered, but incoming requests do not match that endpoint at runtime. In the affected environment, requests fall through to the catch-all route and then enter the sign-in flow instead of executing the intended endpoint.

This behavior appears distinct from separate module-loading and cmdlet-auth-mode findings in the same case and should be tracked independently as an API routing defect.

Observed behavior:

• A standard documented route using :variable syntax works.
• A regex-style route intended to support one required path segment plus one optional numeric segment does not match.
• In customer logs, requests to the regex-style path matched /{*path} instead of the intended endpoint and were redirected into sign-in.
• In local lab validation, equivalent regex-style route probes returned 404, while standard :variable routes returned 200 in the same PSU instance.

Minimal reproduction:

1. Create a standard endpoint using documented variable syntax:

New-PSUEndpoint `
  -Url "/api/SampleEndpoint/:ResourceId" `
  -Method @("GET") `
  -Path ".\sample-standard.ps1"

2. Create a second standard endpoint with two path segments:

New-PSUEndpoint `
  -Url "/api/SampleEndpoint/:ActionType/:ResourceId" `
  -Method @("GET") `
  -Path ".\sample-standard-two-segments.ps1"

3. Create a regex-style endpoint intended to allow one required segment and one optional numeric segment:

New-PSUEndpoint `
  -Url "/api/v1/SampleEndpoint/(?<ActionType>[A-Za-z0-9]+)/?(?<ResourceId>[0-9]+)?" `
  -Method @("GET") `
  -Path ".\sample-regex.ps1"

4. Test requests:

Invoke-RestMethod -Uri "https://server/api/SampleEndpoint/ExampleValue"
Invoke-RestMethod -Uri "https://server/api/SampleEndpoint/OptionA/123"
Invoke-RestMethod -Uri "https://server/api/v1/SampleEndpoint/OptionA"
Invoke-RestMethod -Uri "https://server/api/v1/SampleEndpoint/OptionA/123"

Actual result:

• Standard :variable routes work.
• Regex-style route requests do not match the intended endpoint.
• Customer-side evidence shows those requests falling through to /{*path} and then redirecting to sign-in.
• Lab-side evidence shows regex-style route requests returning 404 while standard routes succeed.

log excerpt from customer-side behavior:

Request path '/api/v1/SampleEndpoint/OptionA/123'
1 candidate(s) found for the request path
Endpoint '/' with route pattern '/{*path}' is valid for the request path
Request matched endpoint '/'
AuthenticationScheme: Cookies was challenged
Request finished ... 302
Request starting ... /api/v1/signin/windows?returnUrl=/api/v1/SampleEndpoint/OptionA/123

Additional notes:

• The customer confirmed that a separate endpoint using documented :variable syntax works in the same environment.

• A local support lab reproduced the route split behavior on a separate PSU instance:

  • Standard :variable routes -> 200
  • Regex-style route probes -> 404

• The exact version boundary was not fully established because intermediate installers/packages were not available locally for full matrix testing.

Version

2026.1.2 - 2026.1.5

Severity

High

Hosting Method

IIS

Operating System

Windows

Database

SQLite

Licensed

Yes

Features

API Endpoints

Additional Environment data

No response

Screenshots/Animations

No response