Route parameter with urlencoded slash. Inconsistency beetween TestServer and Kestrel behavior.
See original GitHub issueDescribe the bug
Having a route parameter that includes a urlencoded /
character produces inconsistent results between TestServer and Kestrel behavior.
Route: /api/{itemId}
Client requests: /api/foo%2Fbar
Kestrel: As expected matches the controller action. TestServer: Produces a HTTP 404 Not Found.
To Reproduce
https://github.com/mcrio/AspNet5TestServerSlashTest
Further technical details
net5.0
.NET SDK (reflecting any global.json): Version: 5.0.100 Commit: 5044b93829
Runtime Environment: OS Name: Mac OS X OS Version: 10.15 OS Platform: Darwin RID: osx.10.15-x64 Base Path: /usr/local/share/dotnet/sdk/5.0.100/
Host (useful for support): Version: 5.0.0 Commit: cf258a14b7
Issue Analytics
- State:
- Created 3 years ago
- Comments:17 (12 by maintainers)
Top Results From Across the Web
asp.net core controller action route uses encoded slash to ...
You can use an asterisk to indicate that searchterm can contain slashes. This is called a catch-all parameter, and looks like this:
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Ok, so SafeUnescaped is not what we need. Unescaped is pretty close except for
%2f
and%2e
.The
%2e
difference might actually be an issue in UrlDecoder rather than URI. In https://datatracker.ietf.org/doc/html/rfc3986/#section-5.2.4 it calls out/.
and/./
as a special case where the segment should be removed. UrlDecoder handles the other special navigation case for/..
and/../
but not the single dot case. I’ll file a separate issue for that. Edit Nevermind, RemoveDotSegments is a separate step done by the server after decoding. We’ll revisit that if it becomes an issue. https://github.com/dotnet/aspnetcore/blob/52eff90fbcfca39b7eb58baad597df6a99a542b0/src/Servers/Kestrel/Core/src/Internal/Http/PathNormalizer.cs#L36Yes, try using UrlDecoder in PathString. When working with the Uri overload of FromUriComponent you’ll want to start with SafeUnescaped and then apply the UrlDecoder.
Resolving that ambiguity is probably the best path forward.
Can you do a thorough comparison please? E.g. for a fully escaped input sequence of ascii bytes %00-%7F, what’s the current behavior of PathString.FromUriComponent (TestServer), UriFormat.SafeUnescaped, and Kestrel. Include the test setup code if possible.