2026-09-06 · 6 min read · Rahul Chitturi
- http
- uploads
- debugging
A browser can select a file successfully while the receiving API sees a blank, garbled, or unsafe filename. Multipart bodies combine boundary-delimited bytes with Content-Disposition parameters whose quoting and character encoding vary across clients and frameworks.
The file content may remain correct even when filename metadata fails, so treat transport bytes, media type, displayed name, and storage key as separate values.
Inspect the multipart contract
Capture a harmless request in a controlled environment and record the boundary, line endings, field name, disposition parameters, declared content type, payload length, and parsed server result. Let the HTTP client generate its boundary unless the complete body is assembled consistently.
- Require form-data and the expected field name
- Check quoted filename and extended filename parameters
- Decode character sets exactly once
- Verify the closing boundary and CRLF placement
Separate display names from storage paths
Treat every client filename as untrusted metadata. Remove path components, reject control characters, apply product length rules, and generate an independent server-side storage identifier.
Do not repair uploads by accepting arbitrary paths or trusting a client MIME type. Validate allowed content and size from the uploaded bytes, then escape the display name for its eventual HTML, header, or log context.
A Flashman workflow
Use the URL tool to inspect percent-encoded parameters, Base64 for synthetic byte fixtures, hash to compare public test files, and JSON formatter for sanitized parser output. Do not paste customer uploads into shared tools.
Test ASCII, spaces, quotes, non-ASCII names, duplicate parameters, missing filenames, path-like values, zero-byte files, exact size limits, repeated fields, and every supported client.