Content-Disposition

Representation Metadata IANA permanent response 2 spellings

Content-Disposition tells the client whether to display something inline or treat it as a download, and supplies a filename. Ninety-six providers declare it, almost all of them on file-serving endpoints.

It is worth more scrutiny than it usually gets. The filename is frequently interpolated from user-supplied input, and it lands in a header where quoting rules are fiddly and non-ASCII handling is genuinely difficult to get right. A filename containing a quote or a newline is a header-injection attempt, and the code path that builds this header is often the least reviewed in the service.

The registry

Listed in the IANA HTTP Field Name Registry as a permanent entry. Defined in RFC 6266: Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP).

In the catalog

Declared by 96 providers across 1,301 published specification files in the API Evangelist catalog, where it appears as a response header — sent by the server.

It is spelled 2 different ways across those contracts — Content-Disposition, content-disposition. HTTP field names are case-insensitive (RFC 9110, §5.1), so every one of these is the same header. They are not the same string, which is why generated clients disagree about it.

Using it

Use the filename* form with UTF-8'' percent-encoding for anything that is not plain ASCII, and keep a plain filename fallback. Sanitise aggressively — strip control characters, quotes and path separators. If the name comes from a user, treat building this header as untrusted-input handling, because it is.