German translation Content Negotiation

[Jobst Giesecke]

Title: Content Negotiation

Der Apache-Server unterstützt die Content Negotiation, wie sie in der HTTP/1.1-Spezifikation beschrieben wird. Er kann anhand der vom Browser angegebenen Präferenzen für den Medientyp, die Sprachen, Zeichensatz und Verschlüsselung die beste Darstellungsform für eine Ressource wählen. Außerdem implementiert er eine Reihe von Eigenschaften für ein intelligenteres Handling bei Browser-Anfragen mit unvollständigen Angaben zum Inhaltstyp.

Für die Content Negotiation ist das standardmäßig kompilierte Modul mod_negotiation zuständig.

Eine Ressource kann in unterschiedlichen Darstellungsarten vorliegen, beispielsweise in unterschiedlichen Sprache und/oder verschiedenen Medientypen. Damit die entsprechende Auswahl getroffen werden kann, kann dem Benutzer eine Indexseite mit den Optionen angezeigt werden. Häufig kann der Server die Auswahl aber auch automatisch treffen. Das ist möglich, weil der Browser mit seiner Anfrage Header zur bevorzugten Darstellungsform senden kann. So kann der Browser beispielsweise angeben, dass er die Informationen am liebsten in Französisch oder falls das nicht möglich ist, auf Englisch angezeigt bekommen möchte. Mit folgendem Header kann der Browser französische Dokumente anfordern:

Accept-Language: fr

Diese Präferenzen werden nur berücksichtigt, wenn eine Auswahl in unterschiedlichen Sprachen vorhanden ist.

Um ein etwas ausführlicheres Beispiel zu zeigen, wurde der Browser im folgenden so konfiguriert, dass er Französisch und Englisch akzeptiert. Ferner akzeptiert er unterschiedliche Medientypen, wobei er HTML gegenüber einfachem Text oder anderen Textformaten vorzieht. Außerdem zieht er die Formate GIF oder JPEG anderen Medientypen gegenüber vor, lässt aber als letzten Ausweg auch andere Typen zu:

Accept-Language: fr; q=1.0, en; q=0.5
Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1

Der Apache unterstützt eine servergesteuerte Content Negotiation, wie sie in HTTP/1.1-Spezifikation beschrieben wird. Er unterstützt die Anfrage-Header Accept, Accept-Language, Accept-Charset und Accept-Encoding ohne Einschränkungen. Ferner unterstützt er die sogenannte transparente Content Negotiation, bei der es sich um eine experimentelle Variante nach RFC 2295 und RFC 2296 handelt. Die in diesen RFCs definiert "Feature Negotiation" wird nicht unterstützt.

Eine Ressource ist eine Entität, die über einen URI (RFC 2396) identifiziert wird. Ein HTTP-Server wie der Apache gewährt innerhalb seines Namespace Zugriff auf Repräsentationen der Ressource(n), wobei es sich bei jeder Repräsentation um eine Sequenz von Bytes eines definierten Medientyps, Zeichensatzes, einer Verschlüsselung usw. handelt. Jede Ressource kann zu jedem Zeitpunkt mit keiner, einer oder mehreren Repräsentationen verknüpft werden. Stehen mehrere Repräsentationen zur Verfügung, wird die Ressource als aushandelbar (engl. negotiable) und jede der Repräsentationen wird als Variante bezeichnet. Die unterschiedlichen Varianten einer aushandelbaren Ressource legen die Dimensionen der Verhandlung fest.

Für das Aushandeln von einer Ressource zu sendenden Repräsentation benötigt der Server Informationen über die einzelnen Varianten, die er auf zwei Wegen erhalten kann:

• Über ein Typ-Map (eine *.var-Datei), das die Dateien mit den Varianten aufführt, oder mit einer
• MultiView-Suche, bei der der Server einen Vergleich mit einem Dateinamensmuster vornimmt und unter den Ergebnissen auswählt.

Ein Typ-Map ist ein Dokument, das mit dem Handler type-map verknüpft ist (entspricht bei älteren Apache-Versionen dem MIME-Typ application/x-type-map). Um diese Möglichkeit nutzen zu können, muss in der Konfiguration ein Handler eingerichtet werden, der das Dateisuffix als type-map definiert. Das geschieht in der Serverkonfigurationsdatei wie folgt:

AddHandler type-map .var

Typ-Map-Dateien sollten die gleiche Bezeichnung wie die Ressource haben, die sie beschreiben, und für jede verfügbare Variante einen Eintrag enthalten. Diese Einträge sind zusammenhängende Zeilen mit HTTP-Format-Headern. Die Einträge für die unterschiedlichen Varianten werden durch Leerzeichen voneinander getrennt. Leerzeilen sind nicht zulässig. Es entspricht der Konvention, eine Map-Datei mit einem Eintrag für die kombinierte Entität als Ganzes zu beginnen (was jedoch nicht erforderlich ist und auch ignoriert wird). Im folgenden Beispiel für eine Map-Datei (foo.var) wird eine Ressource mit der Bezeichnung foo beschrieben.

URI: foo

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

URI: foo.fr.de.html
Content-type: text/html;charset=iso-8859-2
Content-language: fr, de

Dabei ist zu beachten, dass eine Typ-Map-Datei Vorrang vor der Dateinamenserweiterung hat, auch wenn Multiviews aktiviert sind. Besitzen die Varianten unterschiedliche Qualitäten, kann das mit dem Parameter qs für den Medientyp angegeben werden (für JPEG, GIF oder ASCII-Art):

URI: foo

URI: foo.jpeg
Content-type: image/jpeg; qs=0.8

URI: foo.gif
Content-type: image/gif; qs=0.5

URI: foo.txt
Content-type: text/plain; qs=0.01

Die qs-Werte können zwischen 0.000 und 1.000 liegen. Eine Variante mit dem Wert 0.000 wird niemals ausgewählt. Varianten ohne qs-Parameter erhalten automatisch den Faktor 1.0. Dieser Wert gibt die relative "Qualität" einer Variante im Vergleich zu anderen Varianten an, wobei die Darstellungsmöglichkeiten des Client unberücksichtigt bleiben. Eine JPEG-Datei besitzt zum Beispiel in der Regel eine höhere Qualität für die Darstellung eines Fotos als eine ASCII-Datei. Handelt es sich bei der darzustellenden Ressource jedoch um reine ASCII-Darstellung, dann hat das ASCII-Format eine bessere Qualität als eine JPEG-Darstellung. Der qs-Wert ist also je nach der Art der Ressource spezifisch für eine bestimmte Variante.

Eine vollständige Liste der Header finden Sie in der Beschreibung der Direktive mod_negotation typemap.

MultiViews sind eine Option auf Verzeichnisebene, d.h. sie können mit einer Options-Direktive in den Abschnitten Directory , Location oder Files in der Datei httpd.conf oder (wenn AllowOverride korrekt gesetzt ist) in den .htaccess-Dateien aktiviert werden. Beachten Sie, dass die Aktivierung mit Options All MultiViews nicht erfolgen kann, dies muss ausdrücklich geschehen.

MultiViews bewirken folgendes: Der Server erhält eine Anfrage nach /some/dir/foo und für /some/dir wurde die Option MultiViews aktiviert. Wenn /some/dir/foo nicht existiert, sucht der Server im Verzeichnis nach Dateien mit der Bezeichnung foo.* und simuliert auf diese Weise ein Typ-Map, das alle diese Dateien aufführt, dem der gleiche Medientyp und die gleiche Inhaltsverschlüsselung zugewiesen wird, als hätte der Client eine von ihnen mit Namen angefordert. Der Server wählt die Übereinstimmung aus, die der Anfrage des Client am nächsten kommt.

MultiViews können auch für Suchen nach der mit der DirectoryIndex-Direktive angegebenen Datei benutzt werden, wenn der Server versucht, ein Verzeichnis zu indizieren. Steht in den Konfigurationsdateien

DirectoryIndex index

kann der Server zwischen index.html und index.html3 unterscheiden, falls beide vorhanden sind. Ist keine von beiden vorhanden, dafür aber die Datei index.cgi, dann führt der Server sie aus.

Besitzt keine der im Verzeichnis gefundenen Dateien eine von mod_mime erkannte Dateinamenserweiterung, mit der der Zeichensatz, Inhaltstyp, die Sprache oder die Verschlüsselung bestimmt werden können, hängt das Ergebnis von den Einstellungen der MultiViewsMatch-Direktive ab. Diese Direktive legt fest, welche Handler, Filter und anderen Dinge bei der MultiViews Negotiation berücksichtigt werden.

Nachdem der Apache entweder aus einer Typ-Map-Datei oder über die Dateien im Verzeichnis eine Liste der Varianten für eine Ressource ermittelt hat, ruft er eine von zwei Methoden auf, um zu entscheiden, welches die geeignetste Variante ist. Um die Content Negotiation nutzen zu können, müssen Sie die Details der tatsächlich durchgeführten Verhandlungen nicht kennen, die für den Interessierten im verbleibenden Teil dieses Dokuments aber beschrieben werden.

Es gibt zwei Verhandlungsmethoden:

1. Im Normalfall wird die servergesteuerte Verhandlung mit dem Apache-Algorithmus verwendet, auf den im weiteren Verlauf noch genauer eingegangen wird. Wird dieser Algorithmus benutzt, kann der Apache manchmal den Qualitätsfaktor einer bestimmten Dimension beeinflussen, um ein besseres Ergebnis zu erzielen. Wie dies geschieht, wird weiter unter erläutert.
2. Die transparente Content Negotiation wird verwendet, wenn der Browser sie über einem im RFC 2295 beschriebenen Mechanismus verlangt. Bei dieser Verhandlungsmethode hat der Browser die vollständige Kontrolle über die Entscheidung, welches die geeignetste Variante ist. Das Ergebnis hängt daher von den speziellen Algorithmen ab, die der Browser benutzt. Im Verlauf der transparenten Verhandlung kann der Browser den Apache auffordern, die im RFC 2296 definierten "remote variant selection algorithm" zu verwenden.

Dimension	Anmerkungen
Medientyp	Der Browser gibt im Header-Feld Accept Präferenzen für den Medientyp an. Jede Angabe kann einen Qualitätsfaktor besitzen. Auch die Variantenbeschreibung kann einen Qualitätsfaktor besitzen (der Parameter "qs").
Sprache	Mit dem Header-Feld Accept-Language gibt der Browser Präferenzen für die Sprache an. Jede Angabe kann einen Qualitätsfaktor besitzen. Varianten können keiner, einer oder mehreren Sprachen zugeordnet werden.
Verschlüsselung	Im Header-Feld Accept-Encoding gibt der Browser Präferenzen für die Verschlüsselung an. Jede Angabe kann einen Qualitätsfaktor besitzen.
Zeichensatz	Im Header-Feld Accept-Charset gibt der Browser seine Präferenzen für den Zeichensatz an. Jede Angabe kann einen Qualitätsfaktor besitzen. Die Varianten können als Parameter des Medientyps einen Zeichensatz angeben.

Der Apache wählt mit dem folgenden Algorithmus die geeignetste Variante aus (falls es eine gibt), die an den Browser gesendet wird. Dieser Algorithmus kann nicht weiter konfiguriert werden. Er funktioniert folgendermaßen:

1. Für jede Verhandlungsdimension wird das entsprechende Accept*-Header-Feld überprüft und jeder Variante eine Qualität zugewiesen. Geht aus dem Accept*-Header für eine Dimension hervor, dass diese Variante nicht akzeptabel ist, wird sie ausgeschlossen. Bleiben keine Varianten übrig, wird mit Schritt 4 fortgefahren.
2. Über ein Eliminierungsverfahren wird die geeignetste Variante ausgewählt. Jeder der folgenden Tests wird der Reihe nach durchgeführt. Die bei den Test nicht gewählten Varianten werden ausgeschlossen. Bleibt nach einem Test eine Variante übrig, wird sie als die geeignetste ausgewählt und mit Schritt 3 fortgesetzt. Bleiben mehrere Varianten übrig, wird der nächste Test durchgeführt.
   1. Der Qualitätsfaktor aus dem Accept-Header wird mit dem Qualitätsfaktor dieser Varianten für den Medientyp multipliziert und die Variante mit dem höchsten Wert ausgewählt.
   2. Die Varianten mit dem höchsten Qualitätsfaktor für die Sprache werden ausgewählt.
   3. Anhand der Sprachreihenfolge im Accept-Language-Header (falls vorhanden) oder über die Sprachreihenfolge in der LanguagePriority-Direktive (falls vorhanden) werden die Varianten mit der geeignetsten Übereinstimmung für die Sprache bestimmt.
   4. Die Varianten mit der höchsten Präferenz für den Medientyp werden ausgewählt (über den Parameter, mit dem die Version des text/html-Medientyps angegeben wird).
   5. Anhand der Accept-Charset-Header-Zeile werden die Varianten für den Zeichensatz ermittelt. Der Zeichensatz ISO-8859-1 ist akzeptabel, wenn er nicht explizit ausgeschlossen wird. Varianten mit dem Medientyp text/* ohne explizite Verknüpfung mit einem bestimmten Zeichensatz werden als ISO-8859-1 interpretiert.
   6. Auswahl der Varianten, deren Zeichensatzparameter nicht ISO-8859-1 sind. Gibt es solche Varianten nicht, werden alle ausgewählt.
   7. Auswahl der Varianten mit der geeignetsten Verschlüsselung. Gibt es Varianten mit einer für den Benutzeragenten akzeptablen Verschlüsselung, werden nur diese Varianten ausgewählt. Liegt eine Mischung aus verschlüsselten und nicht verschlüsselten Varianten vor, werden nur nicht die verschlüsselten gewählt. Sind alle Varianten verschlüsselt oder nicht verschlüsselt, werden alle ausgewählt.
   8. Auswahl der Varianten mit dem geringsten Inhaltsumfang.
   9. Auswahl der ersten Variante der verbleibenden Varianten. Das ist entweder die erste aus der Typ-Map-Datei oder, wenn Varianten über das Verzeichnis ermittelt wurden, diejenige, deren Dateiname bei einer Sortierung nach dem ASCII-Kode an erster Stelle steht.
3. Der Algorithmus hat jetzt die "geeignetste" Variante ermittelt und gibt sie als Antwort zurück. Der HTTP-Antwort-Header Vary wird gesetzt, um die Dimensionen der Verhandlung anzuzeigen (diese Informationen können vom Browser und für das Caching benutzt werden).
4. Wird dieser Punkt erreicht, wurde keine Variante ausgewählt (weil keine für den Browser akzeptabel war). Der zurückgegebene Status 406 und ein HTML-Dokument mit den verfügbaren Varianten signalisiert, dass keine Repräsentation aus der Liste akzeptabel war. Der HTTP-Header Vary wird ebenfalls gesetzt, um die Dimensionen der Varianz anzuzeigen.

Der Apache korrigiert manchmal die Qualitätswerte, was als Gegensatz zur strikten Interpretation durch den oben beschriebenen Algorithmus erscheinen mag. Dadurch soll der Algorithmus bessere Ergebnisse für Browser liefern, die keine vollständigen oder korrekten Informationen senden. Einige der beliebtesten Browser senden Accept-Header mit Informationen, die zu einer Auswahl der falschen Variante führen könnten. Sendet ein Browser vollständige und korrekte Informationen, werden diese Korrekturen nicht durchgeführt.

Der Accept:-Header gibt Präferenzen für Medientypen an. Dabei können auch Jokerzeichen verwendet werden, zum Beispiel "image/*" oder "*/*", wobei das Sternchen für eine beliebige Zeichenfolge steht:

Accept: image/*, */*

Dieser Header gibt an, dass nur mit "image/" beginnende Typen akzeptiert werden. Manche Browsers senden routinemäßig zusätzlich zu den explizit genannten Typen noch Typen mit Jokerzeichen:

Accept: text/html, text/plain, image/gif, image/jpeg, */*

Damit soll ausgedrückt werden, dass die explizit angegebenen Typen vorgezogen werden, andere Darstellungen aber, falls verfügbar, ebenfalls akzeptiert werden. Mit expliziten Qualitätsangaben soll etwas anderes ausgedrückt werden:

Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01

Die expliziten Typen werden ohne Qualitätsfaktor angegeben und übernehmen dadurch den Vorgabewert 1.0 (höchster Wert). Die Jokerzeichenangabe */* erhält die niedrige Stufe von 0.01, so dass andere Typen nur zurückgegeben werden, wenn keine Variante mit einem explizit aufgeführten Typ übereinstimmt.

Enthält der Accept:-Header keinen Qualitätsfaktor, setzt ihn der Apache für */* (falls vorhanden) auf 0.01, um das gewünschte Verhalten zu erreichen. Den Wert für Jokerzeichen der Form "type/*" setzt er auf 0.02 (damit sie gegenüber der Form "*/*" vorgezogen werden). Enthält ein Medientyp im Accept:-Header einen Qualitätsfaktor, werden diese Werte nicht berücksichtigt, so dass Anfragen von Browsern, die diese explizite Angabe machen, wie erwartet funktionieren.

Mit der Apache-Version 2.0 wurde der Algorithmus um einige Ausnahmen erweitert, damit ein Ausweg offen steht, wenn keine Sprache ausgehandelt werden konnte.

Sendet ein Client eine Anfrage und der Server findet keine Seite, die mit dem Header Accept-language des Browsers übereinstimmt, erhält der Client entweder die Meldung No Acceptable Variant oder eine Multiple Choices-Seite. Um diese Fehlermeldungen zu vermeiden, kann der Apache so konfiguriert werden, dass der Accept-language-Header in diesen Fällen ignoriert wird und ein Dokument gesendet wird, das nicht exakt der Anforderung des Client entspricht. Mit der ForceLanguagePriority-Direktive können diese Fehlermeldungen überschrieben und die Einschätzung des Servers durch die LanguagePriority -Direktive überschrieben werden.

Der Server versucht auch einen Vergleich mit Sprachuntergruppen durchzuführen, wenn keine Übereinstimmung gefunden wird. Fordert ein Client beispielsweise Dokumente in der Sprache en-GB (für Englisch/Großbritannien) an, muss der Server nach dem HTTP/1.1-Standard normalerweise eine Übereinstimmung mit en ablehnen. (In der Regel dürfte es sich hier um einen Konfigurationsfehler handeln, denn es ist sehr unwahrscheinlich, dass jemand zwar die britische Variante aber nicht englisch im Allgemeinen versteht. Leider sind viele Clients standardmäßig so konfiguriert.) Gibt es keine Übereinstimmung mit einer anderen Sprache und steht der Server vor der Alternative, eine Fehlermeldung (No Acceptable Variants) zu senden oder auf die Direktive LanguagePriority zurückzugreifen, ignoriert er die Untergruppierung GB. Implizit übernimmt der Server die übergeordnete Sprache mit einem niedrigen Qualitätswert in die Liste der vom Client akzeptierten Sprachen. Enthält die Client-Anfrage aber die Angabe en-GB; qs=0.9, fr; qs=0.8 und verfügt der Server über Dokumente mit der Angabe en und fr, dann wird das französische Dokument gesendet. Das muss so geschehen, um die Übereinstimmung mit der HTTP/1.1-Spezifikation zu erhalten und effektiv mit korrekt konfigurierten Clients arbeiten zu können.

Um darüber hinaus erweiterte Verfahren (wie Cookies oder spezielle URL-Pfade) für die Bestimmung der bevorzugten Sprache des Benutzers verwenden zu können, nutzt das Modul mod_negotiation seit der Apache-Version 2.0.47 die Umgebungsvariable prefer-language. Ist sie vorhanden und enthält sie ein entsprechendes Sprach-Tag, versucht mod_negotiation eine entsprechende Variante zu finden. Wird eine solche Variante nicht gefunden, wird die Verhandlung normal fortgesetzt.

SetEnvIf Cookie "language=(.+)" prefer-language=$1

Der Apache erweitert die transparente Content Negotiation (RFC 2295) wie folgt: In der Variantenliste wird ein neues {encoding ..}-Element zur Angabe von Varianten eingeführt, die nur bei einer bestimmten Verschlüsselung zur Verfügung stehen. Die Implementierung des RVSA/1.0-Algorithmus (RFC 2296) wird so erweitert, dass verschlüsselte Varianten in der Liste erkannt und als mögliche Varianten benutzt werden, wenn deren Verschlüsselung gemäß Accept-Encoding-Header akzeptabel sind. Die RVSA/1.0-Implementierung rundet berechnete Qualitätsfaktoren nicht auf 5 Dezimalstellen ab, bevor die Variante ausgewählt wird.

Bei der Aushandlung der Sprache können Sie zwischen verschiedenen Namenskonventionen auswählen, weil Dateinamen mehr als eine Erweiterung haben können und ihre Reihenfolge normalerweise keine Bedeutung hat (mehr hierzu finden Sie in der mod_mime-Dokumentation).

Eine normale Datei hat eine MIME-Typerweiterung (z.B. html), vielleicht eine Verschlüsselungserweiterung (z.B. gz) und selbstverständlich eine Spracherweiterung (z.B. en), wenn es unterschiedliche Sprachvarianten dieser Datei gibt.

Beispiel:

• foo.en.html
• foo.html.en
• foo.en.html.gz

Es folgen einige weitere Beispiele für Dateinamen mit zulässigen und unzulässigen Hyperlinks:

Dateiname	Zulässiger Hyperlink	Unzulässiger Hyperlink
foo.html.en	foo foo.html	-
foo.en.html	foo	foo.html
foo.html.en.gz	foo foo.html	foo.gz foo.html.gz
foo.en.html.gz	foo	foo.html foo.html.gz foo.gz
foo.gz.html.en	foo foo.gz foo.gz.html	foo.html
foo.html.gz.en	foo foo.html foo.html.gz	foo.gz

Beim Blick auf diese Tabelle werden Sie bemerken, dass der Name immer ohne Erweiterungen in einem Hyperlink benutzt werden kann (z.B. foo). Das hat den Vorteil, dass der Dokument- oder Dateityp verborgen bleibt und später geändert werden kann, z.B. von html zu shtml oder cgi, ohne das die Hyperlinks geändert werden müssen.

Wenn Sie weiterhin einen MIME-Typ in den Hyperlinks angeben möchten (z.B. foo.html), müssen die Sprach- und eventuelle Verschlüsselungsangaben rechts von der MIME-Typerweiterung stehen (z.B. foo.html.en).

Wird die Repräsentation eines Dokuments im Cache abgelegt, dann wird sie der URL der Anfrage zugeordnet. Wird diese URL das nächste Mal angefordert, kann die zwischengespeicherte Version benutzt werden. Ist die Ressource aber für den Server verhandelbar, ist es möglich, dass nur die erste angeforderte Variante zwischengespeichert wurde und diese der zweiten Anforderung nicht mehr entspricht. Deshalb kennzeichnet der Apache in der Regel alle Antworten, die als Ergebnis einer Content Negotiation gesendet werden, als nicht für die Zwischenspeicherung durch den HTTP/1.0-Client geeignet. Darüber hinaus unterstützt der Apache aber auch HTTP-Eigenschaften, die eine Zwischenspeicherung von ausgehandelten Antworten erlauben.

Bei Anfragen von HTTP/1.0-kompatiblen Clients (Browser oder Cache) kann mit der Direktive CacheNegotiatedDocs das Zwischenspeichern von Antworten zugelassen werden, die Gegenstand einer Verhandlung waren. Diese Direktive kann in der Serverkonfiguration oder der Konfiguration des virtuellen Host angegeben werden und übernimmt keine Argumente. Sie hat keine Auswirkungen auf Anfragen von HTTP/1.1-Clients.

Für HTTP/1.1-Clients sendet der Apache den HTTP-Header Vary, um die Verhandlungsdimensionen der Antworten anzuzeigen. Der Zwischenspeicher kann anhand dieser Informationen feststellen, ob eine spätere Anfrage mit der lokalen Kopie bedient werden kann. Wird die Umgebungsvariable force-no-vary gesetzt, benutzt der Zwischenspeicherunabhängig von den Verhandlungsdimensionen die lokale Kopie .

Weitere Informationen zur Content Negotiation finden Sie unter Language Negotiation Notes von Alan J. Flavell. Dieses Dokument wurde aber noch nicht bezüglich der Änderungen für Apache 2.0 aktualisiert.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]