]>
Prefer Header for HTTP
jasnell@gmail.com
Applications
Individual SubmissionI-DhttppreferThis specification defines an HTTP header that can be
used by a client to request that certain behaviors be implemented
by a server while processing a request.This specification defines a new HTTP header that can be
used by a client to request that certain behaviors be implemented
by a server while processing a request.In this document, the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”,
“SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”
are to be interpreted as described in .The Prefer request-header is used to indicate that particular
server behaviors are preferred by the client, but not required for
successful completion of the request. Prefer is similar in nature to the
Expect header defined by with the exception
that servers are allowed to ignore stated preferences.
Prefer = “Prefer” “:” 1#preference
preference = “return-no-content” |
“return-content” |
“return-status” |
preference-extension
preference-extension = token [ “=” ( token | quoted-string )
*prefer-params ]
prefer-params = “;” token [ “=” ( token | quoted-string ) ]
This header is defined with an extensible syntax to allow for future
values included in the Registry of Preferences).
A server that does not recognize or is unable to comply with particular
preference values in the Prefer header of a request MUST ignore those values
and MUST NOT stop processing or signal an error.Comparison of preference values is case-insensitive for unquoted
tokens and is case-sensitive for quoted-string preference-extensions.An HTTP proxy MAY choose to honor a preference even if the origin server
does not. The Prefer request-header MUST be forwarded by the proxy if the
request is forwarded.Note that the application of a preference by the server MAY affect
the caching characteristics of the response.The Preference-Applied response header MAY be included in the response
message to indicate which Prefer request header values were honored by the server
and applied to the request.
Preference-Applied = “Preference-Applied” “:” 1#preference
The “return-accepted” token indicates that the client prefers
that the server respond with a 202 Accepted response indicating
that the request has been accepted for processing.The “return-content” token indicates that the client prefers
that the server include an entity representing the current state of the
resource in the response to a successful request.The “return-no-content” token indicates that the client prefers
that the server not include an entity in the response to a successful request.
Typically, such responses would use the 204 No Content status code as
defined in Section 10.2.5 of , but other status
codes can be used as appropriate.The “return-status” token indicates that the client prefers
that the server include an entity describing the status of the request
in the response to a successful request.The ‘Prefer’ and ‘Preference-Applied’ headers should be added to
the permanent registry (see ).
Header field name: Prefer
Applicable Protocol: HTTP
Status:
Author/Change controller: IETF
Specification document: this specification
Header field name: Preference-Applied
Applicable Protocol: HTTP
Status:
Author/Change controller: IETF
Specification document: this specification
This registry is maintained by IANA and initially contains the
values: “return-accepted”, “return-content”, “return-no-content” and
“return-status”. New assignments are subjects to IESG approval, as
outlined in . Requests should be made by
email to IANA, which will then forward the request to the IESG,
requesting approval. The request should use the following template:Preference: (A value for the Prefer request header that conforms to the
syntax rule given in )Description:Expected server behavior:Security considerations:Specific preferences requested by a client can introduce security
considerations and concerns beyond those discussed in .
Implementors must refer to the specifications and descriptions of those
preferences to determine the security considerations relevant to each.
&rfc2119;
&rfc2434;
&rfc2616;
&rfc3864;