Thiemo Fetzer 22. Juli 2005

Automatische Auswahl mit Content Negotiation

Kein Beitragsbild

Ein einfaches Apache Modul, das häufig unbeachtet bleibt, bietet auf Grundlage des http-Protokolls interessante Möglichkeiten. Etwa bei der Erstellung internationalisierter Webseiten, bei denen Inhalte in mehreren Sprachen zur Verfügung gestellt werden. Die grundlegende Idee der Content Negotiation ist, dass der Server anhand der Präferenzen des Browsers entscheidet, welchen Content er ausliefert.

Grundsätzlich ist Content Negotiation in HTTP integriert. Der Client – also Browser, Bot oder ähnliches – kann den Server entscheiden lassen, welchen Inhalt und welche Form dieser an den Client zurücksendet. Dabei folgt die Auswahl des Servers den Präferenzen des Clients. Das heißt, man kann über die HTTP-Anfrage des Clients zum Beispiel angeben, welches Format man bevorzugt, .etwa wenn ein Bild sowohl in JPEG als auch in GIF Formatierung vorliegt, In den Anfragen gibt der Client hierzu die akzeptierten MIME Typen an. Ein älterer Browser, etwa der Internet Explorer 3, sendet in der Anfrage nicht, dass er etwa Daten des MIME Typs text/xml empfangen und verwerten kann.

Der Accept-Header, über den eben in der Anfrage spezifiziert wird, welche Inhalte der Browser annimmt, sieht im Idealfall etwa so aus:

 Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9,
    image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1

Dabei handelt es sich um den Accept-Header des MozillaBrowsers. In ihm werden alle gängigen Technologien angegeben. Das q-Attribut gibt den Qualitätswert des bestimmten Inhaltstyps an. Der Wert liegt zwischen 0 und 1. Je höher der Wert, desto höher liegt die Präferenz für einen bestimmten Inhaltstyp. Standardmäßig, also wenn nicht angegeben, ist der q-Wert 1. In dem Fall des Mozilla Browsers ist liegt die Präferenz bei Bildern deutlich bei Bildern des MIME Tpys image/png und image/jpeg. In dem vorher genannten Beispiel würde der Server folglich eher PNGs oder JPEGs zurücksenden als etwa Gifs. Über den Wildcard-Mime-Typ */* bringt der Client zum Ausdruck, dass er auch mit anderen Formaten zurechtkommt beziehungsweise diese zumindest empfängt (auch wenn er dann nicht unbedingt wissen muss, was er mit ihnen anfängt).

Der Accept-Header des Internet Explorers ist für Content Negotiation nicht unbedingt hilfreich:

      Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint,
    application/vnd.ms-excel, application/msword, */*

In dem Header werden weder die Contenttypen HTML, noch XML oder XHTML erwähnt. Das erschwert Content Negotiation auf der Serverseite ganz erheblich. Nehmen wir etwa an, dass der Server die Daten in XML Dateien vorliegen hat, die über ein XSL Stylesheet im Idealfall auf Clientseite dargestellt werden. Sollte der Browser kein XML unterstützen, so soll der Server die Aufgabe der Formatierung von XML und XSL in HTML über einen XSLT-Prozessor übernehmen.

Eine solche Negotiation würde erlauben, dass die XSLT Transformation über den Server nur dann vorgenommen wird, wenn diese auch wirklich benötigt wird. Da der Internet Explorer in seinem Accept keine Angaben zu XML oder gar HTML macht, wüsste der Server, der mit einem solchen Accept umzugehen hat, nicht, was er mit einer solchen Anfrage machen soll. Den Accept-Header, den der Internet Explorer sendet, kann man nur mit Mühe über die Registry verändern.

Wie in der Einleitung schon angesprochen, gibt es auch die Möglichkeit, die Sprachauswahl des Servers über die HTTP – Anfrage direkt zu beeinflussen. In der Anfrage sendet der Browser nämlich auch einen Teil, der etwa wie folgt aussehen könnte.

      Accept-Language: de, en; q=0.5

Das heißt, der Client kann sowohl mit Englisch als auch Deutsch umgehen, wobei die Präferenz bei Deutsch liegt. Die Einstellung der akzeptierten Sprachen kann beim Internet Explorer über das Menü „Internetoptionen – Sprachen“ verändert werden.

Sprachauswahl im Internet Explorer

Nachdem die grundlegenden Ideen von Content Negotiation auf Clientseite erläutert wurden, nähern uns wir jetzt der konkreten Anwendung – d.h. wie man Content Negotiation auf der Serverseite nutzen kann.

Grundsätzlich gibt es mit dem Apache Webserver, bei dem das Modul Content Negotiation aktiviert ist, zwei Möglichkeiten dieses zu nutzen.

Zum einen kann man spezifisch einen Fall untersuchen und alle Alternativen beispielsweise für verschiedene Sprachen angeben; zum anderen kann man generell den Server die Aufgabe übertragen, nach Alternativen zu suchen und die für den Client passende zurückzugeben.

Zunächst soll die explizite Variante vorgestellt werden; dabei werden Type Maps verwendet. Eine Type Map ist eine Datei, die genaue Angaben zu den vorhandenen Alternativen für ein Dokument oder generell eine Datei hat. Um Type Maps verwenden zu können, müssen diese in der Server-Konfiguration aktiviert sein. In der Regel ist die Dateiendung für Type Maps *.var. Eine einfache Type Map könnte wie folgt aussehen:

Beispiel: diagramm.var

      URI: diagramm
    URI: diagramm.jpeg
    Content-type: image/jpeg; qs=0.9
    URI: diagramm.gif
    Content-type: image/gif; qs=0.4

Die Anfrage an die Quelldatei könnte wie folgt aussehen:

http//www.drweb.de/artikel/diagramm

Die Type Map besagt, dass es von dem angeforderten „diagramm“ zwei Versionen gibt – zum einen ein GIF, zum anderen ein JPEG. Der Wert „qs“ beschreibt auf der Serverseite die Qualität der Quelle. Liegt nun die Präferenz des Browsers (wie bei Mozilla) bei JPEGs, so liefert der Browser die Datei diagramm.jpeg zurück

Falls verschiedene Sprachen für das Dokument vorliegen, so könnte die Anfrage wie folgt aussehen:

Beispiel: text.var

      URI: text
    URI: text.html.de
    Content-type: text/html
    Content-language: de
    URI: text.html.en
    Content-type: text/html
    Content-language: en

Die Anfrage an den Server erfolgt wiederum einfach über den Dateinamen. Anhand der vorhandenen Type Map erkennt der Server die Anzahl der Varianten und liefert als Ergebnis die zu den Präferenzen des Clients passende Seite.

Falls es keine passende Seite zu den Wünschen des Clients gibt, so generiert Apache eine Fehlermeldung 406 und listet alle vorhandenen Alternativen auf; unter diesen kann der Besucher sich dann entscheiden.

Die Verwendung von Type Maps ist darauf ausgerichtet, ein explizites Problem zu lösen. Wenn man jedoch generell mehrere Versionen eines Dokumentes vorliegen hat, zum Beispiel in verschiedenen Sprachen, ist es einfacher mit der zweiten Variante das Problem zu lösen – mit den Multiviews. Dabei generiert sich der Webserver quasi selbst eine Type Map für jede Anfrage.

Hierzu muss die Option „MultiViews“ aktiviert werden. Dies kann mit einer .htaccess-Datei geschehen. Der Eintrag in der .htaccess Datei sieht wie folgt aus:

Beispiel .htaccess

      Options +MultiViews

Wird diese Option aktiviert, wird bei einer Anfrage nach „test“ generell genau so verfahren, wie bei den Type Maps. Der Server erkennt die vorhandenen Varianten und liefert diese nach den Präferenzen des Clients. Wichtig ist dabei, dass die Varianten die Dateinamen gemäß der Form test.html.de bzw. test.html.en tragen müssen; anhand des Sprachsuffixes erkennt der Server den Sprachtyp. Dieser richtet sich nach den internationalen Sprachcodes (nach dem RFC 1766 Standard).

Der Vorteil dabei ist, dass man, wenn man etwa Links setzt, nicht immer den Sprachsuffix hinzufügen muss. Gelinkt wird schlicht auf die Seite „test“, der Server erkennt dann automatisch an den Browsereinstellungen, welche Seite er zu liefern hat. Das verringert den Pflegeaufwand deutlich, da man für alle Sprachversionen die gleichen Links verwenden kann. ™

Erstveröffentlichung 22.07.2005

Thiemo Fetzer

Thiemo Fetzer lebt seit 2008 in London und promoviert dort im Fachbereich "Entwicklungsökonomie" an der London School of Economics. Zuvor hat er Wirtschaftswissenschaften, Mathematik und Informatik in Magdeburg und Ulm studiert.
Dr. Webs exklusiver Newsletter
Hinweise zum Datenschutz, also dem Einsatz von Double-Opt-In, der Protokollierung der Anmeldung, der Erfolgsmessung, dem Einsatz von MailChimp als Versanddienstleister und deinen Widerrufsrechten findest du in unseren Datenschutzhinweisen.

Ein Kommentar

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kennst du schon unseren Newsletter?

Hinweise zum Datenschutz, also dem Einsatz von Double-Opt-In, der Protokollierung der Anmeldung, der Erfolgsmessung, dem Einsatz von MailChimp als Versanddienstleister und deinen Widerrufsrechten findest du in unseren Datenschutzhinweisen.