Server-Driven Negotiation
Client-driven negotiation has several drawbacks, as discussed in the previous section. Most of these drawbacks center around the increased communication between the client and server to decide on the best page in response to a request. One way to reduce this extra communication is to let the server decide which page to send back-but to do this, the client must send enough information about its preferences to allow the server to make an informed decision. The server gets this information from the client's request headers.
There are two mechanisms that HTTP servers use to evaluate the proper response to send to a client:
· Examining the set of content-negotiation headers. The server looks at the client's Accept headers and tries to match them with corresponding response headers.
· Varying on other (non-content-negotiation) headers. For example, the server could send responses based on the client's User-Agent header.
These two mechanisms are explained in more detail in the following sections.
Content-Negotiation Headers
Clients may send their preference information using the set of HTTP headers listed in Table 17-2.
Table 17-2. Accept headers | |
| Header | Description |
| Accept | Used to tell the server what media types are okay to send |
| Accept-Language | Used to tell the server what languages are okay to send |
| Accept-Charset | Used to tell the server what charsets are okay to send |
| Accept-Encoding | Used to tell the server what encodings are okay to send |
Notice how similar these headers are to the entity headers discussed in Chapter 15. However, there is a clear distinction between the purposes of the two types of headers. As mentioned in Chapter 15, entity headers are like shipping labels-they specify attributes of the message body that are necessary during the transfer of messages from the server to the client. Content-negotiation headers, on the other hand, are used by clients and servers to exchange preference information and to help choose between different versions of a document, so that the one most closely matching the client's preferences is served.
Servers match clients' Accept headers with the corresponding entity headers, listed in Table 17-3.
Table 17-3. Accept and matching document headers | |
| Accept header | Entity header |
| Accept | Content-Type |
| Accept-Language | Content-Language |
| Accept-Charset | Content-Type |
| Accept-Encoding | Content-Encoding |
Note that because HTTP is a stateless protocol (meaning that servers do not keep track of client preferences across requests), clients must send their preference information with every request.
If both clients sent Accept-Language header information specifying the language in which they were interested, the server could decide which copy of www.joes-hardware.com to send back to each client. Letting the server automatically pick which document to send back reduces the latency associated with the back-and-forth communication required by the client-driven model.
However, say that one of the clients prefers Spanish. Which version of the page should the server send back? English or French? The server has just two choices: either guess, or fall back on the client-driven model and ask the client to choose. However, if the Spaniard happens to understand some English, he might choose the English page-it wouldn't be ideal, but it would do. In this case, the Spaniard needs the ability to pass on more information about his preferences, conveying that he does have minimal knowledge of English and that, in a pinch, English will suffice.
Fortunately, HTTP does provide a mechanism for letting clients like our Spaniard give richer descriptions of their preferences, using quality values ("q values" for short).
Content-Negotiation Header Quality Values
The HTTP protocol defines quality values to allow clients to list multiple choices for each category of preference and associate an order of preference with each choice. For example, clients can send an Accept-Language header of the form:
Accept-Language: en;q=0.5, fr;q=0.0, nl;q=1.0, tr;q=0.0
Where the q values can range from 0.0 to 1.0 (with 0.0 being the lowest preference and 1.0 being the highest). The header above, then, says that the client prefers to receive a Dutch (nl) version of the document, but an English (en) version will do. Under no circumstances does the client want a French (fr) or Turkish (tr) version, though. Note that the order in which the preferences are listed is not important; only the q values associated with them are.
Occasionally, the server may not have any documents that match any of the client's preferences. In this case, the server may change or transcode the document to match the client's preferences. This mechanism is discussed later in this chapter.
Varying on Other Headers
Servers also can attempt to match up responses with other client request headers, such as User-Agent. Servers may know that old versions of a browser do not support JavaScript, for example, and may therefore send back a version of the page that does not contain JavaScript.
In this case, there is no q-value mechanism to look for approximate "best" matches. The server either looks for an exact match or simply serves whatever it has (depending on the implementation of the server).
Because caches must attempt to serve correct "best" versions of cached documents, the HTTP protocol defines a Vary header that the server sends in responses; the Vary header tells caches (and clients, and any downstream proxies) which headers the server is using to determine the best version of the response to send. The Vary header is discussed in more detail later in this chapter.
Content Negotiation on Apache
Here is an overview of how the Apache web server supports content negotiation. It is up to the web site content provider-Joe, for example-to provide different versions of Joe's index page. Joe must put all his index page files in the appropriate directory on the Apache server corresponding to his web site. There are two ways to enable content negotiation:
· In the web site directory, create a type-map file for each URI in the web site that has variants. The type-map file lists all the variants and the content-negotiation headers to which they correspond.
· Enable the MultiViews directive, which causes Apache to create type-map files for the directory automatically.
Using type-map files
The Apache server needs to know what type-map files look like. To configure this, set a handler in the server configuration file that specifies the file suffix for type-map files. For example:
AddHandler type-map .var
This line indicates that files with the extension .var are type-map files.
Here is a sample type-map file:
URI: joes-hardware.html
URI: joes-hardware.en.html
Content-type: text/html
Content-language: en
URI: joes-hardware.fr.de.html
Content-type: text/html;charset=iso-8859-2
Content-language: fr, de
From this type-map file, the Apache server knows to send joes-hardware.en.html to clients requesting English and joes-hardware.fr.de.html to clients requesting French. Quality values also are supported; see the Apache server documentation.
Using MultiViews
To use MultiViews, you must enable it for the directory containing the web site, using an Options directive in the appropriate section of the access.conf file (<Directory>, <Location>, or <Files>).
If MultiViews is enabled and a browser requests a resource named joes-hardware, the server looks for all files with "joes-hardware" in the name and creates a type-map file for them. Based on the names, the server guesses the appropriate content-negotiation headers to which the files correspond. For example, a French-language version of joes-hardware should contain .fr.
Server-Side Extensions
Another way to implement content negotiation at the server is by server-side extensions, such as Microsoft's Active Server Pages (ASP). See Chapter 8 for an overview of server-side extensions.