What does the Prefer header actually do?

Prefer lets a client ask the server for optional, non-critical behaviour without making the request fail if the server ignores it. The server is free to apply some, all, or none of the listed preferences. It is a hint, not a command.

What is the difference between return=minimal and return=representation?

return=minimal asks the server to send the smallest useful body, often just a 204 or a Location header after a write. return=representation asks the server to include the full resulting resource in the response body, saving a follow-up GET.

How do I know if my preference was applied?

A compliant server echoes the preferences it honoured in the Preference-Applied response header. If a token you sent is absent there, the server chose not to apply it. Preferences are never guaranteed.

What does respond-async do?

respond-async asks the server to process the request asynchronously and reply immediately, typically with 202 Accepted and a status URL, instead of blocking until the work finishes. It is often paired with a wait token to bound how long the server may block first.

Is handling=strict the same as a Content-Type error?

No. handling=strict asks the server to reject the request if it cannot fully process every part of it, rather than silently ignoring unsupported bits. handling=lenient is the opposite: do the best you can and ignore what you do not understand.

HTTP Prefer Header Reference

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

What the Prefer header is for

The HTTP Prefer request header, defined in RFC 7240, lets a client express optional preferences about how the server should handle a request. Crucially, a preference is advisory: the server may apply it, partially apply it, or ignore it entirely, and the request must still succeed either way. This makes Prefer safe to send speculatively — you never break a request by asking for a behaviour the server does not support.

How it works

A Prefer header carries one or more comma-separated preference tokens. Each token is either a bare keyword (respond-async) or a name=value pair (return=minimal, wait=10). Multiple preferences combine in one header:

Prefer: respond-async, wait=10, return=minimal

When the server honours a preference, it lists the applied tokens in a Preference-Applied response header so the client can confirm what happened. The registered tokens are respond-async, return (minimal or representation), wait (seconds), and handling (strict or lenient). Unknown tokens are simply ignored. The picker below assembles a syntactically correct header from the tokens you select.

Tips and notes

A server that varies its behaviour on Prefer should generally not cache across different preference values without care. Pair respond-async with wait to bound how long the server may block before switching to an async 202 Accepted response. Remember that absence of a token in Preference-Applied means the preference was not applied — design your client to tolerate either outcome.