Kitchen reported file-reader.php returning HTTP 200 with a genuinely empty body for backups/80-kitchen/spreadsheets/Kitchen-Sourdough-Bake-Log.xlsx, masking a real problem (possibly the documented backups/ web-lock) as if the file were simply empty. HONEST NOTE: attempted direct live reproduction against the exact same path, both text and base64 modes -- did NOT reproduce the empty-body symptom either time (got normal 200 responses with real content, 14721 and 12799 bytes respectively). This is not a confirmed-root-cause fix; per D-CONFIRM-CONSEQUENTIAL I'm not claiming to have found and fixed the exact bug Kitchen hit, since I couldn't verify it two independent ways (couldn't even reproduce it once). What I DID do: identified a real, structural weakness regardless of whether it's what Kitchen actually hit -- the script's existing >100000-byte size checks (both modes) only run AFTER file_get_contents() has already loaded the entire file into memory and, for text mode, after iconv() has processed all of it -- for a genuinely large file this is exactly where a memory-exhaustion PHP fatal would occur, before either check gets a chance to run, and a fatal after headers are already sent produces exactly the empty-200-body symptom reported. Added two defensive layers: (1) a proactive size guard (>5MB) that refuses BEFORE attempting any read, preventing the likely failure mode rather than just catching it after; (2) a register_shutdown_function safety net using real output buffering (added ob_start()) to reliably detect whether a response was already sent -- if a fatal ever does occur before any output, it now returns an explicit JSON 500 error with the exact PHP error message/file/line instead of silently returning nothing.