Probleme mit Browser Cache #3184
Comments
|
Du hast Recht, allerdings ist die Lösung mit dem angehängten --- Originally created on July 29th, 2011, at 05:41pm |
|
Das Problem ist doch dass der Browser cacht, und somit den Server gar nicht angefragt wird. Damit wird auch ein Header schwierig, mir fällt da nur der ETag ein. --- Originally created on July 30th, 2011, at 09:07am |
|
Vielleicht könnte euch http://www.mnot.net/cache_docs/ noch helfen. --- Originally created by innovativecreation on July 30th, 2011, at 10:15am |
|
@andreas: Ja, der ETag wäre imho die saubere Lösung. Von daher gibt es imho 2 Varianten, wobei ich die erstere bevorzuge
--- Originally created by SunBlack on July 30th, 2011, at 06:46pm |
|
U.a. genau wegen dem Browser Cache habe ich mich mit Contao beschäftigt. Insofern bin ich gegen die halbe Kastration des Browsercache, der bei einigen Browsern dann evtl. sogar zu vollständigen Deaktivierung führt. Daher möchte ich mich noch mal für meine effektive Lösung aussprechen, die auch sehr einfach zu realisieren wäre: Das wäre eine einfache Änderung in nur einem Modul. --- Originally created by Georg on July 31st, 2011, at 02:30pm |
|
Es gibt eigentlich ein paar Dinge die dagegen sprechen:
Zum Etag: Wie gesagt, es werden zwar mehr HTTP-Anfragen gestellt, aber wenn das System sinnvoll mit Etags umgeht (also den ETag wirklich solange behält, wie sich die Seite nicht verändert hat und nicht zeitabhängig) sind ETags vermutlich trotzdem sparsamer, da Traffic gespart wird (wieviele Anfragen kann man an einen Server schicken um die gleiche Last zu erreichen, wie ein vollständiges generieren einer Seite?). Abgesehen davon: Die Änderung würde lediglich die html-Seite betreffen - sprich 1 von vielen Dateien, die vom Server angefragt wird. Schau dir einfach mal den Netzwerkverkehr an, wenn du eine Seite aufrufst, die du bereits im Cache hast: Für jedes Bild wird eine erneute Anfrage an den Server gesendet, ob sie gleich geblieben ist. Und merkst du etwas davon? Nein. Durch die .htaccess kann man zwar den Browser sagen, dass er dies bei Bildern nicht mehr machen soll, in dem man den Header ändert, aber auf den meisten Webseiten ist dies nicht der Fall. Von daher glaube ich nicht, dass eine Anfrage mehr (bei bestimmt mind. 10-20 die bei einer Webseite bei jedem Aufruf ausgeführt werden) spürbar ist. Das einzige Argument gegen ETags ist imho, das Contao darauf nicht ganz vorbereitet ist, sprich er den Etag zeitabhängig verwerfen muss - wobei, eigentlich nicht...
Vergleich jetzt ETag vs. max-age: Zu bedenken ist dabei: Wenn du eine Cachezeit von 2h einstellt, weil du selten Änderungen einpflegst, würden alle Benutzer die Änderung sofort bemerken, sobald Contao den Etag für ungültig erklärt (was er bei einer Änderung an einem Artikel erzwingen kann). Bei max-age bekommen die Benutzer es zeitverzögert. Wie gesagt: Ich empfinde den Vorteil von ETag höher, als den von max-age. Letztere finde ich für konstante Ressourcen deutlich geeigneter (Hintergrundgrafiken und so ändern sich doch arg selten, und da kann man einfach die Pfade variieren, wenn eine Änderung an alle Benutzer gleichzeitig raus soll) --- Originally created by SunBlack on July 31st, 2011, at 02:58pm |
|
Ich sehe eine Einführung des ETEG Flags nur als Optimierung des Server Cache Modus. Damit kann dann der Browser Cache Modus in Contao also gleich ganz entfallen! Ich habe aber viele Bauchschmerzen mit dem ETEG Tag: Und ich sehe auch die Vorteile eines echten Browser Cache Modus, so wie er bisher in Contao existiert. Und bezüglich der Serverbelastung ist bis zur Entscheidungsfindung in Contao, dass evtl. nur ein 304 als Antwort gesendet werden muss, schon soviel passiert, dass die Ausgabe der Seite dann auch keine spürbare Mehrbelastung für den Server darstellt. Also bringt die ETEG Optimierung nur etwas für den Client - nicht jedoch für den Server. Aber wie schon gesagt: der ETEG Modus wäre nur eine Optimierung des Contao Server Cache Modus - aber kein Ersatz für den Contao Browser Cache Modus. --- Originally created by Georg on July 31st, 2011, at 10:25pm |
|
Was hatte ich da nur im Kopf: natürlich meine ich den ETag Header.... --- Originally created by Georg on August 1st, 2011, at 08:46am |
|
@SunBlack: Wieso siehst Du bei dem zusätzlichen URL Parameter für eingeloggte User ein Problem mit w3c? --- Originally created by Georg on August 1st, 2011, at 09:17am |
|
@SunBlack: Meintest Du folgendes mit w3c konform: --- Originally created by Georg on August 1st, 2011, at 09:40am |
|
Wenn man es von php automatisch ergänzen lässt... --- Originally created by SunBlack on August 4th, 2011, at 04:53pm |
|
ETags sind keine Alternative, solange sie nicht zuverlässig von allen Browsern unterstützt werden. Auch das Anhängen von Parametern wird nur bedingt funktionieren, denn damit diese URLs angeklickt werden können, müssen sie zunächst im Quelltext ausgegeben werden. Und genau das funktioniert nicht, wenn die Seite bereits im Cache ist. Vermutlich bräuchte man dafür ein JavaScript, das auf jeden Fall immer ausgeführt werden kann. Nur wie erkennt dieses, ob sich jemand angemeldet hat? --- Originally created on August 4th, 2011, at 05:00pm |
|
Wir unterstützen ja nicht mal mehr den IE6, welche Browser können denn kein ETag? Und was ist daran schlimm wenn die dann halt nicht Cachen? --- Originally created on August 4th, 2011, at 05:07pm |
|
Man kann ein System nicht "mal eben" auf ETags umrüsten. Es hat schon seinen Grund, warum (noch) niemand damit arbeitet :) --- Originally created on August 4th, 2011, at 05:09pm |
|
Wie steht es denn mit einem --- Originally created on August 4th, 2011, at 05:10pm |
|
Bezüglich Vary habe ich für den IE folgende Hinweise gefunden:
Eine Klarstellung zu dem zusätzlichem URL Parameter: Sobald sich jedoch ein Nutzer erfolgreich angemeldet hat, soll Contao zwei Dinge ändern:
Der Contao Server soll den zusätzliche URL Parameter bei einem Browser Request völlig ignorieren. Das Anhängen dieses URL Parameter durch den Contao Server könnte z.B. so ähnlich ablaufen, wie das neue Contao erst ganz zum Schluss in dem HTML Dokument Informationen zum Browser Agent an die CSS Klasse anhängt. Beim Login eines Nutzers sorgt der Post Data Request automatisch für das Löschen der Seite im Browser Cache. Eine evtl. im Browser Cache gespeicherte Version für nicht angemeldete Nutzer muss also nicht gelöscht werden. Der angemeldete Nutzer dagegen ruft nach dem Login nur noch URL Adressen mit dem zusätzlichen Parameter auf. Und diese Version der Seiten werden (aufgrund der HTTP Header Angaben von Contao) nicht im Browser Cache gespeichert.
--- Originally created by Georg on August 4th, 2011, at 11:41pm |
|
`Georg: Schau dir einfach mal "session.use_trans_sid" an. Wenn man das aktiviert, fügt php an alle relativen Pfade in der Ausgabe automatisch die SID an (müsste man schauen, ob man es umbiegen kann, dass es nicht die SID ist, sondern dein "BrowserCache=no"-Flag). Vorteil wäre: Es würden automatisch alle nötigen URLS angepasst werden, ohne dass man als Erweiterungsentwickler darauf achten muss. Nachteile: Der modifizierte Code ist zu mindestens nicht mehr XHTML-konform (bei Formularen), ich weiß nicht ob jeder Server es unterstützt und da es für SIDs ausgelegt ist, dürfte es auch hässlicher Code werden. Von daher würde ich diese Variante eher ablehnen. `Leo: Weißt du welche Browser ETag nicht unterstützen und marktrelevant sind (also keine Textbrowser oder so ;) )? Im Falle der nicht-unterstützung würde bei denen ja lediglich der Cache nicht funktionieren. Da imho aber alle moderneren Browser dies unterstützen, dürfte es nur sehr wenige Benutzer betreffen, wobei ich da auch nur ganz kurz im Netz geschaut habe (für mich klang es beim IE nur so, als ob er es unterstützt aber nur, wenn bestimmte andere Header nicht gesetzt sind -> müsste man austesten). Wenn wir auf jeden kleinen bzw. alten Browser achten, dürfte Contao 2.10 sonst ja auch kein CSS3-Support mitbringen... (<=IE9-Surfer ohne JS werden an den Farbverläufen Spaß haben ;) ). Also warum hier mehr Rücksicht nehmen? --- Originally created by SunBlack on August 5th, 2011, at 12:49am |
Das ist ja genau das Problem. Wenn die aufgerufene Seite bereits im Cache ist, stellt der Browser gar keine Anfrage mehr an Contao sondern nimmt einfach die Seite aus dem Cache. Deswegen funktioniert dieser Ansatz auch nicht. --- Originally created on August 5th, 2011, at 08:16am |
|
@leo: Dein Hinweis bezieht sich auf die Option zur Weiterleitung auf eine beliebige Seite. Seiten die nur für angemeldete Nutzer sichtbar sind, werden gemäß der aktuellen Contao Systematik jedoch nie im Browser Cache gespeichert. Oder anders ausgedrückt: wenn ich den registrierten Nutzer nach dem Login unbedingt auf eine Seite lenken möchte, Damit kann ich gut leben. Ich sehe auch einfach keine andere Option. --- Originally created by Georg on August 5th, 2011, at 11:44am |
|
@SunBlack: Leider besteht Leo darauf, dass in Contao auch bei öffentlichen Seiten für jeden Nutzer schon eine Session angelegt wird. Eine Umstellung der öffentlichen (und bitte nur der öffentlichen) Seiten auf eine REST Funktionalität (also ohne Session) kann nicht so schwer sein. Eröffnet auch die Option Contao auf einem Server Cluster zu betreiben. --- Originally created by Georg on August 5th, 2011, at 12:06pm |
|
@georg Außerdem kann ich Leo durchaus verstehen, dass er auch für "Gäste" eine Session erstellt. Wie willst du denn bitte eine öffentliche, von einer nicht öffentlichen Seite unterscheiden? Du kannst den Status "Nur für Mitglieder sichtbar" ja eben nicht nur für Seiten, sondern auch für Inhaltselemente einstellen. Also kannst du es nicht an der "Öffentlichkeit" einer Seite festmachen ob du eine Session startest oder nicht. Ich weiß nicht ob es Core-Funktionen gibt, die auch ohne einen Mitglieder-Login die Session benutzen. Ich weiß aber, dass ich schon Erweiterungen geschrieben hab, die das taten. Und die ganzen Daten in Cookies ablegen ... ich bitte dich, das wäre absoluter Wahnsinn. Ergo denke ich, dass wir die Session brauchen, egal ob der Besucher als Mitglied angemeldet ist oder nicht. Eine Session ist immerhin nicht nur dafür da, den Login-Status zu speichern, sondern auch die Benutzerdaten, bei Bedarf unabhängig von irgendeinem Login. Du meinst wohl auch eher REST Prinzip anstatt Funktionalität, denn mit REST Funktionalität hat deine Erläuterung gar nichts zu tun. Aber auch bei REST gibt es Authentifizierung, nur halt keine Persistente. Die kann entweder mittels Username+Passwort die dann IMMER WIEDER mitgeschickt werden geschehen oder aber mit einem AuthKey, der aber wieder gleichzusetzen mit der SID wäre. Und wie ich im Absatz oben schon erläutert habe, du kannst es eben nicht entscheiden ob eine Webseite wirklich öffentlich oder eben nicht öffentlich ist und Sessions werden eben auch für mehr gebraucht als nur den Login. Und zu guter Letzt, ich weiß ja nicht wie du Clustering betreibst, aber ob du Sessions hast oder nicht ist für das Clustering total egal. Du brauchst nur einen Session Exchange, das geht am einfachsten natürlich über eine Datenbank, dann kannst du auch mit Sessions über einen ganzen Cluster arbeiten. Das ist jetzt nur auf Webserver-Cluster bezogen. Beim Datenbank-Cluster spielt es sogar überhaupt keine Rolle ob Session da oder nicht, weil die Session etwas ist, dass im Webserver oder korrekt in PHP abgewickelt wird. Meiner Erfahrung nach ist Clustering in den meisten Fällen eher eine Frage des Application Environment, anstatt der Software. --- Originally created on August 6th, 2011, at 01:49am |
|
Ich habe grade nochmal nachgegrübelt, ich habe grad den Contao Core nicht vor mir (und will ihn um diese Zeit auch nicht mehr runter laden), deshalb muss ich etwas ins Blaue raten. Gute Nacht... --- Originally created on August 6th, 2011, at 01:59am |
|
@Tril: Contao speichert beim Besuch einer beliebigen Seite sofort die SID im Cookie "PHPSESSID". Das entspricht nach meinem Verständnis Deinem Vorschlag. --- Originally created by Georg on August 6th, 2011, at 05:48pm |
|
@Tril:
Das NoCache unter 1. gilt für die URL, von der das Formular abgesendet wurde. Das Löschen der Seite aus dem Browser Cache in Schritt 1 funktioniert auch auf der Startseite. --- Originally created by Georg on August 6th, 2011, at 11:37pm |
|
@georg
Wenn du das nachverfolgst, stellst du fest, dass dann genau das ursprüngliche Problem auftritt und die Option "zur zuletzt besuchten Seite" ODER Weiterleitungsseite nicht den Cache der Startseite löscht. Das ist ja das ursprüngliche Problem, aber weder "zur zuletzt besuchten Seite" ODER Weiterleitungsseite helfen dagegen ja nicht. So hatte ich dich zumindest verstanden, dass eine der beiden Optionen dieses Problem lösen würde. Wenn nicht, dann ignoriere mich einfach, da hab ich was in den falschen Hals bekommen. --- Originally created on August 8th, 2011, at 10:10pm |
|
@Tril: Oder wie kommt der Nutzer in Deinem letzten Schritt wieder auf die Startseite? Wenn er natürlich von Hand irgendeine URL im Browser eingibt, die sich noch im Browser Cache befindet, dann wird diese öffentliche Version auch angezeigt. --- Originally created by Georg on August 8th, 2011, at 11:29pm |
|
Nachdem die Sommerferien etwas Abstand zu diesem Thema gebracht haben: gibt es frische Ideen? Wir hatten bis jetzt: 2.) Anhängen eines Parameters an die URL
Nicht angemeldete Nutzer erhalten unverändert alle Seiten ohne den Parameter in den Links. 2a) mein Parameter Vorschlag ala "...?BrowserCache=No" 2b.) SunBlacks Vorschlag session.use_trans_sid Jedoch darf der zusätzliche Parameter für einen öffentlichen Nutzer nicht in der URL auftauchen (SEO). Hier mal eine neue Anregung: z.B. eine D.h. die /home.html bleibt statisch und kann im Browser Cache verbleiben. --- Originally created by Georg on September 2nd, 2011, at 03:20pm |
|
Simple und einfache Antwort: Man kann hier nur 2 Fallunterscheidungen machen:
Trotzdem wäre ein Umstieg auf ETag, mit sehr kleinen max-age Zeiten (< 1 min) das Beste was man machen kann. Wenn bei jemanden der Server nicht mehr hergibt, dann muss man ein Cluster verwenden oder einen größeren Server. Die sauberste Möglichkeit die mir noch einfällt wäre, eine komplett eigenen Kontextpfad einzufügen: --- Originally created by backbone on September 3rd, 2011, at 02:57am |
|
Um das nochmal ein bisschen klarer rüberzubringen mit dem eigenen Contextpfad: http://www.domain.tld/tlpath/mein/seiten/alias.html http://www.domain.tld/tlpath/u/mein/seiten/alias.html Kommt ein nicht eingeloggter User auf:
Kommt ein eingeloggter User auf:
--- Originally created by backbone on September 6th, 2011, at 02:43pm |
|
Hat sich dieses Problem nicht erledigt, seit wir in 2.11 die Option bieten den Brower-Cache nicht zu nutzen? |
|
Kann es sein, dass ich gerade in fc511a3 eine ganz einfache Lösung für dieses Problem gefunden habe? Die Seite wird einfach immer komplett gerendert, sobald ein Auth-Cookie vorhanden ist – egal ob dieses noch gültig ist oder nicht. Falls es nicht gültig war, wird es einfach gelöscht und ab dem nächsten Aufruf wird aus dem Cache geladen. Falls es aber gültig war oder die dauerhafte Anmeldung zum Tragen kommt, ist der Benutzer direkt angemeldet und das beschriebene Problem tritt nicht mehr auf. Oder habe ich etwas übersehen? |
|
Nun, das würde ja (auch) nur funktionieren wenn der Browsercache nicht aktiv ist? |
|
Du hast Recht, mein Patch löst nur einen Teil des Problems (nämlich das Server-seitige). Aber immerhin :) |
ghost
mentioned this issue
|
Das Problem ist jetzt endlich gelöst (siehe contao/core-bundle#749). |
Contao Online Demo:
Backend:
z.B. "Home", "The academy", "Courses"
=> die neuen Menuepunkte verschwinden
=> die neuen Menuepunkte werden angezeigt
Die Effekte sind klar:
Für diese URL ist damit alles in Ordnung.
Lösung:
Sobald der Nutzer im FE erfolgreich angemeldet ist, sollte an jeden seiner html Aufrufe automatisch ein Parameter angehängt werden: z.B. "&login".
Damit holt der Browser die Seiten für einen eingelogten User nicht aus dem Browser Cache.
"academy.html" ist für den Browser ja nicht gleich "academy.html?login".
--- Originally created by Georg on June 21st, 2011, at 01:42pm (ID 3184)
The text was updated successfully, but these errors were encountered: