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

Treat the filename as an untrusted suggestion

04

A response cannot grant permission to write outside authorized locations. Filename paths, extensions, controls and special names need recipient-side handling.

DIAGRAMRead RFC section 4.3 ↗
RFC 6266 · § 4.3EXAMPLE
3 / 3
Treat the filename as an untrusted suggestionThree independent recipient safety examples, with no actual filesystem access. A server-supplied path dot dot slash repeated then etc slash passwd is reduced to candidate basename passwd as one optional strategy; authorized-location policy remains mandatory. A claimed application pdf payload named report exe is not authority to execute: a recipient using extensions for media type must use a safe extension, and renaming does not establish content safety. A text plain example with spaces around dot dot is trimmed and substituted by download txt following SHOULD; that name is illustrative, not a required default.A filename suggestion does not grant local authorityExample payload: text/plainfilename=" .. "trim and substituteCandidate: download.txtSHOULD strip confusion and replace special names
03
Substitute a special name after trimming.

For a text/plain example, the surrounding spaces are removed from " .. ", exposing a special name. The shown recipient follows SHOULD and substitutes download.txt; no actual file write is implied.

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

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

An advisory filename is neither a trusted path nor a file-safety verdict.

  • Recipients MUST NOT be able to write anywhere they are not specifically entitled. One strategy is to discard all but the last path segment, considering both slash and backslash separators; this is a strategy, not a mandated complete sanitizer.
  • Recipients that use file extensions to determine media type MUST ensure a safe extension, optimally matching the received media type. A server-supplied .exe is not authority to execute, and renaming does not validate the file contents.
  • Recipients SHOULD strip or replace confusing sequences such as control characters and surrounding whitespace, and SHOULD ignore or substitute special names such as . or .., ~, | and device names.
DETAILS

Three independent fictional examples; no real file is written or executed. Stripping paths does not grant permission to overwrite the remaining basename. A substitute download.txt is only a chosen example for a text/plain payload, not the required name or extension for all downloads. Other local safety policy still applies.

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 ↗