Keep cache variants separate
06A preference can change a response in ways that matter to a cache. Vary tells a cache which request fields were relevant to selecting a stored response.
Asynchronous state and extra representations cost resources. The server may decline a preference rather than commit unlimited work. New preferences have their own specifications and security considerations; this guide covers the initial RFC 7240 set.
Source for this drawing: RFC 7240 · 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
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Prefer SHOULD NOT be used for content negotiation. If supported optional behavior can affect cache handling, the response MUST include Vary: Prefer even when the request omitted Prefer.
- Prefer SHOULD NOT be used for content negotiation. If supported optional behavior can affect cache handling, the response MUST include Vary: Prefer even when the request omitted Prefer.
- Vary: * is an allowed alternative; a proxy cannot use that response to satisfy a later request from its cache.
- Servers may ignore preferences to avoid excessive resource costs. New preferences use a Specification Required registry; consult each definition and its security considerations.
Examples show one chosen server policy. Preferences are optional; consult the linked requirements, errata and RFC 8144 WebDAV update.
Read the RFC section ↗