Unescape relative path before file lookup to fix space-in-filename issue #62349
Conversation
The relative path was URL-encoded, which caused file lookups to fail for paths containing spaces or other special characters. Unescaping the path resolves the issue.
dotnet-policy-service
bot
added
the
community-contribution
|
Thanks for your PR, @@jacob-l. Someone from the team will get assigned to your PR shortly and we'll get it reviewed. |
|
@jacob-l thank you for your contribution. Could you, please add a test in https://github.com/dotnet/aspnetcore/blob/main/src/Components/WebView/WebView/test/StaticContentProviderTests.cs that would demonstrate the encoding failure you're describing? |
This test verifies that TryGetResponseContent can handle file paths containing whitespaces and serves the expected content, ensuring the URL-encoding fix works as intended.
|
@dotnet-policy-service agree |
|
Thanks for your feedback and approval, @ilonatommy |
|
We also need security review, as unescaping has security implications. |
javiercn
added
the
* NO MERGE *
| @@ -27,6 +27,8 @@ public bool TryGetResponseContent(string requestUri, bool allowFallbackOnHostPag | |||
| { | |||
| var relativePath = _appBaseUri.MakeRelativeUri(fileUri).ToString(); | |||
|
|
|||
| relativePath = Uri.UnescapeDataString(relativePath); | |||
There was a problem hiding this comment.
If the relative path intentionally contains encoded parts, ie. %2F, this is going to decode that to a / and the file won't be found/served?
There was a problem hiding this comment.
Thank you for the question, @ladeak !
If the file with %2F is in the file provider, for example, "folder%2Ffile.txt", then I expect the requestUri in the method TryGetResponseContent to be like this: "https://test.domain/folder%252Ffile.txt".
In this case, the relative path before unescaping is "folder%252Ffile.txt", and after unescaping it becomes "folder%2Ffile.txt".
Summary
When serving files, if the requested path contains spaces or other special characters, the lookup fails because
Uri.MakeRelativeUrireturns a URL-encoded path (e.g. spaces become%20). The file provider expects a plain file path, not a URL-encoded one.This PR adds a call to
Uri.UnescapeDataStringafterMakeRelativeUri, ensuring the relative path is correctly unescaped before being used to retrieve files.