Visual RFC.
ALL RFCs / RFC 8674
Read the RFC ↗
RFC 8674 / REQUEST AND INTERPRET A PREFERENCE

Choose when to send it

02

The safe preference can accompany HTTPS requests. A plain HTTP request must not carry it, and privacy choices can also call for omitting it.

DIAGRAMRead RFC section 2 ↗
RFC 8674 · § 2EXAMPLE
3 / 3
Choose when to send itThree separate emission decisions keep the request distinct from its optional field. The configured HTTPS example carries safe. The plain HTTP request still arrives but the safe-preference emission path stops under MUST NOT. In the last HTTPS example a user has expressed a desire to avoid fingerprinting or targeting, so the conditional SHOULD NOT guidance calls for omission. This is not a blanket requirement for all private modes or for all HTTPS requests.Separate request delivery from field emissionUser agentOriginHTTPS request arrivesemit safe preferencePrefer: safe omittedSHOULD NOT emit for this privacy choiceUser expressed desire to avoid targeting
03
Respect the stated privacy preference.

For an HTTPS request where the user expressed a desire to avoid fingerprinting or targeting, the user agent SHOULD NOT emit safe. This conditional recommendation differs from the HTTP prohibition.

Source for this drawing: RFC 8674 · Read RFC section 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 9111 Caching

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

Terms in this drawing
Scheme
The http or https part of the URI determines the plain-HTTP emission restriction.
User agent
The browser or other HTTP client deciding which request fields to send.
Related RFCs and changes

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

KEY POINT

Control emission of the preference without confusing it with delivery of the request.

  • A user agent MUST NOT emit the safe preference on requests with the http scheme. The illustration still delivers the HTTP request, with the preference omitted.
  • Sending on every HTTPS request is typical of the described approach, not mandatory. Finer per-site control is possible; common OS HTTP libraries MAY generate the preference from system configuration.
  • A user agent SHOULD NOT include the preference when the user has expressed a desire to avoid fingerprinting or targeting attacks. Some private modes are an example, not a universal MUST for every private mode.
DETAILS

Appendix A suggests a control such as “Request safe content from web sites”, rather than a promise of enforcement. The controls pictured here explain a protocol; they are not settings on Visual RFC. HTTPS hides the field in transit from ordinary passive observers, not from the receiving origin.

Read the RFC section ↗

All chapters in RFC 8674

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 ↗