☰

Lack - Kekse ablösen und anbringen

tag-icon • tag-icon varnish
Lack - Kekse ablösen und anbringen

Zunächst möchte ich herausfinden, ob dies möglich ist oder nicht.

Ich sehe also, dass Varnish keine Objekte zwischenspeichert, wenn es Cookies hat.

Ich denke daran, dass Varnish Cookies in Variablen speichert, entfernt und dann an das Backend weiterleitet, wenn eine eingehende Anfrage Cookies enthält. Sobald das Backend die Verarbeitung abgeschlossen hat, legt Varnish die Cookies wieder zurück.

ist das möglich?

wenn ja, wie sieht der VCL aus?

Antwort1

Kontext

Varnish ist beim Caching konservativ und geht davon aus, dass die Verwendung von Cookies ein gewisses Maß an Personalisierung der Antwort mit sich bringt.

Das Zwischenspeichern einer personalisierten Antwort kann zu Datenschutz- oder Sicherheitsproblemen führen. Es kann auch zu inkonsistenten Ergebnissen führen.

Stellen Sie sich vor, Sie würden eine Seite mit einem Einkaufswagen zwischenspeichern. Wenn Sie die ganze Seite zwischenspeichern würden, hätte jeder den gleichen Einkaufswagenwert.

Hier ist das integrierte VCL-Verhalten für Varnish für Cookies:

  • Wenn Varnish einen CookieHeader in der Anfrage sieht, wird das Objekt nicht aus dem Cache bereitgestellt, da es davon ausgeht, dass der Inhalt personalisiert ist.

Sehenhttps://www.varnish-software.com/developers/tutorials/varnish-builtin-vcl/#authorization-headers-and-cookies-are-not-cacheable

  • Wenn Varnish Set-Cookiein der Antwort einen Header sieht, speichert es das Objekt nicht im Cache, da das Setzen eines Cookies eine Statusänderung darstellt, die auch eine Personalisierung impliziert.

Sehenhttps://www.varnish-software.com/developers/tutorials/varnish-builtin-vcl/#dont-cache-responses-with-set-cookie-headers

Kekse ausstechen

Set-CookieSobald ein Cookie über den Antwortheader gesetzt wurde , wird es als CookieAnforderungsheader für jede nachfolgende Anforderung übergeben, auch für Seiten, die diese Cookies nicht wirklich benötigen.

Deshalb ist es wichtig, festzustellen, welche Seiten Cookies erfordern und welche nicht. Ebenso wichtig ist es, Tracking-Cookies zu identifizieren, da diese vom Client in Javascript und nicht auf dem Server verarbeitet werden.

Hier ist ein VCL-Beispiel, bei dem wir alle Cookies entfernen, außer denen, die wir auf dem Server benötigen:

vcl 4.1;

sub vcl_recv {
    if (req.http.Cookie) {
        set req.http.Cookie = ";" + req.http.Cookie;
        set req.http.Cookie = regsuball(req.http.Cookie, "; +", ";");
        set req.http.Cookie = regsuball(req.http.Cookie, ";(PHPSESSID)=", "; \1=");
        set req.http.Cookie = regsuball(req.http.Cookie, ";[^ ][^;]*", "");
        set req.http.Cookie = regsuball(req.http.Cookie, "^[; ]+|[; ]+$", "");
    }
    if (req.http.cookie ~ "^\s*$") {
        unset req.http.cookie;
    }
}

In diesem Fall PHPSESSIDwird nur das Cookie beibehalten, da es erforderlich ist, um die Anmeldungen zu verfolgen. Wenn dieses Cookie nach der Ersetzungslogik immer noch vorhanden ist, wird Varnish die Antwort nicht aus dem Cache bereitstellen. Wenn dieses Cookie nicht gesetzt wurde, aber eine Reihe von Tracking-Cookies vorhanden waren, werden alle Cookies entfernt und die Seite kann aus dem Cache bereitgestellt werden.

Cookies für bestimmte Seiten entfernen

Während im vorherigen Beispiel ausgewählte Cookies entfernt und nur das PHPSESSIDCookie behalten wurde, könnten Sie dennoch auf Seiten landen, die dieses Sitzungscookie eigentlich nicht benötigen.

Hier ist ein VCL-Beispiel, bei dem Cookies vollständig entfernt werden, außer auf Seiten, die tatsächlich ein bestimmtes Cookie benötigen, wie etwa die Admin-Seiten und die Warenkorb-Seite:

vcl 4.1;

sub vcl_recv {
    if(req.url ~ "^/admin" || req.url == "/cart") {
        return(pass);
    }
    unset req.http.Cookie;
}

Entfernen von Set-Cookie-Headern

Wie gezeigt aufhttps://www.varnish-software.com/developers/tutorials/varnish-builtin-vcl/#dont-cache-responses-with-set-cookie-headers, die integrierte VCL speichert kein Objekt im Cache, wenn ein Set-CookieHeader verwendet wird, da dies eine Statusänderung impliziert.

Dies bedeutet jedoch nicht, dass die Seite niemals im Cache landet: Die nächste Backend-Antwort enthält wahrscheinlich nicht den Set-CookieHeader, da das Cookie bereits gesetzt ist. In diesem Fall Set-Cookielandet die nächste Antwort ohne den Header möglicherweise im Cache.

Wenn Sie jedoch sicher sind, dass Sie für bestimmte Seiten kein Cookie setzen müssen, können Sie sich auch dafür entscheiden, den Set-CookieHeader zu entfernen.

Das folgende Beispiel verhindert, dass ein Backend ein Cookie für statische Inhalte setzt:

vcl 4.1;

sub vcl_backend_response {
    if (bereq.url ~ "^[^?]*\.(7z|avi|bmp|bz2|css|csv|doc|docx|eot|flac|flv|gif|gz|ico|jpeg|jpg|js|less|mka|mkv|mov|mp3|mp4|mpeg|mpg|odt|ogg|ogm|opus|otf|pdf|png|ppt|pptx|rar|rtf|svg|svgz|swf|tar|tbz|tgz|ttf|txt|txz|wav|webm|webp|woff|woff2|xls|xlsx|xml|xz|zip)(\?.*)?$") {
        unset beresp.http.Set-Cookie;
    }
}

Cookies erneut anfügen

Obwohl es möglich ist, den Cookie-Wert in einem Header zu speichern, die Cookies dann in VCL zu entfernen, um sie aus dem Cache bereitzustellen und sie schließlich für Backend-Anfragen erneut anzufügen, ergibt das nicht wirklich viel Sinn.

Warum sollten Sie Cookies für eine Backend-Anfrage senden, wenn die zwischenspeicherbare Antwort kein Cookie benötigt, um ihre Ausgabe zu erstellen?

Wenn für eine Backend-Anforderung der Cookie-Wert zum Erstellen der Ausgabe benötigt wird, bedeutet dies wahrscheinlich, dass die Antwort nicht zwischengespeichert werden kann. In diesem Fall können Sie den Cache für diese Anforderung auch gleich ganz umgehen.

Nächste Schritte

Da Ihre Frage nicht sehr spezifisch war, musste ich Ihnen auch eine sehr allgemeine Antwort geben.

Wenn meine Antwort Ihre Frage vollständig beantwortet, lade ich Sie ein, Ihren Anwendungsfall genauer zu beschreiben. Im Gegenzug werde ich Ihnen eine detailliertere Antwort geben.

verwandte Informationen