Prefer
The "Prefer" header allows the user-agent to specify server behaviors that are preferred, though not required, by the client. The server can read this header when there's different, optional ways of handling a request, to pick an option that would be most convenient for the client.
For example, an automated script might send Prefer: return=minimal to indicate it only reads the status code, and does not need a response body.
This header offers functionality similar to the Expect header, but can be ignored, and is end-to-end instead of hop-by-hop by default. If listed in Connection, then it is a hop-by-hop header to be parsed by the node.
See the list of HTTP preference tokens.
Usage in requests
Writing requests (clients)
Clients may select a preference for any of the known HTTP preferences, and write them to a Prefer header in the request.
Clients should be prepared to handle a response in whatever way the server responds by, as the request header is strictly advisory. If the server returns a response without a Preference-Applied header listing the names of all the used preferences, the client should take appropriate steps to ensure that the intended outcome was applied.
Reading requests (servers)
Servers that read values from the Prefer header must first tokenize the values. See the list of list of HTTP preferences for preferences that can be implemented. Any preferences used should have their names written to the Preference-Applied response header.
Overview table
- Name
- Prefer
- Description
- Specifies client preferences for the server.
- Direction
- Request
- Negotiates
- Preference-Applied
- List usage in
- Vary
- Specification
- RFC 7240: Prefer Header for HTTP
Syntax
Prefer = "Prefer" ":" 1#preference
preference = preference-parameter *( OWS ";" [ OWS preference-parameter ] )
preference-parameter = parameter / token
Example
Prefer: foo; bar
Prefer: respond-async, wait=10