No-Vary-Search

key-order Optional

Gibt an, dass URLs nicht als separate Einträge zwischengespeichert werden, wenn nur die Reihenfolge, in der die Parameter in der URL erscheinen, unterschiedlich ist. Die Anwesenheit anderer Parameter wird jedoch dazu führen, dass URLs separat zwischengespeichert werden.

params Optional

Entweder ein Boolean oder eine Liste von Strings:

• Als Boolean (params), bedeutet es, dass URLs, die sich nur durch ihre Parameter unterscheiden, nicht als separate Einträge zwischengespeichert 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 zwischengespeichert werden. Die Anwesenheit anderer Parameter wird dazu führen, dass sie separat zwischengespeichert 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, als separate Einträge zwischengespeichert werden. Eine params-Boolean-Direktive muss vorhanden sein, damit es wirksam wird (params, except=("param1" "param2")). Die Anwesenheit anderer Parameter, die nicht in der except= Liste enthalten sind, wird nicht dazu führen, dass URLs als separate Einträge im Cache gespeichert werden.

Die Speculation Rules API unterstützt die Verwendung des No-Vary-Search Headers, um eine vorhandene vorab geladene oder prerenderte 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 mitteilt, welchen No-Vary-Search-Wert (falls vorhanden) er für Dokumente erwartet, die er über Spekulationsregeln für prefetch/prerender Anfragen erhält. Der Browser kann dies verwenden, um im Voraus zu bestimmen, ob es nützlicher ist, auf ein vorhandenes prefetch/prerender zu warten, oder einen neuen Fetch-Anfrage zu starten, wenn die Spekulationsregel übereinstimmt. Sehen Sie sich das "expects_no_vary_search" Beispiel an, um zu erfahren, wie dies verwendet werden kann.

Wenn Sie zum Beispiel eine Suchseite haben, die ihre Suchkriterien in URL-Parametern speichert, und Sie nicht garantieren können, dass die Parameter jedes Mal in derselben Reihenfolge zur URL hinzugefügt werden, können Sie Antworten von URLs zulassen, die identisch sind, mit Ausnahme der Reihenfolge der Parameter, um dem gleichen Cache-Eintrag zu entsprechen, 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 als äquivalent behandelt, wenn im Cache gesucht wird:

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

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

Die folgenden Beispiele veranschaulichen, wie Sie steuern können, welche Parameter im Zusammenhang mit dem Cache-Matching ignoriert werden.

Betrachten Sie den Fall, in dem eine Benutzerverzeichnis-Startseite, /users, bereits zwischengespeichert wurde. Ein id-Parameter könnte verwendet werden, um Informationen zu einem bestimmten Benutzer anzuzeigen, zum Beispiel /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 herausziehbares Panel zu zeigen, dass ihre Daten anzeigt, dann wäre es besser für den Browser, die zwischengespeicherte Antwort für /users zu verwenden. Dies könnte Leistungsvorteile beim Laden der Benutzerseiten mit sich bringen.

Wenn Ihre Anwendung sich wie das oben beschriebene zweite Beispiel verhält, könnten Sie sowohl /users als auch /users?id=345 als identisch für Cachenzwecke behandeln, 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 festlegen, in der die UI-Strings angezeigt werden sollen, zum Beispiel /users?id=345&order=asc&lang=fr.

Sie könnten den Browser dazu bringen, all diese bei der Berücksichtigung des Cache-Matchings zu ignorieren, wie folgt:

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

Wenn Sie wollten, dass der Browser alle von ihnen und alle anderen, die bei Cache-Matching vorhanden sein könnten, ignoriert, könnten Sie die boolesche Form von params verwenden:

No-Vary-Search: params

Angenommen, die App würde sich anders verhalten, wobei /users auf die Hauptseite des Benutzerverzeichnisses verweisen würde, 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 für Cache-Matching-Zwecke ignoriert, außer id, dessen Vorhandensein den Browser dazu bringen würde, den Cache-Eintrag für /users nicht abzustimmen 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