Request a preference, not a guarantee
01A client can send Prefer: safe to request content it finds less objectionable. The receiving site defines what that means and may ignore the preference.
In this independent comparison, Preference-Applied is absent. Either applied or ignored remains possible; the client cannot infer which from absence alone.
Source for this drawing: RFC 8674 · Read RFC section 2 ↗
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
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Prefer
- A request field for optional server behavior, defined in RFC 7240.
- safe
- The registered preference token for site-defined avoidance of objectionable content.
- Preference-Applied
- An optional response acknowledgement, not a content-safety certificate.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A preference requests cooperation; it cannot guarantee the response.
- The safe token belongs inside the Prefer request field defined by RFC 7240; it is not a new field named safe. It is unrelated to HTTP safe-method semantics.
- A cooperating origin is encouraged to acknowledge application with Preference-Applied: safe. This acknowledgement is not required even when the preference was applied.
- No acknowledgement leaves application unknown: the origin might have applied the preference or ignored it. Acknowledgement does not certify universally safe content.
RFC 8674 is a December 2019 Informational Independent Stream publication, not an IETF standard or IETF consensus. Support is optional for clients and servers. Examples use fictional sites and do not assert current browser adoption.
Read the RFC section ↗