2026-09-23 · 5 min read · Rahul Chitturi
- http
- api
- debugging
The Prefer request field lets a client state preferences such as returning a minimal representation, waiting for a bounded interval, or processing asynchronously. A server can ignore unsupported preferences and can report applied ones with Preference-Applied.
Bugs appear when clients treat a preference as a command, intermediaries rewrite fields, or a minimal response is parsed as though it contains the ordinary representation.
Record negotiation, not just status
Capture the exact request field, parsed tokens and parameters, endpoint capabilities, response status, Preference-Applied value, location fields, body presence, and elapsed time. Determine whether caches vary responses when a preference changes representation.
- Use a standards-aware field parser.
- Define fallback behavior for ignored preferences.
- Keep status and body handling independent.
- Document polling and cancellation for async work.
Trace return and async workflows
For return=minimal or return=representation, verify what metadata remains available and whether the response body matches the applied preference. For respond-async, define job ownership, status location, retry timing, expiry, idempotency, and final result behavior.
Do not infer that every 202 response came from a preference or that every successful mutation includes a representation. The endpoint contract remains authoritative.
Test tolerant behavior
Use Flashman's URL tool for synthetic endpoints, JSON formatter for response fixtures, diff for field changes, and timestamp converter for wait and polling timelines.
Test absent, supported, unsupported, repeated, and malformed preferences; minimal and full bodies; synchronous and asynchronous completion; proxy forwarding; caches; retries; duplicate mutations; timeout boundaries; and older clients.