Read optional preferences
01Prefer lets an HTTP client ask for optional server behavior. A preference is a named hint, not a condition that must be satisfied.
This server does not recognize priority=5. It MUST ignore that token and continue ordinary processing. Prefer is end to end; a forwarding proxy normally forwards it, with the explicit Connection exception in §2.
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.
RFC 8144 specifies WebDAV response rules and extends return=representation to relevant 412 responses. This guide teaches the base preferences and marks that scope.
Read the updated RFC section ↗Names of preferences and parameters compare case-insensitively; values compare case-sensitively. Commas separate preferences; semicolons attach parameters.
- Names of preferences and parameters compare case-insensitively; values compare case-sensitively. Commas separate preferences; semicolons attach parameters.
- Unknown or unsupported tokens MUST be ignored while processing continues. Duplicate preference names SHOULD NOT be sent; only the first instance is considered and later occurrences SHOULD be ignored.
- A forwarding proxy MUST forward Prefer unless Connection explicitly marks it hop by hop. Some preferences can be applied by a proxy itself.
Examples show one chosen server policy. Preferences are optional; consult the linked requirements, errata and RFC 8144 WebDAV update.
Read the RFC section ↗