PDF delivery / Content-Type / Content-Disposition
Separate PDF Content-Type and Content-Disposition
Review the Content-Type, Content-Disposition, filename, inline and attachment conditions that are often mixed up in PDF delivery. External PDFs are never fetched; save a local delivery note instead.
Five PDF delivery boundaries
A correct PDF media type does not decide whether a receiver displays or saves it, or which name it uses. Record each header separately.
type ≠ disposition / display → name → verify
| Axis | Review |
|---|
| Content-Type | application/pdf identifies the PDF media type. |
| inline | Represents an expectation that the receiver displays the PDF. |
| attachment | Prompts saving and must be reviewed separately from display. |
| filename | Review the saved name separately from its safety and encoding. |
| filename* | State whether the receiver supports an internationalized name. |
Safe review order
- Confirm the PDF media type with Content-Type.
- Separate display and saving expectations for inline or attachment.
- Check receiver support for filename and filename*.
- Approve the local delivery note before returning to a real delivery.
This page never fetches external PDFs or user URLs. It uses synthetic headers only and performs no external request, storage or URL rewrite.
Six synthetic cases
| case | result |
|---|
content-type-pdf | PDF media type |
inline-display | Display inline |
attachment-download | Download attachment |
safe-filename | Check safe filename |
filename-parameter | Filename parameter |
local-note | Local handoff |