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
AxisReview
Content-Typeapplication/pdf identifies the PDF media type.
inlineRepresents an expectation that the receiver displays the PDF.
attachmentPrompts saving and must be reviewed separately from display.
filenameReview the saved name separately from its safety and encoding.
filename*State whether the receiver supports an internationalized name.

Safe review order

  1. Confirm the PDF media type with Content-Type.
  2. Separate display and saving expectations for inline or attachment.
  3. Check receiver support for filename and filename*.
  4. 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

caseresult
content-type-pdfPDF media type
inline-displayDisplay inline
attachment-downloadDownload attachment
safe-filenameCheck safe filename
filename-parameterFilename parameter
local-noteLocal handoff