= HTTP content negotiation
{c}
<HTTP content negotiation> provides mechanisms for choosing among available <HTTP representations>, for example different formats, languages or content encodings. One resource can have several representations without requiring that its identifier change for every preference.<HTTP Semantics>[§12, Content Negotiation]{ref}
For a concrete example, stipulate that `/color` offers both an <HTML> representation and plain text. A client sends `Accept: text/html;q=0.8, text/plain;q=0.5`. The weights express a preference for <HTML>. If this server honors that ranking and both choices are available, it selects <HTML> and declares `Content-Type: text/html`. The `Accept` request field describes preferences; the `Content-Type` response field identifies the selected <media type>.<HTTP Semantics>[§12.5.1, Accept; §8.3, Content-Type]{ref}
The quality weight `q` lies between zero and one, defaults to one when omitted, and uses zero for an unacceptable choice. These weights are preference values, not probabilities. The example stipulates a server policy; it is not a claim that all servers must select by a universal maximum-weight algorithm.<HTTP Semantics>[§12.4.2, Quality Values; §12.1, limits on honoring preferences]{ref}
In <HTTP proactive negotiation>, the server makes its choice using information from the request. A response field `Vary: Accept` indicates that the request's `Accept` value might influence selection. This matters when reusing a stored response: the resource identifier alone need not describe every relevant selection input.<HTTP Semantics>[§12.1, Proactive Negotiation; §12.5.5, Vary]{ref}
In <HTTP reactive negotiation>, the client selects after receiving an initial response containing alternatives, potentially making a further request. This can expose the choices directly but can require an additional exchange. Neither mechanism guarantees that every requested representation exists, nor that the server knows the user's eventual purpose.<HTTP Semantics>[§12.2, Reactive Negotiation, alternatives and latency tradeoff]{ref}
Back to article page
