fix(storage): RFC 6266 Content-Disposition for non-ASCII attachment filenames

[gig-repo]

Problem

GET /api/v1/storage/download returns HTTP 500 for any archived file whose name contains non-ASCII characters (Korean / Japanese / Chinese, accented Latin, etc.). The file is located and decrypted fine — the failure is emitting the response header:

Error downloading file: TypeError [ERR_INVALID_CHAR]: Invalid character in header content ["Content-Disposition"]
    at ServerResponse.setHeader (node:_http_outgoing)
    at downloadFile (packages/backend/.../storage.controller.js)

Node's res.setHeader only accepts Latin-1 in a header value, so:

res.setHeader('Content-Disposition', `attachment; filename="${fileName}"`);

throws whenever fileName has non-Latin-1 bytes. Because the API and the web UI share this endpoint, such attachments can't be downloaded at all.

Fix

Follow RFC 6266: send an ASCII-only filename="..." fallback and a filename*=UTF-8''<percent-encoded> parameter carrying the real name. Modern clients use filename*; older ones fall back safely.

const asciiName = fileName.replace(/[^\x20-\x7E]/g, '_').replace(/["\\]/g, '_');
res.setHeader(
    'Content-Disposition',
    `attachment; filename="${asciiName}"; filename*=UTF-8''${encodeURIComponent(fileName)}`
);

Verification

Reproduced on a running v0.5.0 instance: a Korean-named PDF (장현준_…_원본.pdf) returned 500. After applying the equivalent change to the compiled controller and restarting, the same file now returns 200 with:

Content-Disposition: attachment; filename="b01dc-___________.pdf"; filename*=UTF-8''b01dc-%EC%9E%A5...%EC%9B%90%EB%B3%B8.pdf

Scope is limited to one header line in storage.controller.ts; no behavior change for ASCII filenames.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[hjang212]

I have read the CLA Document and I hereby sign the CLA