Spaces. Smartes Cloud Hosting für anspruchsvolle Webprojekte. Loslegen und Spaces testen. Von Mittwald.
Thiemo Fetzer 22. Juli 2005

Automatische Auswahl mit Content Negotiation

Kein Beitragsbild

Ein ein­fa­ches Apache Modul, das häu­fig unbe­ach­tet bleibt, bie­tet auf Grundlage des http-Protokolls inter­es­san­te Möglichkeiten. Etwa bei der Erstellung inter­na­tio­na­li­sier­ter Webseiten, bei denen Inhalte in meh­re­ren Sprachen zur Verfügung gestellt wer­den. Die grund­le­gen­de Idee der Content Negotiation ist, dass der Server anhand der Präferenzen des Browsers ent­schei­det, wel­chen Content er aus­lie­fert.

Grundsätzlich ist Content Negotiation in HTTP inte­griert. Der Client – also Browser, Bot oder ähn­li­ches – kann den Server ent­schei­den las­sen, wel­chen Inhalt und wel­che Form die­ser an den Client zurück­sen­det. Dabei folgt die Auswahl des Servers den Präferenzen des Clients. Das heißt, man kann über die HTTP-Anfrage des Clients zum Beispiel ange­ben, wel­ches Format man bevor­zugt, .etwa wenn ein Bild sowohl in JPEG als auch in GIF Formatierung vor­liegt, In den Anfragen gibt der Client hier­zu die akzep­tier­ten MIME Typen an. Ein älte­rer Browser, etwa der Internet Explorer 3, sen­det in der Anfrage nicht, dass er etwa Daten des MIME Typs text/xml emp­fan­gen und ver­wer­ten kann.

Der Accept-Header, über den eben in der Anfrage spe­zi­fi­ziert wird, wel­che 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 han­delt es sich um den Accept-Header des MozillaBrowsers. In ihm wer­den alle gän­gi­gen Technologien ange­ge­ben. Das q-Attribut gibt den Qualitätswert des bestimm­ten Inhaltstyps an. Der Wert liegt zwi­schen 0 und 1. Je höher der Wert, des­to höher liegt die Präferenz für einen bestimm­ten Inhaltstyp. Standardmäßig, also wenn nicht ange­ge­ben, ist der q-Wert 1. In dem Fall des Mozilla Browsers ist liegt die Präferenz bei Bildern deut­lich bei Bildern des MIME Tpys image/png und image/jpeg. In dem vor­her genann­ten Beispiel wür­de der Server folg­lich eher PNGs oder JPEGs zurück­sen­den als etwa Gifs. Über den Wildcard-Mime-Typ */* bringt der Client zum Ausdruck, dass er auch mit ande­ren Formaten zurecht­kommt bezie­hungs­wei­se die­se zumin­dest emp­fängt (auch wenn er dann nicht unbe­dingt wis­sen muss, was er mit ihnen anfängt).

Der Accept-Header des Internet Explorers ist für Content Negotiation nicht unbe­dingt hilf­reich:

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

In dem Header wer­den weder die Contenttypen HTML, noch XML oder XHTML erwähnt. Das erschwert Content Negotiation auf der Serverseite ganz erheb­lich. Nehmen wir etwa an, dass der Server die Daten in XML Dateien vor­lie­gen hat, die über ein XSL Stylesheet im Idealfall auf Clientseite dar­ge­stellt wer­den. Sollte der Browser kein XML unter­stüt­zen, so soll der Server die Aufgabe der Formatierung von XML und XSL in HTML über einen XSLT-Prozessor über­neh­men.

Eine sol­che Negotiation wür­de erlau­ben, dass die XSLT Transformation über den Server nur dann vor­ge­nom­men wird, wenn die­se auch wirk­lich benö­tigt wird. Da der Internet Explorer in sei­nem Accept kei­ne Angaben zu XML oder gar HTML macht, wüss­te der Server, der mit einem sol­chen Accept umzu­ge­hen hat, nicht, was er mit einer sol­chen Anfrage machen soll. Den Accept-Header, den der Internet Explorer sen­det, kann man nur mit Mühe über die Registry ver­än­dern.

Wie in der Einleitung schon ange­spro­chen, gibt es auch die Möglichkeit, die Sprachauswahl des Servers über die HTTP – Anfrage direkt zu beein­flus­sen. In der Anfrage sen­det der Browser näm­lich auch einen Teil, der etwa wie folgt aus­se­hen könn­te.

      Accept-Language: de, en; q=0.5

Das heißt, der Client kann sowohl mit Englisch als auch Deutsch umge­hen, wobei die Präferenz bei Deutsch liegt. Die Einstellung der akzep­tier­ten Sprachen kann beim Internet Explorer über das Menü “Internetoptionen – Sprachen” ver­än­dert wer­den.

Sprachauswahl im Internet Explorer

Nachdem die grund­le­gen­den Ideen von Content Negotiation auf Clientseite erläu­tert wur­den, nähern uns wir jetzt der kon­kre­ten Anwendung – d.h. wie man Content Negotiation auf der Serverseite nut­zen kann.

Grundsätzlich gibt es mit dem Apache Webserver, bei dem das Modul Content Negotiation akti­viert ist, zwei Möglichkeiten die­ses zu nut­zen.

Zum einen kann man spe­zi­fisch einen Fall unter­su­chen und alle Alternativen bei­spiels­wei­se für ver­schie­de­ne Sprachen ange­ben; zum ande­ren kann man gene­rell den Server die Aufgabe über­tra­gen, nach Alternativen zu suchen und die für den Client pas­sen­de zurück­zu­ge­ben.

Zunächst soll die expli­zi­te Variante vor­ge­stellt wer­den; dabei wer­den Type Maps ver­wen­det. Eine Type Map ist eine Datei, die genaue Angaben zu den vor­han­de­nen Alternativen für ein Dokument oder gene­rell eine Datei hat. Um Type Maps ver­wen­den zu kön­nen, müs­sen die­se in der Server-Konfiguration akti­viert sein. In der Regel ist die Dateiendung für Type Maps *.var. Eine ein­fa­che Type Map könn­te wie folgt aus­se­hen:

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önn­te wie folgt aus­se­hen:

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

Die Type Map besagt, dass es von dem ange­for­der­ten “dia­gramm” zwei Versionen gibt – zum einen ein GIF, zum ande­ren 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 lie­fert der Browser die Datei diagramm.jpeg zurück

Falls ver­schie­de­ne Sprachen für das Dokument vor­lie­gen, so könn­te die Anfrage wie folgt aus­se­hen:

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 wie­der­um ein­fach über den Dateinamen. Anhand der vor­han­de­nen Type Map erkennt der Server die Anzahl der Varianten und lie­fert als Ergebnis die zu den Präferenzen des Clients pas­sen­de Seite.

Falls es kei­ne pas­sen­de Seite zu den Wünschen des Clients gibt, so gene­riert Apache eine Fehlermeldung 406 und lis­tet alle vor­han­de­nen Alternativen auf; unter die­sen kann der Besucher sich dann ent­schei­den.

Die Verwendung von Type Maps ist dar­auf aus­ge­rich­tet, ein expli­zi­tes Problem zu lösen. Wenn man jedoch gene­rell meh­re­re Versionen eines Dokumentes vor­lie­gen hat, zum Beispiel in ver­schie­de­nen Sprachen, ist es ein­fa­cher mit der zwei­ten Variante das Problem zu lösen – mit den Multiviews. Dabei gene­riert sich der Webserver qua­si selbst eine Type Map für jede Anfrage.

Hierzu muss die Option “MultiViews” akti­viert wer­den. Dies kann mit einer .htac­cess-Datei gesche­hen. Der Eintrag in der .htac­cess Datei sieht wie folgt aus:

Beispiel .htac­cess

      Options +MultiViews

Wird die­se Option akti­viert, wird bei einer Anfrage nach “test” gene­rell genau so ver­fah­ren, wie bei den Type Maps. Der Server erkennt die vor­han­de­nen Varianten und lie­fert die­se nach den Präferenzen des Clients. Wichtig ist dabei, dass die Varianten die Dateinamen gemäß der Form test.html.de bzw. test.html.en tra­gen müs­sen; anhand des Sprachsuffixes erkennt der Server den Sprachtyp. Dieser rich­tet sich nach den inter­na­tio­na­len Sprachcodes (nach dem RFC 1766 Standard).

Der Vorteil dabei ist, dass man, wenn man etwa Links setzt, nicht immer den Sprachsuffix hin­zu­fü­gen muss. Gelinkt wird schlicht auf die Seite “test”, der Server erkennt dann auto­ma­tisch an den Browsereinstellungen, wel­che Seite er zu lie­fern hat. Das ver­rin­gert den Pflegeaufwand deut­lich, da man für alle Sprachversionen die glei­chen Links ver­wen­den kann. (tm)

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.

Schreibe einen Kommentar

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