No-Vary-Search header

key-order Optional

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

params Optional

Entweder ein Boolean oder eine Liste von Zeichenfolgen:

• Als Boolean (params) zeigt 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 Zeichenfolgen (params=("param1" "param2")). Gibt an, dass URLs, die sich nur durch die aufgeführten Parameter unterscheiden, nicht als separate Einträge im Cache gespeichert werden. Das Vorhandensein anderer Parameter wird jedoch dazu führen, dass sie separat im Cache gespeichert werden.

except Optional

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

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

Die Speculation Rules API kann auch ein expects_no_vary_search Feld beinhalten, das dem Browser angibt, welcher No-Vary-Search Wert für Dokumente erwartet wird, die er als Vorab-/Prerender-Anfragen über die Spekulationsregeln erhält. Der Browser kann dies nutzen, um im Voraus zu bestimmen, ob es sinnvoller ist, auf ein bestehendes Vorab-/Prerender zu warten, oder eine neue Abruf-Anfrage zu starten, wenn die Spekulationsregel erfüllt ist. 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 in der gleichen Reihenfolge zur URL hinzugefügt werden, können Sie Antworten von URLs, die bis auf die Reihenfolge der Parameter identisch sind, erlauben, demselben 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 gleichwertig bei der Suche im Cache behandelt werden:

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 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 folgenden Beispiele veranschaulichen, wie man steuert, welche Parameter im Kontext des Cache-Matchings ignoriert werden.

Betrachten Sie einen Fall, in dem eine Startseite des Benutzerverzeichnisses, /users, bereits im Cache ist. Ein id-Parameter könnte verwendet werden, um Informationen über einen bestimmten Benutzer anzuzeigen, zum Beispiel /users?id=345. Ob diese URL als identisch für Cache-Matching-Zwecke angesehen wird, hängt vom Verhalten der Anwendung ab:

• Wenn dieser Parameter dazu führt, dass eine vollständig neue Seite mit den Informationen für den angegebenen Benutzer geladen wird, dann sollte die Antwort von dieser URL separat im Cache gespeichert werden.
• Wenn dieser Parameter dazu führt, dass der angegebene Benutzer auf derselben Seite hervorgehoben wird und vielleicht ein ausklappbares Fenster erscheint, das seine Daten anzeigt, wäre es besser, wenn der Browser die zwischengespeicherte Antwort für /users verwendet. Dies könnte zu Leistungsverbesserungen beim Laden der Benutzerseiten führen.

Wenn Ihre Anwendung sich wie im zweiten oben beschriebenen Beispiel verhält, könnten Sie sowohl /users als auch /users?id=345 über einen No-Vary-Search Header so als identisch für Cache-Zwecke betrachten lassen:

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 angeben, um die UI-Zeichenfolgen anzuzeigen, zum Beispiel /users?id=345&order=asc&lang=fr.

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

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

Wenn Sie möchten, dass der Browser all dies und alle anderen, die möglicherweise vorhanden sein könnten, beim Cache-Matching ignoriert, könnten Sie die boolesche Form von params verwenden:

No-Vary-Search: params

Angenommen, die App verhält sich anders und /users zeigt auf die Hauptseite des Benutzerverzeichnisses und /users?id=345 zeigt 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 dazu führen würde, dass der Browser den /users Cache-Eintrag nicht zuordnet 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