Content-collection file serving fails for paths with spaces — lookup uses the URL-encoded path

[sierragolflima]

Summary

Content-collection files whose path contains a space cannot be opened from a deployed portal. The error shows the lookup is performed with the URL-encoded path:

'Reports/Data%20Extraction/…' not found in collection 'content'

i.e. the file-serving path fails to URL-decode (%20 → space) before the collection lookup. The stored folder contains a real space (Reports/Data Extraction/…), so the encoded lookup misses and every file under that folder appears to have "disappeared" from the portal UI.

Evidence the files are intact

A direct kernel read with the decoded path succeeds (ContentCollection.GetContentAsync via IContentService — full stream read, byte count matches the Document node's sizeBytes, %PDF- header intact). Only the portal's file-serving route fails.

Steps to reproduce

1. Upload a file into a content collection under a folder whose name contains a space — ideally also a non-ASCII character, e.g. Reports/Data Extraction/Übersicht 2025.pdf.
2. Open the file from the portal UI (file browser / document link).
3. Observe: 'Reports/Data%20Extraction/%C3%9Cbersicht%202025.pdf' not found in collection 'content' — the lookup used the percent-encoded path.
4. Read the same file via IContentService/ContentCollection.GetContentAsync with the decoded path: succeeds, bytes intact.

Files in space-free ASCII paths are unaffected.

Suspected cause

Missing Uri.UnescapeDataString/decode step (or a double-encoding) between the browser URL and the ContentCollection lookup in the file-serving route. The path may also contain UTF-8 percent-escapes (e.g. ü → %C3%BC) — verify the decode handles those, not just %20.

Ask

Decode the request path before the collection lookup, and add a test with a space + umlaut path (e.g. Data Extraction/Übersicht 2025.pdf) through the file-serving route.

[rbuergi]

Addressed by #336 (open, pending CI + review — will auto-close on merge).

Root cause: the /static/{**path} file-serving endpoint (BlazorHostingExtensions.ResolveStatic) looked up the content collection with the raw catch-all route value, which ASP.NET Core leaves percent-encoded (to preserve the multi-segment / separators) — so %20/%C3%9C reached GetContentAsync and missed the stored Reports/Data Extraction/Übersicht 2025.pdf. The encoder side builds URLs with per-segment Uri.EscapeDataString but the serving side never applied the inverse. Fix: per-segment Uri.UnescapeDataString (decode-exactly-once, ASCII no-op, escaped slashes preserved). Real integration test with a space+umlaut path; 6/6 pass, Release build clean.

[sierragolflima]

Tested by uploading 'delete me.pdf' to a MeshWeaver content collection - works.

'to be tested' label removed