No-Vary-Search

key-order Optional

Gibt an, dass URLs nicht als separate Einträge im Cache gespeichert werden, wenn die Reihenfolge, in der die Parameter in der URL erscheinen, der einzige Unterschied ist. Das Vorhandensein anderer Parameter wird jedoch bewirken, dass URLs separat im Cache gespeichert werden.

params Optional

Entweder ein boolescher Wert oder eine Liste von Strings:

• Als Boolescher Wert (params) gibt es an, dass URLs, die sich nur durch ihre Parameter unterscheiden, nicht als separate Einträge im Cache gespeichert werden.
• Eine innere Liste von durch Leerzeichen getrennten Strings (params=("param1" "param2")). Gibt an, dass URLs, die sich nur durch die aufgelisteten Parameter unterscheiden, nicht als separate Einträge im Cache gespeichert werden. Das Vorhandensein anderer Parameter wird bewirken, dass sie separat im Cache gespeichert werden.

except Optional

Eine innere Liste von durch Leerzeichen getrennten Strings (except=("param1" "param2")). Gibt an, dass URLs, die sich nur durch die aufgelisteten Parameter unterscheiden, werden als separate Einträge im Cache gespeichert. Eine boolesche params-Direktive muss enthalten sein, damit sie wirksam wird (params, except=("param1" "param2")). Das Vorhandensein anderer Parameter, die nicht in der except=-Liste sind, wird nicht bewirken, dass URLs separat im Cache gespeichert werden.

Die Speculation Rules API unterstützt die Verwendung des No-Vary-Search-Headers, um eine bereits vorab abgerufene oder vorgerenderte Seite für unterschiedliche URL-Parameter wiederzuverwenden — falls sie im No-Vary-Search-Header enthalten sind.

Die Speculation Rules API kann auch ein expects_no_vary_search-Feld enthalten, das dem Browser anzeigt, welchen No-Vary-Search-Wert (falls vorhanden) für Dokumente erwartet wird, für die sie Vorababruf/Vor-Render-Anfragen über die Spekulationsregeln erhält. Der Browser kann dies nutzen, um im Voraus zu bestimmen, ob es nützlicher ist, auf einen bestehenden Vorabruf/Vor-Render zu warten oder eine neue Abrufanfrage zu starten, wenn die Spekulationsregel übereinstimmt. Siehe das „expects_no_vary_search“-Beispiel für eine Erklärung, wie dies verwendet werden kann.

Wenn Sie beispielsweise eine Suchseite haben, die ihre Suchkriterien in URL-Parametern speichert und nicht garantieren können, dass die Parameter jedes Mal in derselben Reihenfolge zur URL hinzugefügt werden, können Sie Antworten von URLs, die bis auf die Reihenfolge der Parameter identisch sind, denselben Cache-Eintrag zuordnen lassen, indem Sie key-order verwenden:

No-Vary-Search: key-order

Wenn dieser Header zu den zugehörigen Antworten hinzugefügt wird, würden die folgenden URLs beim Durchsuchen des Caches als gleichwertig behandelt:

https://search.example.com?a=1&b=2&c=3
https://search.example.com?b=2&a=1&c=3

Das Vorhandensein unterschiedlicher URL-Parameter wird jedoch bewirken, dass diese URLs separat im Cache gespeichert werden. Zum Beispiel:

https://search.example.com?a=1&b=2&c=3
https://search.example.com?b=2&a=1&c=3&d=4

Die unten stehenden Beispiele veranschaulichen, wie Sie steuern können, welche Parameter im Kontext der Cache-Abgleichung ignoriert werden.

Betrachten Sie einen Fall, in dem eine Benutzerverzeichnis-Startseite, /users, bereits im Cache gespeichert wurde. Ein id-Parameter könnte verwendet werden, um Informationen zu einem bestimmten Benutzer anzuzeigen, beispielsweise /users?id=345. Ob diese URL für Cache-Abgleichungszwecke als identisch betrachtet werden soll, hängt vom Verhalten der Anwendung ab:

• Wenn dieser Parameter den Effekt hat, eine völlig neue Seite mit den Informationen für den angegebenen Benutzer zu laden, sollte die Antwort von dieser URL separat im Cache gespeichert werden.
• Wenn dieser Parameter den Effekt hat, den angegebenen Benutzer auf derselben Seite hervorzuheben und möglicherweise ein Ausziehpanel mit deren Daten anzuzeigen, wäre es besser, wenn der Browser die im Cache gespeicherte Antwort für /users verwendet. Dies könnte Leistungsverbesserungen beim Laden der Benutzerseiten zur Folge haben.

Wenn Ihre Anwendung wie im zweiten obigen Beispiel funktioniert, könnten Sie bewirken, dass sowohl /users als auch /users?id=345 für Caching-Zwecke als identisch behandelt werden, indem Sie einen No-Vary-Search-Header wie folgt verwenden:

No-Vary-Search: params=("id")

Angenommen, Sie hatten auch URL-Parameter, die die Liste der Benutzer auf der Seite in aufsteigender oder absteigender alphabetischer Reihenfolge sortierten und die Sprache zum Anzeigen der UI-Zeichenfolgen festlegten, z.B. /users?id=345&order=asc&lang=fr.

Sie könnten den Browser veranlassen, alle diese zu ignorieren, wenn die Cache-Abgleichung in Betracht gezogen wird, wie folgt:

No-Vary-Search: params=("id" "order" "lang")

Wenn Sie wollten, dass der Browser alle diese und alle anderen ignoriert, die beim Abgleichen des Caches vorhanden sein könnten, könnten Sie die boolesche Form von params verwenden:

No-Vary-Search: params

Angenommen, die App verhält sich anders, wobei /users auf die Haupt-Startseite des Benutzerverzeichnisses verweist und /users?id=345 auf eine völlig separate Detailseite für einen bestimmten Benutzer verweist. In diesem Fall möchten Sie, dass der Browser alle oben genannten Parameter für Cache-Abgleichszwecke ignoriert, außer für id, dessen Vorhandensein dazu führen würde, dass der Browser den /users-Cache-Eintrag nicht abgleicht und /users?id=345 vom Server anfordert.

Dies kann wie folgt erreicht werden:

No-Vary-Search: params, except=("id")

• HTTP Caching: Vary und Vary Header