Unescape relative path before file lookup to fix space-in-filename issue#62349
Unescape relative path before file lookup to fix space-in-filename issue#62349jacob-l wants to merge 2 commits intodotnet:mainfrom
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 *
| { | ||
| 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".
|
Looks like this PR hasn't been active for some time and the codebase could have been changed in the meantime. |
dotnet-policy-service
Bot
added
the
pending-ci-rerun
| { | ||
| var relativePath = _appBaseUri.MakeRelativeUri(fileUri).ToString(); | ||
|
|
||
| relativePath = Uri.UnescapeDataString(relativePath); |
There was a problem hiding this comment.
I don't think this is the right place to do this. If we are going to do something like this, we should to it to the entire URL and do it before the _appBaseUri.IsBaseOf call. I think the same concerns that we have in Kestrel apply here with regards to certain charcters like /
5 participants
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.