Summary

  • RFC 2295 made representations associated with one HTTP URI visible through a machine-readable variant list, but a list response contained no variant data.
  • Selection, retrieval and presentation remained separate steps; a server could return a choice response under conditions, and the user agent could choose and fetch a variant itself.

A resource could have more than one answer

By the late 1990s, the Web already faced a practical mismatch. A resource might exist as HTML or PostScript, in English or French, with capabilities suited to different user agents. A publisher could expose separate URLs or negotiate among versions at one URI. The hard part was not only choosing a version. Intermediaries—especially caches—also needed to know which response belonged to which request.

RFC 2295, “Transparent Content Negotiation in HTTP,” offered an experimental scheme for making the alternatives visible. The March 1998 memo called a version a variant and described the variant list as a set of machine-readable descriptions bound to one negotiable resource. Its Alternates header could identify each candidate’s URI and attributes such as media type, language, source quality or features. “Transparent” meant that variants held inside an origin server became visible to outside parties. It did not mean that every browser negotiated automatically or that the choice disappeared from view.

The proposal named four negotiation dimensions: media type, charset, language and features. The feature dimension was the extension point for properties that those first three could not express, such as support for particular markup or media-type capabilities. Content encoding—compression, for example—was orthogonal, not a fifth variant dimension in this scheme. That boundary matters: the document was trying to describe which representation was appropriate, not every transformation a server might apply to its bytes.

Three receipts, not one

The list response was an inventory. RFC 2295 defines it as returning the variant list but no variant data. A negotiating user agent could evaluate the alternatives and retrieve one with a normal request to the variant’s URI. The RFC’s example makes the separation literal: first the server returns the list; then the client requests paper.1; only the second response carries the paper. A 300 Multiple Choices response could also include a human-readable body, allowing a non-negotiating user agent or reader to choose manually. Even then, the list itself was not the selected representation.

The server was not merely a catalogue clerk. A choice response returned a representation of the best variant and could include the list as well. But the server needed enough information to choose on the user agent’s behalf, and the selected variant had to be a neighboring resource under the RFC’s URI-based rule. RFC 2296, the companion experimental memo, specified a remote selection algorithm and made “choice” conditional: if the available evidence did not establish a positive, definite best variant—or the resource failed the neighborhood condition—the algorithm returned a list instead. RFC 2295 also allowed clients to apply their own local algorithm and, when the list remained available, retrieve another choice.

This is why the history is not accurately told as “the client chose.” Sometimes it could; sometimes the server could. The protocol separated the candidate inventory, the decision authority, the response that carried bytes, and the later act of presentation. Negotiate was the signal by which a user agent declared support for transparent negotiation from the server’s perspective. A capability declaration was not a receipt showing that a particular request used it.

The cache was part of the design

Negotiation can make the same URI yield different representations. If a cache confuses those responses, a good selection algorithm still produces a bad result. RFC 2295 therefore worked with HTTP’s Vary mechanism and entity tags, and added validators for variant lists. Its rules described how a cache could extract a normal response from a choice response and how the selected resource’s location related to the negotiable one. Cache correctness was not decorative plumbing; it was part of the contract that made URI reuse plausible.

The design also exposed a cost. Sending every preference in every request could be verbose, so the user agent often needed to inspect the list locally. Yet Accept preferences can reveal characteristics of a user’s software or environment. The memo explicitly discussed privacy leakage, spoofed responses from variant resources, and security holes revealed by negotiation. Those are design concerns the RFC recognized, not evidence that a named incident occurred.

RFC 2295 was expressly Experimental and stated that it did not specify an Internet Standard. It applied its transparent mechanism to GET and HEAD, not every HTTP transaction. Its ambition—to make alternatives inspectable while distributing selection among clients, servers and caches—can be reconstructed from the specification. The available evidence here does not establish a browser-support census, deployment rate, or successful user outcome. A variant advertised is not necessarily fetched; a response received is not proof of what a person saw.

Sources