[7.0] Match strangely formatted PathBase in HttpSys & IIS #42751

[Tratcher]

There are unusual situations where Http.Sys, IIS, and AspNetCore disagree on the format of the root path of the site.

Forward port of #44753, already servicing-approved.

Description

Http.Sys and IIS support path based routing of requests between sites that are sharing the same port. It applies this matching using the normalized path (e.g. decoded, dot segments removed, etc.). The problem is that Http.Sys does some non-standard normalizations that AspNetCore doesn't like collapsing consecutive slashes, converting backslashes to forward slashes, decoding %2F, etc., so when we try to separate the PathBase later it might not match and the path gets split in the wrong place, causing errors and routing mismatches up stack.

Note there's no defined behavior for most of these unusual path constructions, they are usually mistakes made by the client when constructing the url such as consecutive slashes, backslashes, etc.. AspNetCore does less auto-correction for such mistakes, but an app can usually fix these up in middleware if it wants. This bug was worse for HttpSys because the requests failed before reaching middleware due to a malformed path after an incorrect split.

I've added extra processing to the PathBase logic to emulate Http.Sys's behaviors. E.g. /base will now match //\/%2F%5Cbase like Http.Sys does. The original PathBase //\/%2F%5Cbase will still be included in the request, but the remaining Path will be properly separated now. There's one test case (not reported by any customer) I wasn't able to fix which includes consecutive slashes and dot segments, Http.Sys collapses consecutive slashes before dot segments, but we are applying this fallback after dot segments have been removed. This case gracefully falls back to reporting no PathBase.

I have not included an app context switch since the prior behavior would fail valid requests, and I make sure to apply the old standard matching first before trying the new approach.

I did not implement this additional logic on the TryMatchLongestPrefix code path that's primarily used in delegation scenarios. That code path already gracefully falls back to reporting no PathBase when it can't match.

Contributes to #42751

Customer Impact

This was reported externally first, but then a patch was requested to unblock an internal partner's .NET 6 adoption. A limited workaround is available in the issue.

Regression?

• Yes
• No

Risk

• High
• Medium
• Low

Using PathBase's with unusual formats is rare enough that this is the first customer to notice.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

[ghost]

Hi @Tratcher. This PR was just approved to be included in the upcoming servicing release. Somebody from the @dotnet/aspnet-build team will get it merged when the branches are open. Until then, please make sure all the CI checks pass and the PR is reviewed.

[Tratcher]

/backport to main

[github-actions]

Started backporting to main: https://github.com/dotnet/aspnetcore/actions/runs/3440614035

[Tratcher]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[Tratcher]

#45091 should fix the linux build

[wtgodbe]

Merging to get past the restore failure