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 dazu führen, dass URLs separat zwischengespeichert werden.

params Optional

Entweder ein Boolean oder eine Liste von Zeichenfolgen:

• Als Boolean (params) gibt es an, dass sich unterscheidende URLs nur durch ihre Parameter nicht als separate Einträge im Cache gespeichert werden.
• Eine innere Liste von durch Leerzeichen getrennten Zeichenfolgen (params=("param1" "param2")). Gibt an, dass URLs, die sich nur durch die aufgelisteten Parameter unterscheiden, nicht als separate Einträge zwischengespeichert werden. Das Vorhandensein anderer Parameter wird dazu führen, dass sie separat zwischengespeichert werden.

except Optional

Eine innere Liste von durch Leerzeichen getrennten Zeichenfolgen (except=("param1" "param2")). Gibt an, dass URLs, die sich nur durch die aufgelisteten Parameter unterscheiden, werden als separate Einträge zwischengespeichert. Eine params-Boolean-Direktive muss enthalten sein, damit es wirksam wird (params, except=("param1" "param2")). Das Vorhandensein anderer Parameter, die nicht in der except=-Liste sind, wird nicht dazu führen, dass URLs als separate Einträge zwischengespeichert werden.

Die Speculation-Rules-API unterstützt die Verwendung des No-Vary-Search-Headers, um eine vorhandene vorab geladene oder vorgeladene Seite für unterschiedliche URL-Parameter wiederzuverwenden, wenn diese im No-Vary-Search-Header enthalten sind.

Die Speculation-Rules-API kann auch ein expects_no_vary_search-Feld enthalten, das dem Browser angibt, welcher No-Vary-Search-Wert (falls vorhanden) für Dokumente erwartet wird, für die er Prefetch/Prerender-Anfragen über Spekulationsregeln erhält. Der Browser kann dies nutzen, um im Voraus zu bestimmen, ob es nützlicher ist, auf ein vorhandenes Prefetch/Prerender zu warten oder eine neue Fetch-Anfrage zu starten, wenn die Spekulationsregel erfüllt ist. Siehe das "expects_no_vary_search"-Beispiel zur Erklärung, wie dies genutzt werden kann.

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

No-Vary-Search: key-order

Wenn dieser Header den zugehörigen Antworten hinzugefügt wird, werden die folgenden URLs bei der Cache-Suche 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 verschiedener URL-Parameter wird jedoch dazu führen, dass diese URLs separat zwischengespeichert 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 nachfolgenden Beispiele zeigen, wie zu steuern ist, welche Parameter im Kontext des Cache-Matchings ignoriert werden.

Betrachten Sie einen Fall, in dem eine Benutzerverzeichnis-Landingpage, /users, bereits zwischengespeichert 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-Matching-Zwecke als identisch betrachtet werden sollte, hängt vom Verhalten der Anwendung ab:

• Wenn dieser Parameter die Wirkung hat, eine völlig neue Seite zu laden, die die Informationen für den angegebenen Benutzer enthält, sollte die Antwort von dieser URL separat zwischengespeichert werden.
• Wenn dieser Parameter die Wirkung hat, den angegebenen Benutzer auf derselben Seite hervorzuheben und möglicherweise ein Pullout-Panel anzeigt, das deren Daten zeigt, wäre es besser, wenn der Browser die zwischengespeicherte Antwort für /users verwenden würde. Dies könnte Leistungsvorteile beim Laden der Benutzerseiten bringen.

Wenn sich Ihre Anwendung wie im zweiten Beispiel oben verhält, könnten Sie sowohl /users als auch /users?id=345 so behandeln lassen, dass sie für Caching-Zwecke identisch sind, indem Sie einen No-Vary-Search-Header verwenden wie folgt:

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

Angenommen, Sie hatten auch URL-Parameter, die die Liste von Benutzern auf der Seite in aufsteigender oder absteigender alphabetischer Reihenfolge sortierten und die Sprache festlegten, in der die UI-Zeichenfolgen angezeigt wurden, beispielsweise /users?id=345&order=asc&lang=fr.

Sie könnten den Browser veranlassen, alle diese zu ignorieren, wenn es um Cache-Matching geht, wie folgt:

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

Wenn Sie wollten, dass der Browser alle von ihnen und andere, die möglicherweise vorhanden sind, beim Cache-Matching ignoriert, könnten Sie die boolesche Form von params verwenden:

No-Vary-Search: params

Angenommen, die App verhält sich anders, sodass /users auf die Hauptverzeichnis-Landingpage verweist und /users?id=345 auf eine völlig separate Detailseite für einen bestimmten Benutzer. In diesem Fall möchten Sie, dass der Browser alle oben genannten Parameter beim Cache-Matching ignoriert, außer id, dessen Vorhandensein den Browser dazu veranlassen würde, den Cache-Eintrag von /users nicht zu matchen und /users?id=345 vom Server anzufordern.

Dies kann wie folgt erreicht werden:

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

• HTTP-Caching: Vary und Vary-Header