[Static web assets] Fix casing issues during parsing #35564
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
javiercn
commented
Aug 20, 2021
Pilchie
added
the
area-mvc
javiercn
force-pushed
the
javiercn/static-web-assets-casing-fix
branch
from
9c6f684 to
1790035
Compare
SteveSandersonMS
approved these changes
Sep 7, 2021
|
/backport to release/6.0 |
|
Started backporting to release/6.0: https://github.com/dotnet/aspnetcore/actions/runs/1210072872 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #35328
Static web assets generates a manifest that creates a "virtual file system" that maps content from different folders/locations into the app. That manifest is built as a tree that we parse at runtime and use to map the different file requests to the underlying files.
Each node of the tree represents a folder/file in the path of the "file system". The issue is that when we generate he manifest, we need to preserve all the details about the casing because we don't know the final environment where the app is going to run (for example, within WSL or Docker, where the build has happened on Windows, (this is how tooling works))
This produces the problem that we have a manifest with multiple entries that are case insensitive, and that when we try to parse on windows, nodes that only differ on casing need to be "merged" into a single node.
This doesn't create ambiguity because we already have a process that validates at build time that we don't produce a manifest where more than one asset can target a given request path