12. Inhaltsverhandlung (Content Negotiation)

Wenn Antworten Inhalt übermitteln, unabhängig davon, ob sie einen Erfolg oder einen Fehler anzeigen, hat der Origin-Server oft verschiedene Möglichkeiten, diese Informationen darzustellen; zum Beispiel in verschiedenen Formaten, Sprachen oder Kodierungen. Ebenso können verschiedene Benutzer oder User-Agents unterschiedliche Fähigkeiten, Eigenschaften oder Präferenzen haben, die beeinflussen könnten, welche Repräsentation unter den verfügbaren am besten zu liefern wäre. Aus diesem Grund bietet HTTP Mechanismen für die Inhaltsverhandlung.

Diese Spezifikation definiert drei Muster der Inhaltsverhandlung, die im Protokoll sichtbar gemacht werden: „proaktive" Verhandlung, bei der der Server die Repräsentation basierend auf den angegebenen Präferenzen des User-Agents auswählt; „reaktive" Verhandlung, bei der der Server eine Liste von Repräsentationen bereitstellt, aus denen der User-Agent wählen kann; und „Request-Content"-Verhandlung, bei der der User-Agent die Repräsentation für eine zukünftige Anfrage basierend auf den vom Server in einer vergangenen Antwort angegebenen Präferenzen auswählt.

Andere Muster der Inhaltsverhandlung umfassen „bedingten Inhalt", bei dem die Repräsentation aus mehreren Teilen besteht, die basierend auf User-Agent-Parametern selektiv gerendert werden; „aktiven Inhalt", bei dem die Repräsentation ein Skript enthält, das basierend auf den Eigenschaften des User-Agents zusätzliche (spezifischere) Anfragen stellt; und „Transparente Inhaltsverhandlung" ([RFC2295]), bei der die Inhaltsauswahl von einem Vermittler durchgeführt wird. Diese Muster schließen sich nicht gegenseitig aus, und jedes hat Kompromisse in Bezug auf Anwendbarkeit und Praktikabilität.

Beachten Sie, dass HTTP in allen Fällen die Ressourcensemantik nicht kennt. Die Konsistenz, mit der ein Origin-Server auf Anfragen antwortet, im Laufe der Zeit und für unterschiedliche Clients, und damit die „Gleichheit" der beobachteten Repräsentationen einer Ressource im Laufe der Zeit, wird vollständig von der Entität oder dem Algorithmus bestimmt, die diese Antworten auswählt oder generiert.

12.1. Proaktive Verhandlung (Proactive Negotiation)

Wenn Inhaltsverhandlungspräferenzen vom User-Agent in einer Anfrage gesendet werden, um einen auf dem Server befindlichen Algorithmus zur Auswahl der bevorzugten Repräsentation zu ermutigen, wird dies als „proaktive Verhandlung" (auch bekannt als „servergesteuerte Verhandlung") bezeichnet. Die Auswahl basiert auf den verfügbaren Repräsentationen der Antwort (den Dimensionen, über die sie variieren könnte, wie Sprache, Content-Coding usw.) im Vergleich zu verschiedenen in der Anfrage bereitgestellten Informationen, einschließlich sowohl der expliziten Verhandlungsfelder unten als auch impliziter Eigenschaften, wie der Netzwerkadresse des Clients oder Teilen des User-Agent-Feldes.

Proaktive Verhandlung ist vorteilhaft, wenn der Algorithmus zur Auswahl aus den verfügbaren Repräsentationen schwer einem User-Agent zu beschreiben ist, oder wenn der Server seine „beste Vermutung" zusammen mit der ersten Antwort an den User-Agent senden möchte (in der Hoffnung, die Round-Trip-Verzögerung einer nachfolgenden Anfrage zu vermeiden, wenn diese „beste Vermutung" für den Benutzer gut genug ist). Um die Vermutung des Servers zu verbessern, KANN ein User-Agent (MAY) Request-Header-Felder senden, die seine Präferenzen beschreiben.

Proaktive Verhandlung hat ernsthafte Nachteile:

• Es ist für den Server unmöglich, genau zu bestimmen, was für einen bestimmten Benutzer „am besten" sein könnte, da dies vollständige Kenntnis sowohl der Fähigkeiten des User-Agents als auch der beabsichtigten Verwendung der Antwort erfordern würde (z.B. möchte der Benutzer sie auf dem Bildschirm ansehen oder auf Papier drucken?);

• Wenn der User-Agent seine Fähigkeiten in jeder Anfrage beschreiben lässt, kann dies sowohl sehr ineffizient sein (angesichts der Tatsache, dass nur ein kleiner Prozentsatz der Antworten mehrere Repräsentationen hat) als auch ein potenzielles Risiko für die Privatsphäre des Benutzers darstellen;

• Es verkompliziert die Implementierung eines Origin-Servers und die Algorithmen zur Generierung von Antworten auf eine Anfrage; und,

• Es schränkt die Wiederverwendbarkeit von Antworten für Shared Caching ein.

Ein User-Agent kann sich nicht darauf verlassen, dass proaktive Verhandlungspräferenzen konsistent eingehalten werden, da der Origin-Server möglicherweise keine proaktive Verhandlung für die angeforderte Ressource implementiert hat oder entscheiden könnte, dass das Senden einer Antwort, die nicht den Präferenzen des User-Agents entspricht, besser ist als das Senden einer 406 (Not Acceptable)-Antwort.

Ein Vary-Header-Feld (Abschnitt 12.5.5) wird oft in Antworten gesendet, die der proaktiven Verhandlung unterliegen, um anzuzeigen, welche Teile der Anfrageinformationen im Auswahlalgorithmus verwendet wurden.

Die Request-Header-Felder Accept, Accept-Charset, Accept-Encoding und Accept-Language sind unten definiert, damit ein User-Agent an der proaktiven Verhandlung des Antwortinhalts teilnehmen kann. Die in diesen Feldern gesendeten Präferenzen gelten für jeden Inhalt in der Antwort, einschließlich Repräsentationen der Zielressource, Repräsentationen von Fehler- oder Verarbeitungsstatus und möglicherweise sogar der verschiedenen Textzeichenfolgen, die im Protokoll erscheinen könnten.

12.2. Reaktive Verhandlung (Reactive Negotiation)

Bei der „reaktiven Verhandlung" (auch bekannt als „agentengesteuerte Verhandlung") wird die Auswahl des Inhalts (unabhängig vom Statuscode) vom User-Agent nach Erhalt einer ersten Antwort durchgeführt. Der Mechanismus für reaktive Verhandlung kann so einfach sein wie eine Liste von Referenzen auf alternative Repräsentationen.

Wenn der User-Agent mit dem Inhalt der ersten Antwort nicht zufrieden ist, kann er eine GET-Anfrage an eine oder mehrere der alternativen Ressourcen durchführen, um eine andere Repräsentation zu erhalten. Die Auswahl solcher Alternativen kann automatisch (vom User-Agent) oder manuell (z.B. durch den Benutzer, der aus einem Hypertext-Menü auswählt) erfolgen.

Ein Server kann sich entscheiden, keine erste Repräsentation außer der Liste der Alternativen zu senden und somit anzuzeigen, dass reaktive Verhandlung durch den User-Agent bevorzugt wird. Zum Beispiel enthalten die in Antworten mit den Statuscodes 300 (Multiple Choices) und 406 (Not Acceptable) aufgelisteten Alternativen Informationen über die verfügbaren Repräsentationen, damit der Benutzer oder User-Agent reagieren kann, indem er eine Auswahl trifft.

Reaktive Verhandlung ist vorteilhaft, wenn die Antwort über häufig verwendete Dimensionen (wie Typ, Sprache oder Kodierung) variieren würde, wenn der Origin-Server nicht in der Lage ist, die Fähigkeiten eines User-Agents durch Untersuchung der Anfrage zu bestimmen, und im Allgemeinen, wenn öffentliche Caches verwendet werden, um die Serverlast zu verteilen und die Netzwerknutzung zu reduzieren.

Reaktive Verhandlung leidet unter den Nachteilen, eine Liste von Alternativen an den User-Agent zu übertragen, was die vom Benutzer wahrgenommene Latenz beeinträchtigt, wenn sie im Header-Abschnitt übertragen wird, und eine zweite Anfrage benötigt, um eine alternative Repräsentation zu erhalten. Darüber hinaus definiert diese Spezifikation keinen Mechanismus zur Unterstützung der automatischen Auswahl, obwohl sie die Entwicklung eines solchen Mechanismus nicht verhindert.

12.3. Request-Content-Verhandlung (Request Content Negotiation)

Wenn Inhaltsverhandlungspräferenzen von einem Server in einer Antwort gesendet werden, werden die aufgelisteten Präferenzen als „Request-Content-Verhandlung" bezeichnet, da sie darauf abzielen, die Auswahl eines geeigneten Inhalts für nachfolgende Anfragen an diese Ressource zu beeinflussen. Zum Beispiel können die Header-Felder Accept (Abschnitt 12.5.1) und Accept-Encoding (Abschnitt 12.5.3) in einer Antwort gesendet werden, um bevorzugte Medientypen und Content-Codings für nachfolgende Anfragen an diese Ressource anzuzeigen.

Ähnlich definiert Abschnitt 3.1 von [RFC5789] das „Accept-Patch"-Antwort-Header-Feld, das die Entdeckung ermöglicht, welche Content-Typen in PATCH-Anfragen akzeptiert werden.

12.4. Merkmale von Inhaltsverhandlungsfeldern (Content Negotiation Field Features)

12.4.1. Abwesenheit (Absence)

Für jedes der Inhaltsverhandlungsfelder bedeutet eine Anfrage, die dieses Feld nicht enthält, dass der Sender keine Präferenz für diese Verhandlungsdimension hat.

Wenn ein Inhaltsverhandlungs-Header-Feld in einer Anfrage vorhanden ist und keine der verfügbaren Repräsentationen für die Antwort entsprechend diesem als akzeptabel angesehen werden kann, kann der Origin-Server entweder das Header-Feld ehren, indem er eine 406 (Not Acceptable)-Antwort sendet, oder das Header-Feld missachten, indem er die Antwort so behandelt, als wäre sie nicht der Inhaltsverhandlung für dieses Request-Header-Feld unterworfen. Dies impliziert jedoch nicht, dass der Client in der Lage sein wird, die Repräsentation zu verwenden.

Hinweis: Ein User-Agent, der diese Header-Felder sendet, erleichtert es einem Server, eine Person aufgrund der Anfrageeigenschaften des User-Agents zu identifizieren (Abschnitt 17.13).

12.4.2. Qualitätswerte (Quality Values)

Die von dieser Spezifikation definierten Inhaltsverhandlungsfelder verwenden einen gemeinsamen Parameter namens „q" (Groß-/Kleinschreibung unempfindlich), um ein relatives „Gewicht" für die Präferenz für diese zugeordnete Art von Inhalt zuzuweisen. Dieses Gewicht wird als „Qualitätswert" (oder „qvalue") bezeichnet, da derselbe Parametername oft in Serverkonfigurationen verwendet wird, um ein Gewicht für die relative Qualität der verschiedenen Repräsentationen zuzuweisen, die für eine Ressource ausgewählt werden können.

Das Gewicht wird auf eine reelle Zahl im Bereich von 0 bis 1 normalisiert, wobei 0,001 am wenigsten bevorzugt und 1 am meisten bevorzugt ist; ein Wert von 0 bedeutet „nicht akzeptabel". Wenn kein „q"-Parameter vorhanden ist, beträgt das Standardgewicht 1.

weight = OWS ";" OWS "q=" qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] )
       / ( "1" [ "." 0*3("0") ] )

Ein Sender von qvalue DARF NICHT (MUST NOT) mehr als drei Ziffern nach dem Dezimalpunkt erzeugen. Die Benutzerkonfiguration dieser Werte sollte auf die gleiche Weise begrenzt werden.

12.4.3. Platzhalter-Werte (Wildcard Values)

Die meisten dieser Header-Felder definieren, wo angegeben, einen Platzhalter-Wert (*), um nicht spezifizierte Werte auszuwählen. Wenn kein Platzhalter vorhanden ist, werden Werte, die im Feld nicht ausdrücklich erwähnt werden, als nicht akzeptabel angesehen. Innerhalb von Vary bedeutet ein Platzhalter-Wert, dass die Varianz unbegrenzt ist.

Hinweis: In der Praxis hat die Verwendung von Platzhaltern in der Inhaltsverhandlung begrenzten praktischen Wert, da es selten nützlich ist zu sagen, zum Beispiel: „Ich bevorzuge image/* mehr oder weniger als (einen anderen spezifischen Wert)". Durch Senden von Accept: */*;q=0 können Clients explizit eine 406 (Not Acceptable)-Antwort anfordern, wenn ein bevorzugteres Format nicht verfügbar ist, aber sie müssen dennoch in der Lage sein, eine andere Antwort zu verarbeiten, da der Server ihre Präferenz ignorieren darf.

12.5. Inhaltsverhandlungsfelder (Content Negotiation Fields)

12.5.1. Accept

Das „Accept"-Header-Feld kann von User-Agents verwendet werden, um ihre Präferenzen bezüglich Antwortmedientypen anzugeben. Zum Beispiel kann das Accept-Header-Feld verwendet werden, um anzuzeigen, dass die Anfrage speziell auf eine kleine Menge gewünschter Typen beschränkt ist, wie im Fall einer Anfrage für ein Inline-Bild.

Wenn es von einem Server in einer Antwort gesendet wird, liefert Accept Informationen darüber, welche Content-Typen im Inhalt einer nachfolgenden Anfrage an dieselbe Ressource bevorzugt werden.

Accept = #( media-range [ weight ] )

media-range    = ( "*/*"
                   / ( type "/" "*" )
                   / ( type "/" subtype )
                 ) parameters

Das Sternchen-Zeichen * wird verwendet, um Medientypen in Bereiche zu gruppieren, wobei */* alle Medientypen und type/* alle Subtypen dieses Typs angibt. Der media-range kann Medientyp-Parameter enthalten, die auf diesen Bereich anwendbar sind.

Jedem media-range können optionale anwendbare Medientyp-Parameter (z.B. charset) folgen, gefolgt von einem optionalen „q"-Parameter zur Angabe eines relativen Gewichts (Abschnitt 12.4.2).

Frühere Spezifikationen erlaubten das Auftreten zusätzlicher Erweiterungsparameter nach dem Gewichtsparameter. Die accept-ext-Syntax (accept-params, accept-ext) wurde entfernt, da sie eine komplizierte Definition hatte, in der Praxis nicht verwendet wurde und leichter über neue Header-Felder bereitgestellt werden kann. Sender, die Gewichte verwenden, SOLLTEN (SHOULD) „q" zuletzt senden (nach allen media-range-Parametern). Empfänger SOLLTEN (SHOULD) jeden Parameter namens „q" als Gewicht behandeln, unabhängig von der Parameterreihenfolge.

Hinweis: Die Verwendung des „q"-Parameternamens zur Steuerung der Inhaltsverhandlung würde mit jedem Medientyp-Parameter mit demselben Namen interferieren. Daher verbieten Medientyp-Registrierungen Parameter mit dem Namen „q".

Beispiel:

Accept: audio/*; q=0.2, audio/basic

wird interpretiert als „Ich bevorzuge audio/basic, aber senden Sie mir jeden Audio-Typ, wenn er nach einer 80%igen Qualitätsminderung der beste verfügbare ist".

Ein aufwändigeres Beispiel ist:

Accept: text/plain; q=0.5, text/html,
       text/x-dvi; q=0.8, text/x-c

Wörtlich würde dies interpretiert als „text/html und text/x-c sind die gleichrangig bevorzugten Medientypen, aber wenn sie nicht existieren, dann senden Sie die text/x-dvi-Repräsentation, und wenn diese auch nicht existiert, senden Sie die text/plain-Repräsentation".

Medienbereiche können durch spezifischere Medienbereiche oder spezifische Medientypen überschrieben werden. Wenn mehr als ein Medienbereich auf einen bestimmten Typ zutrifft, hat die spezifischste Referenz Vorrang. Zum Beispiel:

Accept: text/*, text/plain, text/plain;format=flowed, */*

haben die folgende Priorität:

1. text/plain;format=flowed
2. text/plain
3. text/*
4. */*

Der mit einem bestimmten Typ assoziierte Medientyp-Qualitätsfaktor wird bestimmt, indem der Medienbereich mit der höchsten Priorität gefunden wird, der mit dem Typ übereinstimmt. Zum Beispiel:

Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,
       text/plain;format=fixed;q=0.4, */*;q=0.5

würde dazu führen, dass die folgenden Werte zugeordnet werden:

Medientyp	Qualitätswert
text/plain;format=flowed	1
text/plain	0.7
text/html	0.3
image/jpeg	0.5
text/plain;format=fixed	0.4
text/html;level=3	0.7

Hinweis: Einem User-Agent kann ein Standard-Satz von Qualitätswerten für bestimmte Medienbereiche bereitgestellt werden. Sofern der User-Agent jedoch kein geschlossenes System ist, das nicht mit anderen Rendering-Agenten interagieren kann, sollte dieser Standard-Satz vom Benutzer konfigurierbar sein.

12.5.2. Accept-Charset

Das „Accept-Charset"-Header-Feld kann von einem User-Agent gesendet werden, um seine Präferenzen für Zeichensätze in textuellen Antwortinhalten anzuzeigen. Zum Beispiel ermöglicht dieses Feld User-Agents, die umfassendere oder spezialisierte Zeichensätze verstehen können, diese Fähigkeit einem Origin-Server zu signalisieren, der in der Lage ist, Informationen in diesen Zeichensätzen darzustellen.

Accept-Charset = #( ( token / "*" ) [ weight ] )

Zeichensatznamen sind in Abschnitt 8.3.2 definiert. Ein User-Agent KANN (MAY) jedem Zeichensatz einen Qualitätswert zuordnen, um die relative Präferenz des Benutzers für diesen Zeichensatz anzuzeigen, wie in Abschnitt 12.4.2 definiert. Ein Beispiel ist:

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

Der spezielle Wert * stimmt, wenn er im Accept-Charset-Header-Feld vorhanden ist, mit jedem Zeichensatz überein, der nicht anderswo im Feld erwähnt wird.

Hinweis: Accept-Charset ist veraltet, da UTF-8 nahezu allgegenwärtig geworden ist und das Senden einer detaillierten Liste bevorzugter Zeichensätze des Benutzers Bandbreite verschwendet, die Latenz erhöht und passives Fingerprinting viel zu einfach macht (Abschnitt 17.13). Die meisten allgemeinen User-Agents senden Accept-Charset nicht, es sei denn, sie sind speziell dazu konfiguriert.

12.5.3. Accept-Encoding

Das „Accept-Encoding"-Header-Feld kann verwendet werden, um Präferenzen bezüglich der Verwendung von Content-Codings anzuzeigen (Abschnitt 8.4.1).

Wenn es von einem User-Agent in einer Anfrage gesendet wird, gibt Accept-Encoding die in einer Antwort akzeptablen Content-Codings an.

Wenn es von einem Server in einer Antwort gesendet wird, liefert Accept-Encoding Informationen darüber, welche Content-Codings im Inhalt einer nachfolgenden Anfrage an dieselbe Ressource bevorzugt werden.

Das „identity"-Token wird als Synonym für „keine Kodierung" verwendet, um zu kommunizieren, wenn keine Kodierung bevorzugt wird.

Accept-Encoding  = #( codings [ weight ] )
codings          = content-coding / "identity" / "*"

Jedem codings-Wert KANN (MAY) ein assoziierter Qualitätswert (Gewicht) gegeben werden, der die Präferenz für diese Kodierung darstellt, wie in Abschnitt 12.4.2 definiert. Das Sternchen-Symbol * in einem Accept-Encoding-Feld stimmt mit jedem verfügbaren Content-Coding überein, das nicht explizit im Feld aufgelistet ist.

Beispiele:

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Ein Server testet, ob ein Content-Coding für eine gegebene Repräsentation akzeptabel ist, unter Verwendung der folgenden Regeln:

1. Wenn kein Accept-Encoding-Header-Feld in der Anfrage vorhanden ist, betrachtet der User-Agent jedes Content-Coding als akzeptabel.

2. Wenn die Repräsentation kein Content-Coding hat, ist sie standardmäßig akzeptabel, es sei denn, das Accept-Encoding-Header-Feld schließt sie explizit aus, indem es entweder identity;q=0 oder *;q=0 ohne einen spezifischeren „identity"-Eintrag angibt.

3. Wenn das Content-Coding der Repräsentation eines der im Accept-Encoding-Feldwert aufgelisteten Content-Codings ist, ist es akzeptabel, es sei denn, es wird von einem qvalue von 0 begleitet. (Wie in Abschnitt 12.4.2 definiert, bedeutet ein qvalue von 0 „nicht akzeptabel".)

Eine Repräsentation kann mit mehreren Content-Codings codiert werden. Die meisten Content-Codings sind jedoch alternative Wege, denselben Zweck zu erfüllen (z.B. Datenkompression). Bei der Auswahl zwischen mehreren Content-Codings mit demselben Zweck wird das akzeptable Content-Coding mit dem höchsten qvalue ungleich Null bevorzugt.

Ein Accept-Encoding-Header-Feld mit einem leeren Feldwert bedeutet, dass der User-Agent kein Content-Coding in der Antwort wünscht. Wenn ein nicht leeres Accept-Encoding-Header-Feld in einer Anfrage vorhanden ist und keine der verfügbaren Repräsentationen für die Antwort ein als akzeptabel aufgelistetes Content-Coding hat, SOLLTE der Origin-Server (SHOULD) eine Antwort ohne Content-Coding senden, es sei denn, die identity-Kodierung wird als nicht akzeptabel angezeigt.

Wenn das Accept-Encoding-Header-Feld in einer Antwort vorhanden ist, gibt es an, welche Content-Codings die Ressource bereit war, in der zugehörigen Anfrage zu akzeptieren. Der Feldwert wird auf die gleiche Weise wie in einer Anfrage ausgewertet.

Beachten Sie, dass diese Information spezifisch für die zugehörige Anfrage ist; der Satz unterstützter Kodierungen kann für andere Ressourcen auf demselben Server unterschiedlich sein und sich im Laufe der Zeit ändern oder von anderen Aspekten der Anfrage abhängen (wie der Anfragemethode).

Ein Server, der eine Anfrage aufgrund eines nicht unterstützten Content-Codings ablehnt, sollte mit einem 415 (Unsupported Media Type)-Status antworten und ein Accept-Encoding-Header-Feld in dieser Antwort einschließen, damit Clients zwischen Problemen im Zusammenhang mit Content-Codings und Medientypen unterscheiden können. Um Verwirrung mit Problemen im Zusammenhang mit Medientypen zu vermeiden, DARF ein Server, der eine Anfrage mit einem 415-Status aus Gründen ablehnt, die nicht mit Content-Coding zusammenhängen, das Accept-Encoding-Header-Feld NICHT (MUST NOT) einschließen.

Die häufigste Verwendung von Accept-Encoding ist in Antworten mit einem 415 (Unsupported Media Type)-Statuscode, als Reaktion auf die optimistische Verwendung eines Content-Codings durch Clients. Das Header-Feld kann jedoch auch verwendet werden, um Clients anzuzeigen, dass Content-Codings unterstützt werden, um zukünftige Interaktionen zu optimieren. Zum Beispiel könnte eine Ressource es in einer 2xx (Successful)-Antwort einschließen, wenn der Anforderungsinhalt hätte kodiert werden können, der Client jedoch kein Content-Coding verwendet hat.

12.5.4. Accept-Language

Das „Accept-Language"-Header-Feld kann von User-Agents verwendet werden, um den Satz natürlicher Sprachen anzugeben, die in der Antwort bevorzugt werden. Sprach-Tags sind in Abschnitt 8.5.1 definiert.

Accept-Language = #( language-range [ weight ] )
language-range  =
          <language-range, see [RFC4647], Section 2.1>

Jedem language-range kann ein assoziierter Qualitätswert gegeben werden, der eine Schätzung der Benutzerpräferenz für die von diesem Bereich angegebenen Sprachen darstellt, wie in Abschnitt 12.4.2 definiert. Zum Beispiel:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

würde bedeuten: „Ich bevorzuge Dänisch, aber ich akzeptiere britisches Englisch und andere Arten von Englisch".

Beachten Sie, dass einige Empfänger die Reihenfolge, in der Sprach-Tags aufgelistet sind, als Hinweis auf absteigende Priorität behandeln, insbesondere für Tags, denen gleiche Qualitätswerte zugewiesen sind (kein Wert ist dasselbe wie q=1). Auf dieses Verhalten kann man sich jedoch nicht verlassen. Für Konsistenz und maximale Interoperabilität weisen viele User-Agents jedem Sprach-Tag einen eindeutigen Qualitätswert zu, während sie sie auch in absteigender Reihenfolge der Qualität auflisten. Zusätzliche Diskussionen zu Sprachprioritätslisten finden sich in Abschnitt 2.3 von [RFC4647].

Für den Abgleich definiert Abschnitt 3 von [RFC4647] mehrere Abgleichschemata. Implementierungen können das für ihre Anforderungen am besten geeignete Abgleichsschema anbieten. Das „Basis-Filterung"-Schema ([RFC4647], Abschnitt 3.3.1) ist identisch mit dem Abgleichsschema, das zuvor für HTTP in Abschnitt 14.4 von [RFC2616] definiert wurde.

Das Senden eines Accept-Language-Header-Feldes mit den vollständigen sprachlichen Präferenzen des Benutzers in jeder Anfrage könnte den Datenschutzerwartungen des Benutzers widersprechen (Abschnitt 17.13).

Da die Verständlichkeit stark vom einzelnen Benutzer abhängt, müssen User-Agents eine Benutzerkontrolle über die Sprachpräferenzen ermöglichen (entweder durch Konfiguration des User-Agents selbst oder durch Standardeinstellung auf eine vom Benutzer kontrollierbare Systemeinstellung). Ein User-Agent, der eine solche Kontrolle nicht bereitstellt, DARF NICHT (MUST NOT) ein Accept-Language-Header-Feld senden.

Hinweis: User-Agents sollten Benutzern beim Festlegen einer Präferenz Anleitung geben, da Benutzer selten mit den Details des Sprachabgleichs wie oben beschrieben vertraut sind. Zum Beispiel könnten Benutzer annehmen, dass sie bei der Auswahl von „en-gb" jede Art von englischem Dokument erhalten, wenn britisches Englisch nicht verfügbar ist. Ein User-Agent könnte in einem solchen Fall vorschlagen, „en" zur Liste hinzuzufügen, um ein besseres Abgleichsverhalten zu erzielen.

12.5.5. Vary

Das „Vary"-Header-Feld in einer Antwort beschreibt, welche Teile einer Anfragenachricht, abgesehen von der Methode und der Ziel-URI, den Prozess des Origin-Servers bei der Auswahl des Inhalts dieser Antwort beeinflusst haben könnten.

Vary = #( "*" / field-name )

Ein Vary-Feldwert ist entweder das Platzhalter-Mitglied * oder eine Liste von Request-field-name-Token, genannt die Auswahl-Header-Felder, die eine Rolle bei der Auswahl der Repräsentation für diese Antwort gespielt haben könnten. Potenzielle Auswahl-Header-Felder sind nicht auf die von dieser Spezifikation definierten Felder beschränkt.

Eine Liste, die das Mitglied * enthält, signalisiert, dass andere Aspekte der Anfrage eine Rolle bei der Auswahl der Antwortrepräsentation gespielt haben könnten, möglicherweise einschließlich Aspekten außerhalb der Nachrichtensyntax (z.B. der Netzwerkadresse des Clients). Ein Empfänger wird nicht in der Lage sein zu bestimmen, ob diese Antwort für eine spätere Anfrage geeignet ist, ohne die Anfrage an den Origin-Server weiterzuleiten. Ein Proxy DARF NICHT (MUST NOT) ein * in einem Vary-Feldwert erzeugen.

Zum Beispiel zeigt eine Antwort, die Folgendes enthält:

Vary: accept-encoding, accept-language

an, dass der Origin-Server möglicherweise die Accept-Encoding- und Accept-Language-Header-Felder der Anfrage (oder deren Fehlen) als bestimmende Faktoren bei der Auswahl des Inhalts für diese Antwort verwendet hat.

Ein Vary-Feld, das eine Liste von Feldnamen enthält, hat zwei Zwecke:

1. Cache-Empfänger darüber zu informieren, dass sie diese Antwort NICHT (MUST NOT) verwenden dürfen, um eine spätere Anfrage zu erfüllen, es sei denn, die spätere Anfrage hat die gleichen Werte für die aufgelisteten Header-Felder wie die ursprüngliche Anfrage (siehe Abschnitt 4.1 von [CACHING]), oder die Wiederverwendung der Antwort wurde vom Origin-Server validiert. Mit anderen Worten, Vary erweitert den Cache-Schlüssel, der erforderlich ist, um eine neue Anfrage mit dem gespeicherten Cache-Eintrag abzugleichen.

2. User-Agent-Empfänger darüber zu informieren, dass diese Antwort einer Inhaltsverhandlung unterlag (Abschnitt 12) und dass eine andere Repräsentation in einer nachfolgenden Anfrage gesendet werden könnte, wenn zusätzliche Werte in den aufgelisteten Header-Feldern bereitgestellt werden (proaktive Verhandlung).

Ein Origin-Server SOLLTE (SHOULD) ein Vary-Header-Feld auf einer cachebaren Antwort erzeugen, wenn er möchte, dass die Antwort für nachfolgende Anfragen an diese Ressource selektiv wiederverwendet wird. Im Allgemeinen ist dies der Fall, wenn der Antwortinhalt angepasst wurde, um den von diesen Auswahl-Header-Feldern ausgedrückten Präferenzen besser zu entsprechen, wie wenn ein Origin-Server die Sprache der Antwort basierend auf dem Accept-Language-Header-Feld der Anfrage ausgewählt hat.

Vary kann weggelassen werden, wenn ein Origin-Server die Varianz in der Inhaltsauswahl als weniger bedeutsam ansieht als die Leistungsauswirkungen von Vary auf das Caching, insbesondere wenn die Wiederverwendung bereits durch Cache-Response-Direktiven eingeschränkt ist (siehe Abschnitt 5.2 von [CACHING]).

Es ist nicht erforderlich, den Authorization-Feldnamen in Vary zu senden, da die Wiederverwendung dieser Antwort für einen anderen Benutzer durch die Felddefinition verboten ist (Abschnitt 11.6.2). Ebenso ist es nicht erforderlich, dass der Origin-Server diese Varianz in Vary angibt, wenn der Antwortinhalt von der Netzwerkregion ausgewählt oder beeinflusst wurde, der Origin-Server jedoch möchte, dass die gecachte Antwort wiederverwendet wird, auch wenn der Empfänger von einer Region in eine andere wechselt.