Apache - Content Negotiation 
 von Lars Eilebrecht   

Der Apache hat durch das Negotiation-Moduls die Fähigkeit, seine Antworten an die Wünsche und Fähigkeiten des Web-Clients anzupassen. Liegt ein Dokument beispielsweise in deutscher und englischer Sprache vor, so kann der Apache aus Basis der Client-Anfrage automatisch entscheiden, welche der beiden Varianten zurückgeliefert werden soll. 

Funktionsprinzip [zurück] 

Der Apache hat die Fähigkeit, eine Antwort an die Wünsche und Fähigkeiten des Web-Clients anzupassen. Der Web-Client handelt quasi bei einem Zugriff aus (daher resultiert der Begiff Content Negotiation), welche Variante einer Datei er gerne hätte. Liegt eine Bilddatei beispielsweise in den Formaten PNG, GIF und JPG vor, so könnte an einen Client der PNG-Dateien (Portable Network Graphic) verarbeiten kann, diese Variante des Bildes geliefert werden. Die Auswahl einer geeigneten Variante läuft hierbei für die Client-Seite transparent ab. 

Dieser Mechanismus wird als Transparent Content Negotiation oder manchmal auch als Content Arbitration bezeichnet. 

Auf der Seite des Apache ist - abgesehen von der Erstellung der verschiedenen Dateivarianten - die Erstellung einer Type-Map oder der Aktivierung einer sogenannten MultiViews-Suche notwendig. 

[Content Negotiation]
 Auskunft über seine Fähigkeiten gibt ein Web-Client in den HTTP-Headern, die er beim Zugriff an den Web-Server übermittelt. Zu nennen sind hier die HTTP-Header Accept, Accept-Charset, Accept-Encoding und Accept-Language. Resultierend aus diesen vier HTTP-Headern ergeben sich somit vier Möglichkeiten, auf deren Basis der Apache entscheiden kann, was für eine Variante er an den Client zurückliefern soll: 

Konfiguration [zurück] 

Bevor wir jedoch zur Anwendung der Content Negotiation kommen, sollen zunächst die dafür notwendigen Konfigurationsschritte betrachtet werden. 

Type-Maps

Unter einer Type-Map versteht man eine Datei, die Angaben zu den verschiedenen Varianten enthält, die sich hinter einem URL verbergen. Liegt ein Dokument beispielsweise im HTML- und PDF-Format vor, so werden diese Dateien in der Map aufgeführt und der jeweilige MIME-Typ kenntlich gemacht. 

Aktiviert werden Type-Maps über die Zuweisung des Handlers type-map zu einer Dateiendung, wobei typischerweise die Endung .var (für variant) benutzt wird. 

     AddHandler type-map var
Gibt man die AddHandler-Anweisung global in der Server-Konfiguration an, so werden Dateien mit der Endung .var in allen Verzeichnissen des Web-Servers als Type-Maps deklariert. Will man die Nutzung der Type-Maps einschränken, so bietet sich eine Beschränkung auf bestimmte Verzeichnisse an, z.B.: 
     <Location /test>
     AddHandler type-map var
     </Location>

MultiViews

Die Erstellung von Type-Maps ist relativ zeitaufwendig, da zu jeder Datei, die in verschiedenen Varianten vorliegt, eine entsprechende Type-Map erstellt werden muß. Einfacher gestaltet sich die Content Negotiation, wenn man die MultiViews-Funktionalität des Apache einsetzt. Dies ist jedoch nicht so flexibel wie der Einsatz von Type-Maps. 

Aktiviert wird die MultiViews-Suche über die Option MultiViews, die, wie im folgenden Beispiel, typischerweise auf bestimmte Verzeichnisse beschränkt wird: 

     <Location /test>
     Options +MultiViews
     </Location>
Zu beachten ist, daß die Option MultiViews die einzige Option ist, die nicht über die Anweisung Options All aktiviert wird. 

Der Ablauf einer MultiViews-Suche ergibt sich wie folgt: Bei einem Zugriff auf eine nicht existierende Datei, z.B. /test/page, in einem Verzeichnis, für das MultiViews aktiviert wurde, sucht der Apache intern nach allen Dateien /test/page.* und erstellt anhand der gefunden Dateien intern eine Type-Map, auf deren Basis dann entschieden wird, welche Datei an den Web-Client zurückgeliefert werden soll. Wird keine passende Datei gefunden, wird eine normale »Datei nicht gefunden«-Fehlermeldung an den Client zurückgeliefert. 

Die MultiViews-Suche wird in erster Linie angewendet, wenn Dokumente in verschiedenen Sprachen angeboten werden sollen, z.B. Deutsch und Englisch. Damit der Apache herausfinden kann, in welcher Sprache ein Dokument vorliegt, kennzeichnet man dies über einen zuvor via AddLanguage definierten Dateizusatz. Dieser Zusatz des Dateinamens entspricht in der Regel dem Sprachkürzel der jeweiligen Sprache, so wie es in ISO 639 definiert ist. 

Hier ein Beispiel für ein Dokument, das in englischer und deutscher Sprache vorliegt: 

     page.html.de
     page.html.en
Fordert ein Web-Client in einer Anfrage keine spezifische Sprache an, so wird das Dokument zurückgeliefert, das bezüglich der verwendeten Sprache die höchste Priorität hat. Gekennzeichnet wird dies in der Konfiguration durch die LanguagePriority-Anweisung. 

AddLanguage

 
Syntax AddLanguage Sprache Name [Name ...]
Modul mod_mime
Kontext Server-Konfiguration, <VirtualHost>, <Directory>, <Location>, .htaccess
 Sprache ist hierbei ein Sprachkürzel nach ISO 639, und Name kennzeichnet die Dateiendung, von denen mehrere angegeben werden können. 

Beispiele: 

     AddLanguage de .de
     AddLanguage en .en
     AddLanguage pl .po
Das letzte Beispiel fällt etwas aus dem Rahmen: Bei der polnischen Sprache sollte als Dateiendung nicht pl, sondern z.B. po verwendet werden, um Probleme mit eventuell vorhandenen Perl-Dokumenten zu vermeiden, die ja bekanntlich auch die Dateiendung .pl haben. 

LanguagePriority

 
Syntax LanguagePriority Sprache [Sprache ...]
Modul mod_negotiation
Kontext Server-Konfiguration, <VirtualHost>, <Directory>, <Location>, .htaccess
 Da nicht alle Browser respektive Web-Clients kenntlichmachen, welche Sprache sie bevorzugen, oder im ungünstigsten Fall gar keinen Accept-Language-Header mitschicken, läßt sich über die Konfigurationsanweisung LanguagePriority festlegen, welche Variante in solch einem Fall vom Apache zurückgeliefert werden soll. 

Beispiel: 

     LanguagePriority en de fr
Die zuerst angegebene Sprache hat hierbei die höchste Prioriät. Im obigen Beispiel haben somit englische Dokumente die höchste Priorität, deutsche Dokumente die zweithöchste und französische Dokumente die niedrigste Priorität. 

Übermittelt ein Client z.B. den Header 

     Accept-Language: de, en
so wird ihm das englische Dokumente übermittelt. 

Bei LanguagePriority sollte man darauf achten, nur die Sprachen anzugeben, die man auch auf dem Web-Server verwendet. 

Caching von Variationen

Das Caching von Dateien, die als Variation eines bestimmten URLs zurückgeliefert wurden, stellt prinzipiell ein Problem dar. Ein Nutzer beispielsweise, der nur Englisch spricht, wird sich nicht freuen, wenn er vom Proxy-Cache die deutsche Variante eines Dokuments erhält. In HTTP/1.1 wurden Mechanismen entwickelt, um genau dies zu verhinden, so daß man sich in solch einem Fall keinerlei Gedanken machen muß. Bei HTTP/1.0-Anfragen läßt sich dies jedoch nicht kontrollieren. Per Default sorgt der Apache dafür, daß eine Variation nicht in einem Proxy-Cache gespeichert wird, wenn es sich um eine HTTP/1.0-Anfrage gehandelt hat. Dieses Verhalten läßt sich jedoch mit der Anweisung CacheNegotiatedDocs außer Kraft setzen. 

CacheNegotiatedDocs

 
Syntax CacheNegotiatedDocs
Default (Caching von Variationen wird verhindert)
Modul mod_negotiation
Kontext Server-Konfiguration
 Die Konfigurationsanweisung CacheNegotiatedDocs hat keinerlei Optionen und sorgt, wenn sie in der Server-Konfiguration gesetzt wird, dafür, daß Variationen auch in einem Proxy-Cache gespeichert werden dürfen, wenn es sich bei der Anfrage um eine HTTP/1.0-Anfrage gehandelt hat. Im Zeitalter von HTTP/1.1 sollte man jedoch auf das Setzen dieser Konfigurationsanweisung verzichten, damit die Variationen in solch einem Fall nicht gespeichert werden. Sonst kommt es zu Problemen, weil an einen Client eine Varianten ausgeliefert wird, die er nicht verarbeiten kann oder will. 

Nutzung von Type-Maps und MultiViews [zurück] 

Type-Maps

Bei einer Type-Map handelt es sich um eine Textdatei, die Angaben zu allen Varianten einer bestimmten Ressource enthält. Kenntlich gemacht wird sie in der Regel über die Dateiendung .var. 

Aufbau einer Type-Map-Datei

Wie zuvor beschrieben, läßt sich eine Content Negotiation auf Basis von vier verschiedenen Variationen durchführen. Dies sind der MIME-Typ (Accept-Header), die Sprache (Accept-Language-Header), der Zeichensatz (Accept-Charset-Header) und die Kodierung (Accept-Encoding-Header). Zu jeder Variation können nun Angaben zu einer oder mehrerer dieser vier Arten der Content Negotiation in einer Type-Map gemacht werden. 

Eine Type-Map hat dasselbe Format wie Mail-Header (RFC822), wobei insgesamt sechs verschiedene Header vom Apache erkannt bzw. genutzt werden: 

URI 

Als URI wird der Dateiname relativ zum aktuellen Verzeichnis angegeben, also z.B. 

     URI: page.html
oder 
     URI: ../page.html
Die Angabe eines absoluten URI ist nicht möglich. 

Content-Type

Über den Content-Type-Header wird der MIME-Typ einer Variante und - durch Semikolon getrennt - der zugehörige Qualitätswert »qs« (quality score) definiert. Als zusätzlicher Parameter (charset) kann der in der Datei verwendete Zeichensatz angegeben werden. 

Der Content-Type-Header muß bei jeder Variante in einer Type-Map angegeben werden, auch wenn alle Varianten denselben MIME-Typ haben! 

Beispiele: 

     Content-Type: text/html
     Content-Type: image/gif; qs=0.5
     Content-Type: text/plain; qs=0.4; charset=iso-8859-5

Content-Length

Hiermit läßt sich die Größe der zugehörigen Datei in Bytes angeben. Der Apache ermittelt den korrekten Wert selbständig, falls der Content-Length-Header nicht angegeben wird. Auch die Angabe eines falschen Wertes scheint den Apache nicht sonderlich zu beeindrucken, denn bei Tests lieferte er immer den korrekten Wert (die Dateigröße) zurück, jedoch niemals einen absichtlich falsch angegebenen Wert. Die Angabe dieses Wertes erscheint somit unnötig. 

Content-Language

Die in der Datei verwendete Sprache (gemeint ist keine Programmiersprache, sondern eine natürliche Sprache wie z.B. Deutsch oder English) wird über Content-Language kenntlich gemacht. Als Wert wird dabei das zweistellige Kürzel für die jeweilige Sprache verwendet, so wie es in ISO 639 definiert ist. 

Beispiel: 

     Content-Language: de
Da es aber auch unterschiedliche Varianten innerhalb einer Sprache geben kann, kann bei Bedarf auch ein zweistelliges Länderkürzel angehängt werden, z.B. unterscheidet sich das Englisch, das in den USA gesprochen wird, vom Englisch, das in Großbritannien gesprochen wird. 

Sprach- und Länderkennzeichnung werden durch ein »-« getrennt. 

Beispiel: 

     Content-Language: en-GB
Fordert ein Client beispielsweise die Sprache »en-GB« an, so wird ihm die »en-GB«-Variante oder - falls diese nicht verfügbar ist - die »en«-Variante zurückgeliefert. Andersherum erhält er die »en-GB«-Variante, wenn er »en« übermittelt hat, aber keine andere englischsprachige Variante vorliegt. 

Vergleiche hierzu die HTTP/1.1-Spezifikationen in RFC 2068. 

Content-Encoding

Wurde eine Datei mit compress oder gzip kodiert, so läßt sich dies über Content-Encoding deutlich machen. 

Beispiele: 

     Content-Encoding: gzip
     Content-Encoding: compress

Description

Wie der Name des Headers schon suggeriert, läßt sich über diesen optionalen Description-Header eine Kurzbeschreibung der jeweiligen Variante angeben. Der Apache gibt diese Beschreibungen aus, wenn er keine passende Variante gefunden hat, die den Anforderungen des Web-Clients gerecht wird. Dies geschieht in Form einer Fehlermeldung (Statuscode 406, Not Acceptable), die alle verfügbaren Varianten zusammen mit der Kurzbeschreibung auflistet und an den Client schickt. Der Nutzer kann dann bei Bedarf selbständig die Variante auswählen, die ihm am ehesten zusagt. 

Hier ein Beispiel solch einer Fehlermeldung: 

[Beispiel-Fehlermeldung]
 Enthält die Beschreibung Leerzeichen, muß sie in Anführungszeichen gesetzt werden. 

Beispiele: 

     Description: "Original english version"
     Description: "German HTML document"
     Description: Blafasel
Jeder der oben genannten Header darf mehrfach in einer Type-Map auftreten, allerdings pro Dateivariante nur einmal. Jede Beschreibung einer Variante enthält mindestens den URI-Header und den Content-Type-Header und wird durch eine Leerzeile von den Beschreibungen der anderen Varianten getrennt. Zeilen, die mit »#« beginnen, werden als Kommentar angesehen und nicht weiter beachtet. 

Beispiel einer Type-Map-Datei: 

    #
    # type-map: /test/page.var
    # 
    
    URI: page.de.html
    Content-Type: text/html; qs=0.8
    Content-Language: de
    Description: "German HTML document"
    
    URI: page.en.html
    Content-Type: text/html; qs=0.8
    Content-Language: en 
    Description: "English HTML document"
    
    URI: page.txt
    Content-Type: text/plain; qs=0.1
    Content-Language: en
    Description: "English plain text document"
    
    URI: page.pdf
    Content-Type: application/pdf; qs=1
    Content-Language: en
    Description: "English PDF document"
Ein Zugriff auf den URL http://www.domain.tld/test/page.var würde eine der Varianten page.de.html, page.en.html, page.txt oder page.pdf zurückliefern. Falls der Client nur Dokumente in deutscher Sprache haben möchte, so würde ihm ohne weitere Nachfrage die deutsche Version des HTML-Dokuments page.de.html übermittelt, auch wenn er PDF-Dokumenten eine höhere Präferenz einräumt. Aktzeptiert er hingegen auch Dokumente in englischer Sprache, würde ihm die Variante page.pdf übermittelt, da sie den höchsten Qualitätswert »qs« hat. 

Der Web-Client sagt, was er will

Auf welche Weise ein Web-Client kenntlich macht, welche Formate er verarbeiten kann respektive welchen Varianten der Nutzer den Vorzug gibt, ist im folgenden für die einzelnen Arten der Content Negotiation zusammengefaßt. 

Type Negotiation

Im Accept-Header übermittelt der Web-Client die verschiedenen MIME-Typen, die er verarbeiten kann bzw. verarbeiten will, z.B. text/html, image/png oder application/pdf, um nur einige zu nennen. Zusätzlich zum Typ selbst, kann der Client einen Qualitätswert angeben, d.h. er kennzeichnet, inwieweit er einen Typ gegenüber einem anderen bevorzugt. Der Qualitätswert »q« reicht hierbei von 0 bis 1, wobei ein höherer Wert eine höhere Präferenz für den jeweiligen Typ anzeigt. 

Beispiel-Header: 

     Accept: image/png;q=1, image/gif;q=0.5, image/jpeg;q=0.7
Der obige Beispiel-Header bringt zum Ausdruck, daß der Client die Image-Formate PNG, GIF und JPG verarbeiten kann und dabei PNG-Dateien den Vorzug gibt (q=1). Liegt keine PNG-Variante vor, so liefert der Apache die JPEG-Datei oder, falls diese auch nicht vorhanden ist, die GIF-Datei zurück. Kann keinem der Wünsche des Web-Clients entsprochen werden, so antwortet der Apache, wie schon zuvor gesagt, mit einer 406-Fehlermeldung. 

Beispiel einer Type-Map für die drei Dateien bild.png, bild.gif und bild.jpg

     #
     # type-map: bild.var
     #
     
     URI: bild.png
     Content-Type: image/png; qs=0.6
     Description: "Truecolor PNG image"
     URI: bild.gif
     Content-Type: image/gif; qs=1
     Description: "256color GIF image"
        
     URI: bild.jpg
     Content-Type: image/jpeg; qs=0.6
     Description: "Truecolor JPEG image with 70% quality-level"
Würde ein Client auf bild.var zugreifen und dabei den oben angegebenen Beispiel-Header übermitteln, so würde die PNG-Variante vom Apache zurückgeschickt. Die Qualitätswerte der Client-Anfrage werden mit den Qualitätswerten der Type-Map kombiniert, und die bestmögliche Kombination wird an den Client ausgeliefert. Hätte der Client als Qualitätswert für den MIME-Typ image/png den Wert 0.5 angegeben, so wäre ihm vom Apache die GIF-Variante des Bildes übermittelt worden. 

Language Negotiation

Liegt ein Dokument in mehreren verschiedenen Sprachen, wie z.B. Deutsch und Englisch vor, so kann auf Basis des Accept-Language-Header die gewünschte Variante zurückgeliefert werden. 

Beispiel-Header: 

     Accept-Language: de, en;q=0.9, fr;q=0.2
Verbal ausgedrückt, bedeutet der Header: »Ich bevorzuge Deutsch, aber nehme auch Englisch und im Notfall sogar Französisch.« 

Beispiel einer Type-Map für ein HTML-Dokument, das in den Sprachen Deutsch, Englisch und Französisch vorliegt: 

     #
     # type-map: page.var
     #
     
     URI: page.html.de
     Content-Type: text/html
     Content-Language: de
     Description: "German document (original version)"
     
     URI: page.html.en
     Content-Type: text/html
     Content-Language: en
     Description: "English document (translated version)"
     
     URI: page.html.fr
     Content-Type: text/html
     Content-Language: fr
     Description: "French document (translated version)"
Betrachtet man einen Zugriff auf page.var mit obigem Beispiel-Header, so würde die deutsche Version des HTML-Dokuments an den Client übermittelt. 

Charset Negotiation

Der Accept-Charset-Header gibt Auskunft darüber, welche Zeichensätze der Web-Client verarbeiten kann. Der Standardzeichensatz für HTML-Dokumente ist ISO-8859-1. 

Beispiel-Header: 

     Accept-Charset: iso-8859-1, unicode-1-1;q=0.8
Beispiel einer Type-Map für zwei HTML-Dokumente: 
     #
     # type-map: page.var
     #
     
     URI: page.html
     Content-Type: text/html; qs=1; charset=iso-8859-1
     Description: "test document (iso)"
     
     URI: page.uni.html
     Content-Type: text/html; qs=1; charset=unicode-1-1
     Description: "test document (unicode)"

Encoding Negotiation

Über den Accept-Encoding-Header zeigt der Web-Client an, ob und welche Arten von Kodierungen er akzeptiert. 

Beispiel-Header: 

     Accept-Encoding: gzip, compress
Beispiel einer Type-Map für ein Postscript-Dokument: 
     #
     # type-map: info.var
     #
     
     URI: info.ps.Z
     Content-Type: application/postscript
     Content-Encoding: compress
     Description: "info document (compress)"
     
     URI: info.ps.gz
     Content-Type: application/postscript
     Content-Encoding: gzip
     Description: "info document (gzip)"
Je nachdem, ob ein Client compress oder gzip akzeptiert, wird vom Apache entweder info.ps.Z oder info.ps.gz zurückgeliefert. Falls ein Client beide Kodierungsformate akzeptiert, wird eine der beiden Varianten ausgeliefert werden, jedoch kann nicht vorherbestimmt werden, welche dies ist (bei der jetzigen Implementierung des Negotiation-Moduls würde die zuletzt genannte Variante aus der Type-Map genommen). Gibt man einen entsprechenden Qualitätswert beim Content-Type-Header an, läßt sich eine Präferenz bezüglich der beiden Formate festlegen. 

Kombination verschiedener Varianten

Wie schon in einem vorhergehenden Beispiel gezeigt, läßt sich eine Type-Map nicht nur für jeweils eine Variation erstellen, sondern es lassen sich beliebige der zuvor genannten Arten der Content Negotiation kombinieren. 

Hier ein Beispiel für ein Dokument, das als HTML- und TXT-Datei, jeweils in zwei verschiedenen Zeichensätzen und jeweils in deutscher und englischer Sprache vorliegt: 

     #
     # type-map: extrem.var
     #
     
     URI: extrem-iso.html.de
     Content-Type: text/html; qs=0.9; charset=iso-8859-1
     Content-Language: de
     Description: "German HTML document, iso-8859-1"

     URI: extrem-iso.html.en
     Content-Type: text/html; qs=0.9; charset=iso-8859-1
     Content-Language: en
     Description: "English HTML document, iso-8859-1"

     URI: extrem-iso.txt.de
     Content-Type: text/plain; qs=0.2; charset=iso-8859-1
     Content-Language: de
     Description: "German plain text document, iso-8859-1"

     URI: extrem-iso.txt.en
     Content-Type: text/plain; qs=0.2; charset=iso-8859-1
     Content-Language: en
     Description: "English plain text document, iso-8859-1"

     URI: extrem-uni.html.de
     Content-Type: text/html; qs=0.9; charset=unicode-1-1
     Content-Language: de
     Description: "German HTML document, unicode-1-1"
     URI: extrem-uni.html.en
     Content-Type: text/html; qs=0.9; charset=unicode-1-1
     Content-Language: en
     Description: "English HTML document, unicode-1-1"

     URI: extrem-uni.txt.de
     Content-Type: text/plain; qs=0.2; charset=unicode-1-1
     Content-Language: de
     Description: "German plain text document, unicode-1-1"

     URI: extrem-uni.txt.en
     Content-Type: text/plain; qs=0.2; charset=unicode-1-1
     Content-Language: en
     Description: "English plain text document, unicode-1-1"

MultiViews

Wie am letzten Beispiel zu erkennen ist, ist die Erstellung von Type-Maps relativ zeitaufwendig. Da der Apache an der Dateiendung sowieso in der Regel erkennen kann, welchen MIME-Typ oder welche Kodierung eine Variante hat, könnte er die Type-Maps prinzipiell selbst erstellen. 

Genau diese Funktionalität verbirgt sich hinter der MultiViews-Suche, die jedoch nicht so flexibel einsetzbar ist wie Type-Maps. 

Die Konfiguration und der Ablauf einer MultiViews-Suche wurde bereits zuvor im Konfigurationsabschnitt erläutert und soll hier nicht noch einmal betrachtet werden. 

Die Funktion einer MultiViews-Suche ist identisch zu einer Type-Map, mit dem Unterschied, daß man selbst keinerlei Type-Map-Dateien erstellen muß, aber hierdurch auch etwas an Flexibilität verliert. 

Anwendungsbeispiel: 

Das Verzeichnis /test enthält die drei Dateien page.html, page.txt und page.pdf. Ein Client greift auf http://www.domain.tld/test/page zu und sendet dabei den folgenden Accept-Header: 

     Accept: text/html;q=1, text/plain;q=0.5, application/pdf;q=0.8
Der Apache übermittelt in diesem Fall die Datei page.html, da der Client hierfür den höchsten Qualitätswert angegeben hat. Gibt der Client keine Qualitätswerte für die verschiedenen MIME-Typen an, kann nicht vorhergesagt werden, welche der drei Varianten ihm übergeben wird. Hier wirkt sich der Nachteil der geringeren Flexibilität der MultiViews-Suche aus, da man selbst keine Präferenzen für die einzelnen Formate vergeben kann. 

Die Verwendung von MultiViews ist in solchen Fällen somit weniger geeignet. Ganz unmöglich ist die Verwendung einer MultiViews-Suche, wenn Varianten in verschiedenen Zeichensätzen vorliegen, da dies nur in einer Type-Map angegeben und nicht über eine Dateiendung kenntlich gemacht werden kann. 

Hervorragend eignet sich eine MultiViews-Suche jedoch, wenn man Dokumente in verschiedenen Sprachen anbietet. 

Language Negotiation

Wie schon zuvor beschrieben, kennzeichnet man die Sprache eines Dokuments durch einen Zusatz im Dateinamen, der typischerweise dem Sprachkürzel der Sprache laut ISO 639 entspricht. 

Ein Dateiname ist nach folgender Regel aufgebaut: Name.Typ.Sprache.Kodierung 

Beispiele: 

     page.html.de
     info.txt.de.gz
In einem Hyperlink würde man auf page.html bzw. info.txt verweisen. 

Der Apache verarbeitet jedoch auch Dateinamen der folgenden Art: 

     page.de.html
Als Hyperlink würde in solch einem Fall page ohne weitere Dateiendung benutzt. 

Damit der Apache auch weiß, daß z.B. »de« für Deutsch und »en« für Englisch steht, zeigt man ihm dies über die Konfigurationsanweisung AddLanguage an. Falls ein Web-Client keinen Accept-Language-Header übermittelt, wird eine Variante ausgewählt, die der angegebenen LanguagePriority entspricht. 

Online-Ressourcen [zurück] 

 

Der Autor [zurück] 

 

Lars Eilebrecht studiert - sofern er nicht gerade Bücher über Apache schreibt - Technische Informatik an der Uni-GH Siegen und ist Mitglied der dortigen Unix-AG. In erster Linie betreut er die Web-Server der Unix-AG, sowie den zentralen Web-Server der Universität. Sofern es die Zeit erlaubt engagiert sich der Autor beim Apache-Projekt, vorwiegend im Rahmen der Betreuung der Bug-Report-Database. 
E-Mail: sfx@unix-ag.org 
 
    © 1998 Lars Eilebrecht, International Thomson Publishing GmbH  A P A C H E