Summary

  • RFC 2068 dokumentierte 1997 Accept-Language: Browser konnten akzeptierte Sprachen mit Gewichtungen ordnen und dem Server schon in der Anfrage mitteilen.
  • Wählte der Server danach eine Sprachfassung, konnte er mit Vary: Accept-Language dem Cache melden, welche Anfrageeigenschaft vor einer Wiederverwendung zu vergleichen war.

Der HTTP/1.1-Text RFC 2068 vom Januar 1997 enthält eine kleine Speisekarte: zuerst Dänisch, danach britisches Englisch, dann anderes Englisch. q-Werte geben den Rang an. Der Browser schickt den Wunsch zusammen mit der Adresse. Der Server kann eine passende Fassung liefern, ohne den Leser zunächst durch eine Sprachwahlseite zu schicken.

Sobald ein gemeinsamer Cache beteiligt ist, reicht die Adresse allein nicht mehr als Erklärung. Zwei Menschen verlangen /news; einer möchte Dänisch, die andere Französisch. Der Ursprungsserver kann zwei Fassungen derselben URL liefern. Ein Cache, der nur den URL-Namen merkt, besitzt womöglich den dänischen Text, aber keinen Hinweis darauf, warum gerade dieser Text im Regal liegt. Schnelles Wiederverwenden kann dann zur falschen Ausgabe führen.

Das zusätzliche Etikett heißt Vary. RFC 9110 beschreibt Vary: accept-language als Hinweis, dass dieses Anfragefeld die Auswahl der Antwort beeinflusst haben kann. Nach RFC 9111 über HTTP-Caching darf ein Cache eine so markierte Antwort nicht ohne erneute Validierung verwenden, wenn die genannten Felder nicht zu denen der ursprünglichen Anfrage passen. Die dänische Ausgabe darf bleiben. Ihr Bestellzettel muss mitbleiben.

Der Standard nennt sogar die unscheinbare Panne: Eine voreingestellte Antwort bekommt versehentlich kein Vary. Dann kann genau diese Ausgabe bei späteren Anfragen weiter ausgewählt werden, obwohl eine bessere Sprachfassung bereitliegt. Niemand muss einen Satz falsch übersetzt haben. Das Regal wurde bloß ohne Tischkarte bestückt.

Content-Language bezeichnet die sprachliche Zielgruppe des tatsächlich gelieferten Inhalts. In RFC 9110 stehen damit drei verschiedene Aussagen nebeneinander: Accept-Language ist ein Wunsch, Content-Language beschreibt die gelieferte Fassung, Vary regelt deren Wiederverwendung. Wer sie trennt, kann nachsehen, ob der Fehler beim Wunsch, bei der Auswahl oder beim Cache entstand.

Die Person vor dem Bildschirm kann außerdem eine andere sein als die Person, die den Browser eingestellt hat. Der W3C-Leitfaden zur Sprachaushandlung beschreibt geliehene Browser und empfiehlt sichtbare Sprachwechsel. Schon RFC 2068 erwähnte, dass eine vollständige Sprachliste bei jeder Anfrage private Vorlieben offenlegen kann. Die heutige Spezifikation verlangt deshalb Kontrolle durch den Nutzer über diese Angabe.

HTTP baute hier einen kleinen, arbeitsteiligen Service: Bestellung, Auswahl, Lagerung und Korrektur. Der Cache ist für Tempo zuständig; die Leserin darf trotzdem die Karte neu aufschlagen und eine andere Sprache wählen.