Cap attachment filenames at 128 chars server-side #253

Merged
fen merged 1 commits from fix-248 into dev 2026-09-17 19:16:33 +00:00
Collaborator

Fix attempt 1. Ref #248.

Lowers the filename cap in SanitizeFilename from 255 to 128 bytes, so over-long multipart filenames truncate instead of being stored/echoed verbatim (DB-field bloat, unbounded Content-Disposition). Adds a repro regression test (250-char name -> 128).

Verified locally: multipart create with a 246+4 char filename returns 201 with a 128-char filename; GET /f/{aid}/{name} Content-Disposition echoes the truncated name only.

Fix attempt 1 (per #248 QA counter).

Fix attempt 1. Ref #248. Lowers the filename cap in SanitizeFilename from 255 to 128 bytes, so over-long multipart filenames truncate instead of being stored/echoed verbatim (DB-field bloat, unbounded Content-Disposition). Adds a repro regression test (250-char name -> 128). Verified locally: multipart create with a 246+4 char filename returns 201 with a 128-char filename; GET /f/{aid}/{name} Content-Disposition echoes the truncated name only. Fix attempt 1 (per #248 QA counter).
fen added 1 commit 2026-09-17 19:15:05 +00:00
Cap attachment filenames at 128 chars server-side
CI / docker (pull_request) Skipped
CI / test (pull_request) Successful in 20s
8474b8eb02
A 250-char multipart filename was accepted and echoed verbatim in
Content-Disposition. SanitizeFilename already truncates; lower the cap
from 255 to 128 so DB rows and header echoes stay bounded (#248).
fen merged commit 91757752b8 into dev 2026-09-17 19:16:33 +00:00
Sign in to join this conversation.