Content collection route does not URL-decode path segments — files/folders with spaces (or other encoded characters) return "not found"

[sierragolflima]

Summary

When browsing a content collection in the portal, clicking a file or folder whose name contains a space (or any other character the browser percent-encodes) produces a "not found" error. The collection browser lists such items correctly, but opening them fails.

How to reproduce

1. On any node that has a content collection (for example the default content collection), add a file whose name contains a space, such as my report.md. A folder with a space in its name, such as Data Extraction, reproduces the same way.
2. Open the collection browser in the portal at /{node}/content. The item my report.md (or the Data Extraction folder) is listed correctly, with its space intact.
3. Click the item. The browser navigates to /{node}/content/my%20report.md (the space percent-encoded as %20).
4. Observe the error instead of the file content or folder listing.

Actual behavior

The page renders:

'my%20report.md' not found in collection 'content'.

Note the literal %20 in the message — the encoded form is compared directly against the collection's real item names.

Expected behavior

The file renders (or the folder opens) as it does for items whose names contain no encoded characters. Percent-encoded URL segments are decoded before they are matched against the collection's stored item names.

Root cause

The content-collection layout areas take the path from the raw URL id (host.Reference.Id) and use it as a collection path without URL-decoding it. The stored item name contains a real space (my report.md), while the path from the URL contains my%20report.md, so the case-insensitive equality match never succeeds and the fallback "not found" branch is returned.

The only decodes in the resolution chain are WorkspaceReference.Decode (which reverses the custom %9Y→. escaping, not percent-encoding) and query-string parsing — neither touches %20 in the path. The shared file renderer ContentLayoutArea.RenderFile re-encodes the path with Uri.EscapeDataString when it builds the static URL, which confirms the internal contract expects an already-decoded path; the callers violate that contract.

This is not related to nesting depth. It occurs whenever any path segment contains a character the browser percent-encodes; names without such characters resolve correctly, which is why most navigation works.

Affected code

• src/MeshWeaver.ContentCollections/CollectionNamedLayoutArea.cs — RenderCore, where path is derived from host.Reference.Id and matched against item.Path.
• src/MeshWeaver.ContentCollections/ContentLayoutArea.cs — UnifiedContentCore, which reads host.Reference.Id raw for the unified $Content path.

Suggested fix

URL-decode each path segment (Uri.UnescapeDataString, splitting on / first so separators are preserved) at both boundaries where the URL id becomes a content-collection path, before it is matched against the provider's item names.

[rosalie1984]

This is essential also for the memex.systemorph.com where we now start to work collaboratively and need to upload existing files

Description

When a file is uploaded, the resulting path reference uses a URL-encoded filename (e.g., USH%20RFP%20-%20current_process_analysis%201.docx) instead of the decoded filename. This causes errors when the content collection is later accessed, because the encoded path doesn't match the actual stored file.

Steps to reproduce

1. Upload a .docx file with spaces in its name (e.g., USH RFP - current_process_analysis 1.docx)
2. The resulting path stored is USH%20RFP%20-%20current_process_analysis%201.docx
3. Attempting to retrieve the file from the content collection fails with:

   'USH%20RFP%20-%20current_process_analysis%201.docx' not found in collection 'content'

Expected behavior

Uploaded file paths should use the decoded filename so that lookups into the content collection work correctly. Either:

• Store the decoded path from the start, or
• URL-decode the path before performing the collection lookup.

Impact

Any file with a space (and likely other characters that get percent-encoded) in its name becomes inaccessible after upload.

[rbuergi]

Fix opened as #375 (branch fix/content-collection-url-decode).

Root cause confirmed exactly as reported: the content-collection layout areas matched the raw URL id against the collection's stored item names without URL-decoding it, so a percent-encoded segment (my%20report.md) never matched the real name (my report.md).

Fix: decode each path segment (Uri.UnescapeDataString, split on / first) at both boundaries — CollectionNamedLayoutArea.RenderCore and ContentLayoutArea.UnifiedContentCore — via a new DecodeCollectionPath helper (the inverse of the Uri.EscapeDataString re-encoding RenderFile/RenderPdf already do). Regression test renders a spaced folder+file through their encoded ids; it fails with the exact "not found" symptom when the decode is removed.

This will auto-close on merge and resolves the issue on both memex and atioz once their images self-update from main.

[sierragolflima]

Related instance of the same root cause — the lookup also fails on Unicode normalization, not just percent-encoding.

A file uploaded from macOS arrives with its filename in NFD (decomposed) form — e.g. ä stored as a + U+0308 (combining diaeresis). The content-collection file lookup (FileSystemStreamProvider / blob provider: Path.Combine(basePath, filePath) → open by exact string; there is no Normalize call anywhere in the content providers) then cannot match a request whose ä is NFC (precomposed, U+00E4) — the two are different byte sequences, and on a byte-exact store (Linux fs / blob) the lookup returns "not found".

Notably, indexing still succeeds — the indexer walks the directory and reads the NFD name verbatim, so the file is present and fully chunked. Only the by-name Get fails, when a downstream consumer reconstructs the filename in NFC (from a user message, a URL, or a slug).

Observed impact: a consumer that needs the whole file (rather than chunks) cannot read it, falls back to fragmentary/snippet reads, and can loop expensively with no result.

Suggested fix (extends this issue to full path canonicalization)

Canonicalize the path once, before the lookup, in both directions:

1. URL-decode the segments (this issue), and
2. Normalize(NormalizationForm.FormC) the decoded path.

And normalize filenames to NFC at upload/save time so the stored keys are canonical to begin with. A single "canonicalize the path" step then covers spaces, percent-encoding, and NFD/NFC uniformly.