Zusammenfassung

  • RFC 2295 machte mehrere Repräsentationen unter einer HTTP-URI durch eine maschinenlesbare Variantenliste sichtbar; eine Listenantwort enthielt jedoch keine Variantendaten.
  • Auswahl, Abruf und Darstellung blieben getrennte Vorgänge. Unter bestimmten Bedingungen konnte der Server die ausgewählte Repräsentation zurückgeben; der Client konnte eine angekündigte Variante auch selbst auswählen und abrufen.

Eine Ressource, mehrere mögliche Antworten

Ende der 1990er-Jahre stand das Web bereits vor einem praktischen Problem: Eine Ressource konnte als HTML oder PostScript, auf Englisch oder Französisch vorliegen und je nach Fähigkeiten des Benutzerprogramms unterschiedlich geeignet sein. Herausgeber konnten getrennte URLs verwenden oder mehrere Fassungen unter einer URI aushandeln. Die Herausforderung bestand nicht nur in der Auswahl. Auch Vermittler, insbesondere Caches, mussten erkennen, welche Antwort zu welcher Anfrage gehörte.

RFC 2295, „Transparent Content Negotiation in HTTP“, schlug dafür ein experimentelles Verfahren vor. Das Memo vom März 1998 nannte jede Fassung eine Variante und beschrieb maschinenlesbare Angaben, die in einer Variantenliste an eine aushandelbare Ressource gebunden waren. Der Header Alternates konnte zu jeder Option deren URI und Eigenschaften wie Medientyp, Sprache, Quellqualität oder Merkmale aufführen. „Transparent“ bedeutete, dass die Varianten auf dem Ursprungsserver für externe Beteiligte sichtbar wurden. Es bedeutete weder, dass jeder Browser automatisch verhandelte, noch dass der Auswahlvorgang unsichtbar war.

Das Verfahren definierte vier Aushandlungsdimensionen: Medientyp, Zeichensatz, Sprache und Merkmale. Die vierte Dimension deckte Eigenschaften ab, die sich mit den ersten drei nicht ausdrücken ließen, etwa HTML-Erweiterungen oder Fähigkeiten anderer Medienformate. Inhaltscodierung, zum Beispiel Kompression, war orthogonal und keine fünfte Variantendimension. Die Abgrenzung ist wichtig: Die Spezifikation beschrieb, welche Repräsentation passend sein konnte, nicht jede Umwandlung, die ein Server an ihren Bytes vornehmen konnte.

Drei Belege statt eines einzigen Ereignisses

Eine Listenantwort war ein Verzeichnis. RFC 2295 definiert sie als Rückgabe der Variantenliste ohne Variantendaten. Ein Benutzerprogramm mit Unterstützung für transparente Aushandlung konnte die Optionen bewerten und eine davon mit einer gewöhnlichen HTTP-Anfrage an deren URI abrufen. Das Beispiel der RFC trennt die Schritte ausdrücklich: Zuerst liefert der Server die Liste; anschließend fordert der Client paper.1 an; erst die zweite Antwort enthält das Dokument. Eine Antwort mit Status 300 Multiple Choices konnte auch einen für Menschen lesbaren Text enthalten, sodass ein nicht aushandelndes Benutzerprogramm oder ein Leser manuell wählen konnte. Trotzdem war die Liste nicht die gewählte Repräsentation.

Der Server war nicht bloß ein Katalogführer. Eine Choice Response lieferte eine Repräsentation der besten Variante und konnte zugleich die Liste enthalten. Dazu brauchte der Server genügend Informationen, um für das Benutzerprogramm auswählen zu können; außerdem musste die Variante die in der RFC definierte URI-Nachbarschaftsbedingung erfüllen. Das ergänzende experimentelle RFC 2296 legte einen Algorithmus für die entfernte Variantenauswahl fest und machte die Auswahl vom Ergebnis abhängig: Ließ sich keine positive, eindeutig beste Variante bestimmen oder war sie nicht benachbart, gab der Algorithmus stattdessen eine Liste zurück. Der Client konnte ebenfalls seinen eigenen Algorithmus anwenden und bei weiterhin verfügbarer Liste eine andere Variante abrufen.

Die Geschichte lässt sich daher nicht korrekt mit „der Client wählte“ zusammenfassen. Manchmal konnte er wählen, manchmal der Server. Das Protokoll unterschied den Kandidatenbestand, die entscheidende Instanz, die Antwort mit den Bytes und die spätere Darstellung. Aus Sicht des Servers zeigte der Header Negotiate an, dass ein Benutzerprogramm Unterstützung für transparente Aushandlung erklärte. Diese Fähigkeitserklärung beweist nicht, dass eine bestimmte Anfrage das Verfahren tatsächlich nutzte.

Der Cache gehörte zum Entwurf

Bei der Aushandlung kann dieselbe URI unterschiedliche Repräsentationen liefern. Verwechselt ein Cache sie, führt selbst ein guter Auswahlalgorithmus zum falschen Ergebnis. RFC 2295 nutzte daher HTTPs Vary und Entity-Tags und ergänzte Validatoren für Variantenlisten. Die Spezifikation beschrieb auch, wie ein Cache aus einer Choice Response eine gewöhnliche HTTP-Antwort extrahieren und wie sich der Ort der gewählten Ressource zur aushandelbaren Ressource verhalten konnte. Korrektes Caching war kein nebensächliches Implementierungsdetail, sondern Teil des Vertrags, der die Wiederverwendung einer URI erst plausibel machte.

Das Design hatte Kosten. Alle Präferenzen bei jeder Anfrage zu senden, konnte die Header aufblähen; daher musste das Benutzerprogramm die Liste oft lokal auswerten. Accept-Präferenzen können jedoch Merkmale der Software oder Umgebung einer Person verraten. Das Memo behandelte ausdrücklich Datenschutzlecks, gefälschte Antworten von Variantenressourcen und Sicherheitslücken, die durch Aushandlung sichtbar werden konnten. Das sind erkannte Entwurfsrisiken, keine Belege für einen konkreten Vorfall.

RFC 2295 war ausdrücklich Experimental und stellte klar, dass es keinen Internetstandard festlegte. Die transparente Aushandlung galt für GET und HEAD, nicht für sämtliche HTTP-Transaktionen. Aus der Spezifikation lässt sich ein Ziel rekonstruieren: Alternativen prüfbar zu machen und die Auswahl auf Clients, Server und Caches zu verteilen. Die hier ausgewerteten Quellen belegen weder eine Erhebung zur Browserunterstützung noch eine Verbreitungsrate oder ein Nutzerergebnis. Eine angekündigte Variante muss nicht abgerufen worden sein; der Empfang einer Antwort beweist nicht, was ein Mensch gesehen hat.

Quellen