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

Handle extensions and invalid fields within the right scope

05

Unknown parameters can be ignored without losing understood information. An invalid field is different from an invalid response, and this HTTP profile does not define MIME body-part handling.

DIAGRAMRead RFC section 4.4 ↗
RFC 6266 · § 4.4EXAMPLE
3 / 3
Handle extensions and invalid fields within the right scopeThree independent boundaries. An unknown fictional sample parameter is ignored following SHOULD while attachment and report txt remain understood. A response with duplicate filename parameters arrives at the user agent; the pictured default ignores only the invalid field and keeps the response, with optional recovery and validator rejection exceptions stated separately. Finally an outer HTTP response Content-Disposition is in scope, but a same-named header inside a multipart part is outside this profile; shared MIME registries do not automatically supply HTTP semantics.Separate unknown parameters, errors and scopeHTTP responseResponse header:Content-Disposition → RFC6266Multipart payload: one partPart header: Content-DispositionOutside this response-header profileUse the relevant MIME / multipart specification
03
Apply this profile to the response header only.

The outer HTTP Content-Disposition is in scope. A same-named field inside a multipart part belongs to another specification, not this HTTP response-header profile.

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

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.

Related RFCs and changes

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

KEY POINT

Keep extension tolerance, error recovery and protocol scope distinct.

  • Recipients SHOULD ignore unrecognized parameters. Unknown disposition types have a different rule: they SHOULD be handled like attachment.
  • Recipients MAY recover a usable value from an invalid field, but SHOULD NOT reject the whole message outright unless explicitly desirable, such as in a validator. Default handling is to ignore the invalid field; no first-wins or last-wins duplicate rule is mandated.
  • This profile covers HTTP response headers, not Content-Disposition inside multipart payload parts. Registries are shared with MIME, but not every MIME value makes sense in HTTP. Verified erratum3475 identifies read-date, not quoted-date-time, among the MIME parameters omitted from this profile.
DETAILS

The sample parameter is hypothetical and unrecognized by the pictured recipient. The invalid field arrives before the receiver ignores it; it is not stopped before receipt. Source§3 allows exceptional outright rejection and optional recovery, so the shown default is not the only legal strategy. MIME multipart and email rules require their own specifications.

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 ↗