Content Negotiation

Unter Content Negotiation (Inhaltsvereinbarung)[1] versteht man eine Technik im Hypertext Transfer Protocol, die eine Abstimmung der Inhalte der angefragten Ressource aufgrund der Möglichkeiten und Vorzüge des Clients ermöglicht.

Funktionsweise

Im HTTP stehen zur Inhaltsvereinbarung die Anfrage-Header-Felder Accept, Accept-Charset, Accept-Encoding sowie Accept-Language zur Verfügung, die eine durch Kommas getrennte Liste bewerteter Eigenschaften beschreiben.

Accept
Liste akzeptierter Inhaltstypen. Gegenstück in der Antwort ist das Content-Type-Feld
Accept-Charset
Liste akzeptierter Zeichensätze beziehungsweise Zeichenkodierungen. Gegenstück in der Antwort ist der charset-Parameter des Content-Type-Felds
Accept-Encoding
Liste akzeptierter Kodierungen. Gegenstück in der Antwort ist das Content-Encoding-Feld
Accept-Language
Liste akzeptierter Sprachen. Gegenstück in der Antwort ist das Content-Language-Feld

Die Bewertung der Eigenschaften ist über den optionalen Qualitätsparameter q möglich, der Werte zwischen 0 (inakzeptabel) und 1 (bevorzugt) erlaubt; fehlt dieser, wird der Standardwert 1 angenommen. Bei gleicher Wertigkeit wird je nach Header-Feld zusätzliche die Spezifität der Eigenschaft bei der Bestimmung der Reihenfolge herangezogen, wobei spezifischere den weniger spezifischen Eigenschaften vorgezogen werden.

Zusätzlich sollte bei der Nutzung von HTTP-Caching-Techniken in der Antwort des Webservers das Vary-Header-Feld diejenigen Header-Felder der Anfrage genannt werden, die bei der Abstimmung berücksichtigt wurden, die also zur eindeutigen Auswahl der gesendeten Repräsentation der Ressource führten.

Falls die angeforderte URL eine generische ist, sie also die Repräsentation der Ressource nicht eindeutig beschreibt und stattdessen eine Inhaltsvereinbarung stattfindet, die ausgelieferte Repräsentation jedoch eine eigene spezifische URL besitzt, kann diese im Content-Location-Header-Feld angegeben werden.

Beispiel

Eine der am weitesten verbreiteten Anwendungen ist die automatische Auswahl der Sprache (englisch Language Negotiation). Dazu sendet der Client in seiner Anfrage das Feld Accept-Language: 

GET /path/to/resource HTTP/1.1
Host: example.com
Accept-Language: de-de, de, en;q=0.5, fr;q=0.2
⋮

Diese Angabe ist so zu interpretieren, dass der Client Deutsch, Englisch und Französisch akzeptiert, wobei allerdings bundesdeutsches Hochdeutsch vor allen anderen Deutsch-Varianten sowie vor Englisch und Französisch bevorzugt wird. Wenn der Server also über eine Version im bundesdeutschen Hochdeutsch, im österreichischen Deutsch und im Schweizer Hochdeutsch verfügt, sollte die bundesdeutsche Version ausgeliefert werden.

Eine Antwort des Webservers könnte dann beispielsweise wie folgt aussehen, hier wird deutschsprachiger Content geladen, ohne eine Varietät des Standarddeutschen zu spezifizieren: 

HTTP/1.1 200 OK
Content-Language: de
Content-Location: /de/path/to/resource
Vary: Accept-Language
⋮

HTTP-Statuscodes

Das HTTP bietet spezielle Statuscodes an, die der Server an den Client senden sollte, wenn eine inhaltliche Abstimmung nicht möglich war:

300 Multiple Choices
Wird gesendet, wenn mehrere zu den in der Anfrage gestellten Bedingungen passenden Ressourcen an anderer Stelle zu finden sind oder der Server dem Client die Auswahl überlassen möchte. Die entsprechenden Adressen und Charakteristiken der Auswahlmöglichkeiten sollten im Dokument angegeben werden; der Server kann die Adresse eines von ihm bevorzugten Dokuments im Location-Header-Feld mitsenden.
406 Not Acceptable
Wird gesendet, wenn die angefragte Ressource zwar existiert, die vom Client gesendeten Bedingungen aber nicht erfüllbar sind.
506 Variant Also Negotiates[2]
Die Inhaltsvereinbarung der Anfrage ergibt einen Zirkelbezug.

Unterstützung durch Webserver

Der Apache HTTP Server bietet über das Modul mod_negotiation die Möglichkeit mehrere Sprachen anzubieten, ohne viel aufwendige Konfiguration betreiben zu müssen. Dazu muss (in der Standardeinstellung) lediglich die ISO-639-Kennung der jeweiligen Sprache an den Dateinamen angehängt werden, so wird deutschen Browsern, die die Datei foo.html anfordern, eigentlich die Datei foo.html.de ausgeliefert. Hierzu erzeugt mod_negotiation transparent typemaps.[3]

  • RFC: 2616 – Hypertext Transfer Protocol – HTTP-1.1. Juni 1999 (löst RFC 2068 ab, Spezifikation, englisch).
    • Beschreibung der Header-Felder:
      • Accept – RFC: 2616 – HTTP-1.1. Abschnitt 14.1 (englisch).
      • Accept-Charset – RFC: 2616 – HTTP-1.1. Abschnitt 14.2 (englisch).
      • Accept-Encoding – RFC: 2616 – HTTP-1.1. Abschnitt 14.3 (englisch).
      • Accept-Language – RFC: 2616 – HTTP-1.1. Abschnitt 14.4 (englisch).
    • RFC: 2616 – HTTP-1.1. Abschnitt 12: Content Negotiation. (englisch).
  • RFC: 2295 – Transparent Content Negotiation in HTTP. März 1998 (englisch).
  • Apache Content Negotiation. apache.org (englisch)
  • Wann es angebracht ist, Sprachvereinbarung (language negotiation) einzusetzen. W3C, I18n FAQ (deutsch).

Einzelnachweise

  1. ↑ Ben Laurie, Peter Laurie: Apache. Das umfassende Handbuch. 2. Auflage. Deutsche Ausgabe der 3. Auflage. O’Reilly, Beijing u. a. 2003, ISBN 3-89721-356-7.
  2. ↑ RFC: 2295 – Transparent Content Negotiation in HTTP. März 1998 (englisch).
  3. ↑ httpd.apache.org