Visual RFC.
ALL RFCs / RFC 6266
Read the RFC ↗
RFC 6266 / HTTP RESPONSE DISPOSITION

Choose normal processing or a save interaction

01

Content-Disposition adds response-processing information. attachment suggests a local save interaction; inline keeps normal processing according to the media type.

DIAGRAMRead RFC section 4.2 ↗
RFC 6266 · § 4.2EXAMPLE
3 / 3
Choose normal processing or a save interactionThree independent response examples. A sender returns Attachment with filename example.html, prompting a local save choice rather than normal media-type processing. INLINE with quoted filename an example.html keeps default processing and a name for a later save. An unknown fictional disposition example is treated like attachment following SHOULD. Case-insensitive type matching and advisory names do not authorize a silent write, execution, overwrite or a specified browser dialog.Disposition changes handling, not payload bytesHTTP senderUser agentHTTP responseContent-Disposition:example; filename=report.txtUnknown type → handle like attachmentSHOULD; local safety policy still applies
03
Handle an unknown disposition conservatively.

For the fictional unhandled type example, the shown recipient follows SHOULD and treats it like attachment. It still applies filename and local safety policy.

Source for this drawing: RFC 6266 · Read RFC section 4.2 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

RFC 9110 HTTP RFC 3629 UTF-8

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
HTTP
Hypertext Transfer Protocol, used to exchange requests and responses.
User agent (UA)
Recipient software, such as a browser.
Media type
A label such as text/html describing the payload format.
Advisory filename
A suggested local name that the recipient must assess under its own permissions and safety policy.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Disposition is a processing instruction, not a change to the payload bytes.

  • Disposition types are matched case-insensitively. attachment indicates that the recipient should prompt to save locally rather than process normally; inline implies default processing.
  • inline can still supply a filename for a later save. The filename is advisory; its presence is not an automatic file write.
  • Unknown or unhandled disposition types SHOULD be handled like attachment. This does not authorize execution or an overwrite, and exact browser UI is not specified.
DETAILS

Three independent response examples, not three responses in one transaction. The first two adapt RFC6266§5. A browser is one possible user agent (UA), meaning recipient software. Content-Type describes media type; Content-Disposition adds handling information. This guide covers HTTP response headers, not multipart body-part headers.

Read the RFC section ↗

All chapters in RFC 6266

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗