Der Thread der endgültig alle Shared Cache Probleme klärt (oder wieder umsonst ist)

[betatester]

Seit der Shared Cache (vormals Seitencache) auf das Proxy Konzept umgestellt wurde, bin ich regelmäßig am Verzweifeln. Ich schaffe es kaum noch, dass Contao Seiten von mir cached.

Dazu haben wir hier auch sehr widersprüchliche Infos. Aus meiner Sicht wiederspricht sich sogar das Handbuch, welches zuerst sagt dass die COOKIE_WHITELIST definiert welche Cookies bei der Applikation ankommen sollen und somit "Deaktivierung des Cachings zur Folge haben", dann aber ein Codeschnippsel zeigt, welches genau diese Standard Cookies auf die Whitelist setzt und somit "Die höchste Anzahl Cache-Treffer und somit optimale Performance" bringen soll. Hier kann ja eigentlich nur eine der beiden Behauptungen stimmen.

Eine Forensuche bringt dann ebenfalls sehr viel Verwirrung, User plagen sich mit der Whitelist, meist ohne zu einem Ergebnis zu kommen.

Ich möchte daher folgendes Szenario zur Diskussion stellen:

- Contao 4.13.44
- Es wurde sichergestellt dass keine Backend Session offen ist
- Seite hat Private und Shared Cache auf 3 Tage
- Da es keine User bezogenen Inhalte gibt, wurde sogar der Haken "immer aus dem Shared Cache laden" rein gemacht
- auf den betroffenen Seiten existieren keine Formulare
- Gemäß Browser Konsole existieren einzig die Cookies PHPSESSID und csrf_https-contao_csrf_token (dürfte ja spätestens mit dem "Immer shared Cache" Haken kein Problem sein)

Dennoch kein Caching, stets

Contao-Private-Response-Reason: session-cookie
Contao-Cache: miss

im Header.

Wo geht nun die Ursachensuche los?

[Spooky]

Dazu haben wir hier auch sehr widersprüchliche Infos. Aus meiner Sicht wiederspricht sich sogar das Handbuch, welches zuerst sagt dass die COOKIE_WHITELIST definiert welche Cookies bei der Applikation ankommen sollen und somit "Deaktivierung des Cachings zur Folge haben", dann aber ein Codeschnippsel zeigt, welches genau diese Standard Cookies auf die Whitelist setzt und somit "Die höchste Anzahl Cache-Treffer und somit optimale Performance" bringen soll. Hier kann ja eigentlich nur eine der beiden Behauptungen stimmen.

Nein, das ist schon richtig so. Wenn du die COOKIE_WHITELIST definierst - dort also nur die Cookies definierst, die von der Applikation (wenn vorhanden) unbedingt benötigt werden, werden alle anderen Cookies nicht an die Applikation weitergeleitet und somit erhöht sich die Chance, dass die Response aus dem Cache kommt.

[Spooky]

Wo geht nun die Ursachensuche los?

Irgendetwas in deinem Setup erzeugt eine Session. Das musst du los werden - oder "Immer aus dem Shared Cache" laden aktivieren, wenn du weißt, dass die Session den Inhalt einer Seite nicht verändern kann (potentiell gefährlich).

[betatester]

oder "Immer aus dem Shared Cache" laden aktivieren

Eben. Das ist ja aktiviert.

Nein, das ist schon richtig so. Wenn du die COOKIE_WHITELIST definierst - dort also nur die Cookies definierst, die von der Applikation (wenn vorhanden) unbedingt benötigt werden, werden alle anderen Cookies nicht an die Applikation weitergeleitet und somit erhöht sich die Chance, dass die Response aus dem Cache kommt.

Danke. Das ist schonmal eine Erkenntnis. Also eine Whitelist tut nicht nur whitelisten, sie schließt also auch alle anderen aus, wenn ich Dich richtig verstehe.

[Spooky]

Also eine Whitelist tut nicht nur whitelisten, sie schließt also auch alle anderen aus, wenn ich Dich richtig verstehe.

Korrekt, sobald du die `COOKIE_WHITELIST` definiert hast, werden nur mehr diese Cookies an die Applikation durchgelassen. Hast du keine `COOKIE_WHITELIST` definiert, entfernt Contao nur einige bekannte Cookies, die keine Relevanz für die Applikation haben im Normalfall (wie zB. tracking cookies von Google oder Matomo etc.).

[betatester]

Danke.
Bleibt für mich die Frage warum ich mit "Immer aus dem Shared Cache laden" (ich bin mir der Risiken bewusst und mache das nur bei Seiten die keine Userbezogenen Inhalte haben) stets in die Röhre schaue. Und das schon seit wirklich einigen Contao Versionen.

[Spooky]

Müsste man debuggen. Ich würde aber an deiner Stelle eher verfolgen, warum eine Session gestartet wird. Allein schon um unnötige Cookies zu verhindern.

[betatester]

Ich würde es gern debuggen. Wo fang ich an? Aus meiner Sicht tut dieser "Immer" Haken einfach nicht das was man erwarten würde.

Sessions unterbinden ist manchmal schwer möglich.

[Spooky]

Sessions unterbinden ist manchmal schwer möglich.

In wie fern?

[betatester]

Ich hab es für die Dinge die ich selbst programmiere unter Kontrolle. Aber nicht für Erweiterungen.

[Spooky]

Ich hab es für die Dinge die ich selbst programmiere unter Kontrolle. Aber nicht für Erweiterungen.

Naja, dann musst du für diese Erweiterungen ggf. Pull Requests stellen, damit nicht unnötig Sessions gestartet werden.

[betatester]

Vielleicht. Aber im Moment erscheint mir ein PR zielführender, warum der "Immer Shared Cache" haken nichts tut.

[Spooky]

Wo fang ich an?

Da lässt sich nicht pauschal sagen - wenn du das debuggen willst musst du dich wohl zwangsläufig mit der Materie (also der Implemenation in Contao) tiefer beschäftigen.

[tab]

Ich habe gerade mal was getestet bei einer meiner privaten Websites. Diese ist mit einem Basic Auth Verzeichnisschutz gegen nicht genehmigte Besucher geschützt, was dann auch in einem Cookie resultiert, was die Auslieferung aus dem Public Cache verhindert. Damit könnte ich mittlerweile von der Ladezeit her leben, aber in älteren Contao-Versionen war das eher nicht so, weshalb ich seit langer Zeit für alle Frontend-Seiten "Immer aus dem Shared-Cache laden" aktiviert habe. Die "Cachezeit Shared Cache" habe ich auf 1 Jahr eingestellt.
Funktioniert auch ganz prima, die Seiten werden aus dem Shared-Cache geladen.

Eine Tücke musste ich dafür allerdings überwinden. Die Seiten müssen auch erst mal im Shared-Cache drin sein . Ansonsten, dazu habe ich gerade mal in der Systemwartung den Shared-Cache gelöscht, sieht das dann auch bei mir so aus:

contao-cache: miss
contao-private-response-reason: authorization

Und das bleibt auch so, egal wie oft ich die Seite aufrufe, weil das Authorization Cookie die Aufnahme der Seite in den Shared-Cache verhindert.

Die Seiten wieder in den Cache zu bringen gestaltet sich daher etwas mühsam und ist nicht durch normale Benutzung der Website zu erreichen.

Zum Glück unterstützt mich dabei der Crawler. Ich lasse beim Verzeichnisschutz die lokale IP des Webservers als Ausnahme zu. Dann lasse ich durch den Crawler in der Systemwartung alle Seiten aufrufen, danach sind die Seiten im Shared Cache.

Eh voilà:

contao-cache: fresh

Die Ursache ist nicht die selbe wie bei dir, aber sie ist im Kern ähnlich. Es existiert ein Cookie, das die Aufnahme der gerade geladenen Seite in den Shared-Cache verhindert. Bei dir ist es wohl das Session Cookie, das muss dann wohl doch irgendwie weg oder du musst eine Möglichkeit finden, die Seiten ohne Session-Cookie aufzurufen. Vielleicht reicht es bei dir ja schon, den Crawler zu starten. Ich gehe fast davon aus. Bei mir hat eben der Verzeichnisschutz den Crawler daran gehindert die Seiten zu laden.

[betatester]

Dankeschön!
Das mit Basic Auth ist mir klar, ist aber bei mir nicht vorhanden.

Ich habe auch gerade die Seite erfolgreich crawlen lassen, ändert leider auch nichts.

Ich frage mich halt, wenn das Session Cookie das Problem ist (ich such gerade parallel nach dessen Ursache) - wozu existiert der "Immer aus dem Shared Cache" Haken dann überhaupt?

[Spooky]

Ich frage mich halt, wenn das Session Cookie das Problem ist (ich such gerade parallel nach dessen Ursache) - wozu existiert der "Immer aus dem Shared Cache" Haken dann überhaupt?

Damit Mitglieder, die im Frontend eingeloggt sind, die Response trotzdem aus dem Cache bekommen. Aber dafür müssen die Seiten natürlich erst mal auch im Cache vorhanden sein.

[betatester]

Damit Mitglieder, die im Frontend eingeloggt sind, die Response trotzdem aus dem Cache bekommen. Aber dafür müssen die Seiten natürlich erst mal auch im Cache vorhanden sein.

Wie sollte das funktionieren? Ein eingeloggter Frontend User sendet zwangsweise ein Session Cookie und damit gibts keine gecachte Seite.

[Spooky]

Wie gesagt bekommst du auch mit Session Cookie die Seite aus dem Cache, wenn Immer aus dem Shared Cache aktiv ist. Die Seite muss dazu wie gesagt aber schon im Cache existieren (also durch Aufrufe ohne Session Cookie bspw.).

[tab]

Damit Mitglieder, die im Frontend eingeloggt sind, die Response trotzdem aus dem Cache bekommen. Aber dafür müssen die Seiten natürlich erst mal auch im Cache vorhanden sein.

Ja, du solltest also erst mal checken, ob die Seiten überhaupt im Shared-Cache vorhanden sind. Ansonsten kann ich mir nur vorstellen, dass bei dir auch beim Crawler ein Session-Cookie erzeugt und beim Seitenaufruf mitgeschickt wird. Was durchaus wahrscheinlich ist, wenn das Session-Cookie in irgendeiner Erweiterung grundsätzlich immer erzeugt wird. Dann hilft es nur, dieses Session-Cookie irgendwie loszuwerden, also die Erweiterung dementsprechend zu ändern. Nach meinen damaligen Diskussionen bin ich schon froh, dass es die Option "Immer aus dem Shared-Cache laden" überhaupt gibt. Ich hatte da für meinen Anwendungsfall sicher noch relativ bessere Argumente als du, die Seiten trotz Cookie (Basic Auth) in den Shared-Cache aufzunehmen. Geholfen hat es nichts. Letztlich auch korrekt.

[Spooky]

@tab für deinen Fall könntest du ein Vary auf Authorization hinzufügen (siehe z.B. auch https://github.com/inspiredminds/con...ryListener.php).

[betatester]

Inspiriert durch eure Beiträge habe ich jetzt mal folgendes gemacht:

1) Privates Browserfenster, sichergestellt dass keine Cookies da sind
2) Im Browser eingestellt dass die Seite keine Cookies setzen darf

Die Annahme: gibt es kein Session Cookie, kann diese auch das Caching nicht verhindern.

Also die Seite angesurft, mehrmals sichergestellt dass keine Cookies da sind (sind sie nicht) herum geklickt, ge-reloadet.

Was sagt der Http Header dazu?

Contao-Private-Response-Reason: session-cookie
Contao-Cache: miss

Jetzt wirds doch schräg, oder?

[Spooky]

Jetzt wirds doch schräg, oder?

Nein, es ist ja deine Applikation die ein Session-Cookie sendet. Das verhindern der Nutzung von Cookies in deinem Browser beeinflusst das nicht.

[betatester]

Die Annahme war dass zumindest mal der Cache befüllt wird, wenn ein Request ohne Cookies daher kommt. Aber ich versteh schon, der Reverse Proxy sieht dass die App ein Cookie sendet und lässt es wieder bleiben.

Wieder mal einen Tag in das Thema investiert. Ich geb auf vorerst.

[Spooky]

Die Annahme war dass zumindest mal der Cache befüllt wird, wenn ein Request ohne Cookies daher kommt.

Der Cache wird nicht befüllt, wenn:

• die Response einen Authorization Header enthält,
• oder während des Requests eine Session gestartet und befüllt wurde,
• oder die Response mindestens ein Cookie enthält,
• oder der ursprüngliche Request mindestens ein Cookie und die Response einen Vary: Cookie Header enthält.

(siehe MakeResponsePrivateListener)

[betatester]

So, der aktuelle Anlassfall (also die Website an der ich hier gerade geknabbert habe) ist nun gelöst. Es war hier ein Premium Contao Theme mit an Board und der Entwickler hat sich hier dankenswerterweise sehr viel Zeit genommen um die Ursache einzugrenzen. In dem Fall hat es wohl damit zu tun wie der Google Fonts Consent abgearbeitet wird. Wer mag, kann das nachlesen.

Nun werde ich mir die nächsten Kandidaten (nicht Premium Contao Theme related) vorknöpfen. Ich halte über Erkenntnisse hier am Laufenden.

[Spooky]

Ja, die Suche nach Schriften, die der TD dynamisch einbinden soll, wenn man die Schriften nicht lokal einbindet.
Hier durchläuft die Routine auch eine Prüfung, ob sich ggf. Schriftart-Daten in der Session vorfinden lassen. Die Session ist für den TD zwar leer, aber wird angeklopft.

Ich ändere die Logik dahingehend, dass wenn es einen aktiven Layout-Speicherpunkt gibt und der TD nicht im Bearbeiten-Modus läuft, sich der TD sich ausschließlich aus den Daten des Speicherpunkts bedient.

PCT muss einfach nur ein ->isStarted() einbauen, weil ein ->has() oder ->get() bereits die Session startet.

[Spooky]

Wenn https://github.com/contao/contao/pull/7281 gemerged und released wird, sollte das Fehlen der ->isStarted() Prüfung nicht mehr diese Auswirkung haben, wenn man ->has() oder ->get() nutzen will, theoretisch.