HTTP’s main job is to manage client-server communications, allowing the former to make requests and the latter to reply by returning the requested documents along with sufficient meta-information so that the client can interpret them correctly. In addition, it is desirable to have the requests contain meta-information as well so that the server, by interpreting it, can fulfill the request more effectively.

HTTP/1.1, the current version of the protocol, is described in RFC 2616, a Proposed Standard. Version 1.0 was described in RFC 1945, which is not a standard, but merely an information document.

The charset parameter

HTTP uses MIME type headers for both requests and replies for sending meta-information between client and server. Undoubtedly, the most important line in the reply header is the one called Content-Type which tells the client what kind of data the server is sending: HTML text, plain text, GIF image, AU sound, etc.

But in all text cases, correct interpretation requires knowledge of the character coding used in addition to the basic type information. MIME provides a parameter called charset (short for character set) for this purpose; this parameter is attached to the type in the Content-Type line.

Unfortunately, this parameter is almost never used in current Web practice. This is for historical reasons, since the Web originally used only ISO-8859-1, and this character set became its implicit code; it is even referred to as such in RFC 1945 and RFC 2616. European and American HTTP server developers

Cont.

did not bother to implement it, finding ISO-8859-1 adequate for their purposes.

Today, ISO-8859-1 is no longer the implicit code, in spite of what the RFCs may say; in fact, there is none, since many are in use without any tagging.

Let us hope that the future HTTP standards will recognize this de facto condition and make the charset parameter mandatory for everyone.

Language negotiation

Language negotiation is one of the facets of content type negotiation. The idea is that a document can exist in several language variants, formats or codes; using special header lines, the client indicates its capabilities and/or preferences, which the server then uses to choose the most appropriate version from among all the variants.

Although it was abandoned in HTTP 1.0 (RFC 1945), the idea has resurfaced in the HTTP 1.1 standard (RFC 2616). Several browsers and servers are already capable of handling content negotiation in general, and language negotiation in particular. One of the most popular servers - the Apache server - can be configured to allow document language selection in accordance with preferences indicated by the browser, and also to tag character coding correctly. Additional details can be found in an article on content negotiation on the Apache site.

Language negotiation is a great feature when navigating through multilingual sites. The client receives the appropriate version directly, without wasting time wading through poorly understood or incomprehensible pages looking for a hyperlink to the right language. The Babel site uses it, yet offers explicit hyperlinks on most pages for those whose browser does not yet support linguistic preferences, or those who neglect to set them.