No-Vary-Search header

key-order Optional

Gibt an, dass URLs nicht als separate Einträge zwischengespeichert werden, wenn die Reihenfolge, in der 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 Boolescher Wert oder eine Liste von Zeichenfolgen:

• Als Boolescher Wert (params) gibt es an, dass sich unterscheidende URL-Parameter nicht als separate Einträge zwischengespeichert werden.
• Eine innere Liste von 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 Leerzeichen-getrennten Zeichenfolgen (except=("param1" "param2")). Gibt an, dass URLs, die sich nur durch die aufgelisteten Parameter unterscheiden, als separate Einträge zwischengespeichert werden. Eine boolesche params-Direktive muss enthalten sein, damit es wirksam ist (params, except=("param1" "param2")). Das Vorhandensein anderer Parameter, die nicht in der except-Liste enthalten sind, wird nicht dazu führen, dass URLs als separate Einträge zwischengespeichert werden.

Die Speculation Rules API unterstützt den Einsatz des No-Vary-Search-Headers, um eine vorhandene vorab abgerufene oder -gerenderte Seite trotz unterschiedlicher URL-Parameter wiederzuverwenden — wenn diese im No-Vary-Search-Header enthalten sind.

Die Spekulationsregeln-API kann auch ein Feld expects_no_vary_search enthalten, das dem Browser angibt, welchen erwarteten No-Vary-Search-Wert es (sofern vorhanden) für Dokumente haben wird, für die es Vorabrufe/-Renderanforderungen im Rahmen der Spekulationsregeln erhält. Der Browser kann dies nutzen, um im Voraus zu bestimmen, ob es sinnvoller ist, auf das Abschluss eines vorhandenen Vorabrufs/-Renders zu warten oder eine neue Abrufanfrage zu starten, wenn die Spekulationsregel zutrifft. Siehe das "expects_no_vary_search"-Beispiel für eine Erklärung, wie dies genutzt werden kann.

Wenn Sie beispielsweise 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 es erlauben, dass Antworten von URLs, die identisch sind, abgesehen von der Reihenfolge der Parameter, mit demselben Cache-Eintrag übereinstimmen, 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 bei der Cachesuche 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 führt jedoch dazu, 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 folgenden Beispiele veranschaulichen, wie zu steuern ist, welche Parameter im Kontext des Cache-Matchings ignoriert werden.

Betrachten Sie einen 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 angesehen werden sollte, hängt vom Verhalten der Anwendung ab:

• Wenn dieser Parameter die Auswirkung hat, dass eine völlig neue Seite mit den Informationen für den angegebenen Benutzer geladen wird, sollte die Antwort von dieser URL separat zwischengespeichert werden.
• Wenn dieser Parameter die Auswirkung hat, den angegebenen Benutzer auf derselben Seite hervorzuheben und vielleicht ein Ausziehpanel anzuzeigen, das seine Daten darstellt, wäre es besser, dass der Browser die zwischengespeicherte Antwort für /users verwendet. Dies könnte Leistungsverbesserungen beim Laden der Benutzerseiten bewirken.

Wenn sich Ihre Anwendung wie im zweiten oben beschriebenen Beispiel verhält, könnten Sie dafür sorgen, dass sowohl /users als auch /users?id=345 für Caching-Zwecke als identisch behandelt werden, mittels eines No-Vary-Search-Headers:

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

Angenommen, Sie hätten auch URL-Parameter, die die Liste der Benutzer auf der Seite in aufsteigender oder absteigender alphabetischer Reihenfolge sortieren und die Sprache für die Anzeige der UI-Zeichenfolgen angeben, 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, indem Sie Folgendes tun:

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

Wenn Sie wollten, dass der Browser alle und jede andere, die möglicherweise vorhanden sind, ignoriert, wenn das Cache-Matching berücksichtigt wird, könnten Sie die boolesche Form von params verwenden:

No-Vary-Search: params

Angenommen, die App hätte ein anderes Verhalten, wobei /users auf die Hauptbenutzerverzeichnis-Startseite 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-Matching-Zwecke ignoriert, außer für id, dessen Vorhandensein den Browser dazu veranlassen würde, den Cache-Eintrag für /users nicht abzugleichen 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