9. Content Negotiation

Content negotiation is an optional feature of the HTTP protocol. It is designed to allow for preemptive selection of a preferred content representation, within a single request-response round-trip, and without intervention from the user. However, this may not always be desirable for the user and is sometimes unnecessary for the content provider. Implementors are encouraged to provide mechanisms whereby the amount of preemptive content negotiation, and the parameters of that negotiation, are configurable by the user and server maintainer.

The first step in the negotiation algorithm is for the server to determine whether or not there are any content variants for the requested resource. Content variants may be in the form of multiple preexisting entities or a set of dynamic conversion filters. If there are no variant forms of the resource, the "negotiation" is limited to whether or not that single media type is acceptable under the constraints given by the Accept request header field (if any).

If variants are available, those variants that are completely unacceptable should be removed from consideration first. Unacceptable variants include those with a Content-Encoding not listed in an Accept-Encoding field, those with a character subset (other than the default ISO-8859-1) not listed in an Accept-Charset field, and those with a media type not within any of the media ranges of an explicitly constrained Accept field (or listed with a zero quality parameter).

If no acceptable variants remain at this point, the server should respond with a "406 None Acceptable" response message. If more than one variant remains, and at least one has a Content-Language within those listed by an Accept-Language field, any variants which do not match the language constraint are removed from further consideration.

If multiple choices still remain, the selection is further winnowed by calculating and comparing the relative quality of the available media types. The calculated weights are normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. The following parameters are included in the calculation:

q: The quality factor chosen by the user agent (and configurable by the user) that represents the desirability of that media type. In this case, desirability is usually a measure of the clients ability to faithfully represent the contents of that media type to the user. The value is in the range [0,1], where the default value is 1.
qs: The quality factor, as chosen by the server (via some unspecified mechanism), to represent the relative quality of a particular variant representation of the source. For example, a picture originally in JPEG form would have a lower qs when translated to the XBM format, and much lower qs when translated to an ASCII-art representation. Note, however, that this is a function of the source -- an original piece of ASCII-art may degrade in quality if it is captured in JPEG form. The qs value has the same range and default as q.
mxb: The maximum number of bytes in the Entity-Body accepted by the client. The default value is mxb=undefined (i.e. infinity).
bs: The actual number of bytes in the Entity-Body for a particular source representation. This should equal the value sent as Content-Length. The default value is 0.

The discrete mapping function is defined as:

		{ if mxb=undefined,	then (qs * q)	}
Q(q,qs,mxb,bs)	=	{ if mxb >= bs,	then (qs * q)	}
		{ if mxb <  bs,	then 0	}

The variants with a maximal value for the Q function represent the preferred representation(s) of the entity. If multiple representations exist for a single media type (as would be the case if they only varied by Content-Encoding), then the smallest representation (lowest bs) is preferred.

Finally, there may still be multiple choices available to the user. If so, the server may either choose one (possibly at random) from those available and respond with "200 OK", or it may respond with "300 Multiple Choices" and include an entity describing the choices. In the latter case, the entity should either be of type "text/html' (such that the user can choose from among the choices by following an exact link) or of some type that would allow the user agent to perform the selection automatically (no such type is available at the time of this writing).

The "300 Multiple Choices" response can be given even if the server does not perform any winnowing of the representation choices via the content negotiation algorithm described above. Furthermore, it may include choices that were not considered as part of the negotiation algorithm and resources that may be located at other servers.

T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen - 12 MAR 95

[Next] [Previous] [Top] [Full Contents] [Search]

Generated with CERN WebMaker