What do the filename and content type declared on a multipart part actually tell a server about the uploaded bytes?

## Where these two values come from Both values live in the part's own header block, which the client wrote: ```http --ab17 Content-Disposition: form-data; name="document"; filename="invoice.pdf" Content-Type: application/pdf <bytes> ``` A parser reads `filename` out of the `Content-Disposition` header and the media type out of the part's `Content-Type` header, and passes them to the handler as-is. No stage of that pipeline compares either string against the bytes that follow. They are assertions made by whoever composed the request, which for a public endpoint means anyone. ## What each one is actually good for | Value | What it reliably tells you | What it does not tell you | |---|---|---| | presence of `filename` | that this part is a file part, not a form field | anything about the content | | the `filename` string itself | what the client wants the file called | that it is safe to use as an identifier, a path segment, or a type hint | | the part's `Content-Type` | what the client claims the bytes are | what the bytes actually are | | absence of a part `Content-Type` | nothing; it is frequently omitted | that the content is text | The asymmetry is the point. The **presence** of the `filename` parameter is a structural fact about the envelope and is trustworthy. Its **value** is user input in the fullest sense. ## Why the extension is the weakest signal of all An extension is just the tail of a string a client chose. Three separate problems compound: - Extensions and media types do not map one-to-one; several types share one extension and several extensions map to one type. - The client is often not even lying deliberately — operating systems and browsers guess the type themselves, so a genuine upload can arrive mislabelled. - Consumers downstream may make their own determination from the bytes and disagree with the label you stored, which is how a file ends up treated as one thing by your service and another thing by the next one. Where a decision genuinely depends on the type — whether to transcode, whether to render, which pipeline to route it to — determine it from the content and treat the declared type as a hint at best. ## Treating the name as data, not identity The durable rule is to separate the two jobs the filename appears to do: 1. **Identity** — what your system calls the stored object. Generate it yourself: an opaque identifier, with an extension you derived, in a location your code chose. Nothing carried in the request should be able to influence it. 2. **Display** — what a user sees when the file is listed or downloaded again. Keep the original string for this, stored as an ordinary attribute of the record, escaped and bounded like any other user-supplied text. Once identity is generated server-side, a whole family of problems about what the supplied name might contain simply stops being reachable from the storage path. That does not make the string safe everywhere else: it is still untrusted text wherever it is rendered, logged, or echoed back, and building a filesystem path out of it is a well-known vulnerability class in its own right rather than something to get clever about. ## The awkward edges of the string itself A robust handler assumes the supplied name may be any of these, because all of them occur in the wild: - **Empty, or absent entirely** on a part that is clearly a file. - **Very long** — long enough to be worth capping before it is stored or logged. - **Non-ASCII**, including scripts and encodings your storage layer may normalise differently than your database does. - **Duplicated** across several parts in the same request, so a naive name-keyed map silently drops files. - **Containing separators, control characters or padding whitespace**, none of which are rejected by the format. The corresponding defensive posture is dull and effective: cap the length, normalise the encoding once at the boundary, never key anything on it, and always store it beside a generated identifier rather than as one. ## A note on size The declared type and name are also the cheapest thing to reject on: they arrive in the part's headers, before any of its bytes. A part whose declared type is far outside what the endpoint accepts can be refused after a few hundred bytes have been read. That is an optimisation, not a control — a client can declare anything, so the real decision still has to be made once the content is known. ## The interview answer in one breath The presence of `filename` is structural and trustworthy; the value of `filename` and the declared type are untrusted claims. Generate identity, derive the type from the content when it matters, keep the original name as display metadata, and bound it like any other free-text field.