fix(files): serve transit files whose name is outside Latin-1 - #249
Conversation
Header values are ByteStrings, so a name holding a character above U+00FF threw while the download response was built, failing with HTTP 500. Mail hit this often, since an attachment keeps the filename the server sent. Names now follow RFC 6266: non-ASCII travels percent-encoded in `filename*`, with an ASCII-only `filename` fallback. ASCII names are unchanged.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
Summary by CodeRabbit
WalkthroughTransit file response handling now uses the shared 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Downloading a transit file whose name has a character above U+00FF returns HTTP 500. The upload succeeds, so you only find out at download time, and the file stays unreachable for the rest of its TTL.
Header values are ByteStrings, so a name outside Latin-1 throws while the response is being built, before any byte is written.
It is easy to hit through mail, where an attachment keeps the filename the server sent and CJK names are common.
The name now follows RFC 6266. Anything outside ASCII is carried percent-encoded, with a plain ASCII fallback for clients that do not read it: