No-Vary-Search

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. Die Anwesenheit anderer Parameter wird allerdings dazu führen, dass URLs separat zwischengespeichert werden.

params Optional

Entweder ein Boolean oder eine Liste von Zeichenketten:

• Als Boolean (params) zeigt es an, dass URLs, die sich nur in ihren Parametern unterscheiden, nicht als separate Einträge zwischengespeichert werden.
• Eine innere Liste von durch Leerzeichen getrennten Zeichenketten (params=("param1" "param2")). Gibt an, dass URLs, die sich nur durch die aufgeführten Parameter unterscheiden, nicht als separate Einträge zwischengespeichert werden. Die Anwesenheit anderer Parameter wird jedoch dazu führen, dass sie separat zwischengespeichert werden.

except Optional

Eine innere Liste von durch Leerzeichen getrennten Zeichenketten (except=("param1" "param2")). Gibt an, dass URLs, die sich nur durch die aufgeführten Parameter unterscheiden, werden als separate Einträge zwischengespeichert. Eine params-Boolean-Direktive muss hinzugefügt werden, damit sie wirksam wird (params, except=("param1" "param2")). Die Anwesenheit anderer Parameter, die nicht in der except= Liste sind, wird es nicht verursachen, dass URLs als separate Einträge zwischengespeichert werden.

Falls 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 der gleichen Reihenfolge zur URL hinzugefügt werden, können Sie Antworten von URLs erlauben, die identisch sind bis auf die Reihenfolge der Parameter, um die gleiche Cache-Eintragung mit key-order zu treffen:

No-Vary-Search: key-order

Wenn dieser Header zu den zugehörigen Antworten hinzugefügt wird, würden die folgenden URLs beim Suchen im Cache 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 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 untenstehenden Beispiele veranschaulichen, wie man steuert, welche Parameter im Kontext des Cache-Matchings ignoriert werden.

Betrachten Sie einen Fall, bei dem eine Benutzerverzeichnis-Landingpage, /users, bereits zwischengespeichert wurde. Ein id Parameter könnte verwendet werden, um Informationen zu einem bestimmten Benutzer abzurufen, 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 mit den Informationen für den angegebenen Benutzer zu laden, sollte die Antwort dieser URL separat zwischengespeichert werden.
• Wenn dieser Parameter die Wirkung hat, den angegebenen Benutzer auf der gleichen Seite hervorzuheben, und möglicherweise ein herausziehbares Panel mit den Daten anzuzeigen, 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 für Cache-Zwecke als identisch behandeln, indem Sie einen No-Vary-Search Header wie folgt hinzufügen:

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 angaben, in der die UI-Zeichenfolgen angezeigt werden sollten, zum Beispiel /users?id=345&order=asc&lang=fr.

Sie könnten den Browser dazu bringen, all diese zu ignorieren, wenn es um das Cache-Matching geht:

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

Wenn Sie möchten, dass der Browser sie alle und alle anderen vorhandenen ignoriert, die beim Cache-Matching vorhanden sein könnten, können Sie die Boolean-Form von params verwenden:

No-Vary-Search: params

Angenommen, die App verhielt sich anders, mit /users, das auf die Hauptbenutzerverzeichnis-Landingpage verweist, und /users?id=345, das 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 id, dessen Vorhandensein dazu führen würde, dass der Browser den /users Cache-Eintrag nicht trifft 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