Browsercache

Wie wir sehen, sehen wir nichts.

--
"Wer grundlegende Freiheiten aufgibt, um vorübergehend ein wenig Sicherheit zu gewinnen, verdient weder Freiheit noch Sicherheit." -Benjamin Franklin

sollte den Code vielleicht mitsenden....

head
meta http-equiv="Refresh" content="30"
meta http-equiv="pragma" content="no-cache"
/head

habe jetzt herausgefunden das in diesem Fall der Inhalt der Seite alle 30 Sekunden neugeladen wird. Wo muss ich diesen Code einfügen um dies auf der Profilseite hinzubekommen? Oder gibt es vielleicht eine bessere Lösung?

Gruß, der Jenzen!!

Sowas gehört in den Head der HTML-Seite. Allerdings wird dir das in deinem Fall nichts nutzen, denn du willst ja das Cachen von Bildern steuern, nicht das der Seite. Da bliebe dann die entsprechenden Bilder über ein PHP-Skript ausgeben zu lassen und ihnen passende HTTP-Header mitzugeben.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9
http://de.php.net/header

--
"Wer grundlegende Freiheiten aufgibt, um vorübergehend ein wenig Sicherheit zu gewinnen, verdient weder Freiheit noch Sicherheit." -Benjamin Franklin

Ich kann grad Dein Problem mit dem Browsercache nicht nachvollziehen. Letzten Endes hat jeder Cache eine Lifetime.

Und wenn Du Dir schon Gedanken in diese Richtung machst. Was ist dann mit den Proxys? Soll ich es Dir sagen?

Verhindert, dass die Datei auf einem Proxy-Server gespeichert wird:

Nur tote Fische schwimmen mit dem Strom.

Ich bin mir nicht sicher, dass er damit den gewünschten Effekt erzielen würde, denn die Angaben bringen nur etwas für die HTML-Seite. Wenn er aber den Dateinamen des Bildes nicht ändert, bringt das zunächst mal nüscht, denn das Bild ist eine andere HTTP Ressource und hat entsprechend eigene Header mit eigenen Einstellungen, die nichts mit Gewurschtel im HTML zu tun haben.

--
"Wer grundlegende Freiheiten aufgibt, um vorübergehend ein wenig Sicherheit zu gewinnen, verdient weder Freiheit noch Sicherheit." -Benjamin Franklin

Wenn jeder Cache eine Lifetime hat dann mache ich mir evtl. doch einen Gedanken zuviel. Gibt es denn dazu eine "pauschale" Antwort, wie lange z.B. der IE oder Mozilla nicht aktualisiert. Ich will vermeiden das jemand nach längerer Zeit auf die Seite geht und dann immer noch das alte Profilbild eines Freundes sieht! In dem anderen Content kann ich problemlos den Namen des "neuen" Bildes ändern und somit eine Aktualisierung erzwingen.

Gruß, der Jenzen!

Kann ich Dich noch mehr verwirren?

Was ist mit dem Cache von Drupal?
Wenn Du den aus Performancegruenden aktiviert hast bekommst Du das gleiche Problem wie bei Deinen Ueberlegungen mit dem Browsercache.

Warum verwendest Du auf dieses Thema Energie? Ist es nur im Vorab oder schon erlebte Realitaet?
Ich glaube Du machst Dir gerade etwas zu viele Gedanken.

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Ja, du kannst mich noch mehr verwirren!!.... an einen Cache von Drupal habe ich überhaupt noch nicht gedacht! Das werde ich jetzt am besten sofort vergessen ;-)

Erlebt habe ich das schon! Momentan testen wir natürlich einwenig an allen möglichen Funktionen herum deshalb wird wohl des öfteren ein neues Profilbild hochgeladen. Wird im "normalen" Leben sicherlich nicht so oft der Fall sein. Aber momentan habe ich einfach den Eindruck das z.B. der Explorer relativ lange auf seinen Cache zurückgreift.

Möchte einfach vermeiden das User ihr Bild ändern und niemand bekommt es mit!! Will mich einfach vorbereiten falls dieser Fall eintritt, aber wenn ihr meint das der IE oder Mozilla mit Sicherheit nicht ewig nur aus dem Cache lesen ist das schon i.O.
Außderdem fällt so auch weniger Traffic an ;-)

Also Ihr meint ich sollte erstmal mit dem Gedanken abschließen?!

Trotzdem Danke!!!

Gruß, der Jenzen!!

Browser sind irrelevant. Entweder du kannst den Zeitpunkt der Aktualisierung beinflussen, oder du kannst es nicht. Die Möglichkeit, Caching zu kontrollieren, ist keine Funktionalität, dessen Vorhandensein ich für meine Seiten vorraussetzen würde.

Wenn du den Zeipunkt der Aktualisierung beinflussen kannst, dann nur über HTTP-Header. Das meta-Element, das vorgeschlagen wurde, hat aus diesem Grund ein http-equiv-Attribut, weil es equivalent zu einem HTTP-Header sein soll. meta-Elemente kommen aber nicht in Frage, da du sie nicht in Bildateien unterbringen kannst; und du willst ja das Zwischenspeichern von Bildateien steuern.

Wenn du die private Methode zum Herunterladen von Dateien gewählt hast, dann kannst du die entsprechenden Header eventuell mittels eines geeigneten Drupal-Moduls senden.

Wenn du die öffentliche Methode zum Herunterladen von Dateien gewählt hast, dann musst du an deiner Serverkonfiguration herumschrauben.

Welche Header du verwenden kannst, steht im von Alexander-Langer erwähnten RFC2616. Insbesondere der Expires-Header ist auch interessant.

Im übrigen schließe ich mich quiptime an: "Ist es nur im Vorab oder schon erlebte Realitaet?
Ich glaube Du machst Dir gerade etwas zu viele Gedanken."

--

Das Problem erledigt sich von selbst, wenn das neue Bild eine andere URI hat, als das alte.

--
"Wer grundlegende Freiheiten aufgibt, um vorübergehend ein wenig Sicherheit zu gewinnen, verdient weder Freiheit noch Sicherheit." -Benjamin Franklin

Das Problem lässt sich auf das Caching von HTML-Dateien reduzieren, wenn das neue Bild eine andere URI hat, als alle alten.

--

Da dynamische Seiten (man ist eingeloggt) aber nicht gecached werden (weil Drupal nicht ganz doof ist beim Ausspucken von Headern), stellt sich das Problem vielleicht auch nur im Kopf. ;)

--
"Wer grundlegende Freiheiten aufgibt, um vorübergehend ein wenig Sicherheit zu gewinnen, verdient weder Freiheit noch Sicherheit." -Benjamin Franklin

Ich habe verstanden wie du das meinst!
Aber da muss ich dich leider enttäuschen, denn das Problem besteht nicht nur im Kopf!! Es ist aufjedenfall Fakt das ich mein Profilbild im eingeloggten Bereich ändern kann und dann loggt sich jemand anderes unter seinem Namen ein und sieht noch mein altes Profilbild!

Gruß!

Allein die Beobachtung trifft aber keine Aussage darüber an welcher Stelle nun welcher Caching-Mechanimsus (Browser, Proxy, Drupal, Modul, ...) für den Effekt verantwortlich ist. Ohne das zu klären ist es müßig über Gegenmaßnahmen zu sprechen. Hier ist erstmal eine ordentliche Analyse nötig.

--
"Wer grundlegende Freiheiten aufgibt, um vorübergehend ein wenig Sicherheit zu gewinnen, verdient weder Freiheit noch Sicherheit." -Benjamin Franklin

Das selbe kam bei mir auch schon vor. ich denke nicht, das das ein problem von drupal ist. ich tippe mal auf proxy (vllt vom provider) oder den brauserkäsch.

--

Freiwilligendienst Community

Ich danke euch aufjedenfall für die Infos. Was die Analyse angeht, das ist sicherlich der richtige Weg! Doch wenn ich ehrlich bin weiß ich nicht wie ich damit überhaupt beginnen soll!? Mein Problem: das User wochenlang nicht sehen können das jemand ein neues Bild hochgeladen hat habe ich somit noch nicht gelöst. Vielleicht ist die Situation ja nicht so dramatisch und die lifetime, vom wem auch immer, ist nicht so lange...

Gruß, der Jenzen!!

Ich tippe auf einen eigenartig konfigurierten Proxy, der vermutlich sogar bei Deinem Hoster steht. Entweder durch Unfaehigkeit des Admins oder bewusst. Im letzteren Fall wird es wohl eher schwierig den Hoster zu Aenderungen zu bewegen. Denn wer bei Bildern die Lifetime im Proxy auf abstruse Werte setzt hat seine Gruende. Wer ist Dein Hoster? Versuche mal im Internet ueber den Hoster zu recherchieren ob es bekannte Probleme gibt.

Sollte es wirklich Dein Hoster sein der einen seltsamen Proxy betreibt muesste man ihn in die Kategorie schwarzes Schaf einstufen.

Beteht das Cachingproblem von verschiedenen Rechnern aus? Mit verschieden meine ich nicht einzelne Rechner in einem Firmennetzwerk sondern Rechner an voellig unterschiedlichen Standorten.

Man koente mit Traceroute versuchen die Proxys in Deinem "Vertriebsweg" zu ermitteln. Kennt man die Proxys kann man versuchen zu erfahren wer sie bertreibt. Aber das ist nicht unbedingt von Erfolg gekroent.

In der Konfiguration Deiner Header existiert nicht zufaellig
<META HTTP-EQUIV="Pragma" CONTENT="private"> ? Wenn ja dann weg damit.

Vermutlich hast Du das Cachingproblem nicht nur bei Userprofil-Bildern sondern generell bei Bildern. Ich wuerde schon mal ueberlegen mit dem Hoster ernsthaft zu sprechen.

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Also ich bin bei Webhostone und dort wurde mir gesagt das nichts gecacht wird. Da ich mit Webhostone bisher sehr sehr zufrieden bin nehme ich Ihnen die Aussage zu 100Prozent ab. Unter "settings/performance" ist der Caching-Modus deaktiviert, somit richtig eingestellt?! ....

Also was die Header angeht, da habe ich nichts geändert somit gehe ich davon aus das es nicht drin steht. In welcher Datei müsste ich denn danach suchen?

Hmm... "Traceroute" hört sich für mich mal wieder nach "Bahnhof" an. Ansonsten gibt´s nicht wirklich eine Möglichkeit dem Fehler auf die Spur zu kommen?! Drupal sollte ich somit ausschließen können oder gibt es evtl. noch irgendwo eine Einstellung bei der ich etwas falsch konfiguriert habe!?

Blöde Situation irgendwie!

Der Server von Webhostone, den sie für ihre eigene Seiten verwenden, ist so eingestellt, das Proxys und Browser die Daten nicht cachen dürfen. Wie das mit Kundenservern aussieht kann ich nicht sehen.

Ich habe von Webhostone folgende Haeder zum Thema caching bekommen:

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Liegt in der Vergangenheit.

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Kein Archivieren, Kein zwischenspeichern und jedes mal fragen ob sich was geändert hat

Pragma: no-cache

Auch ältere Software, die HTTP/1.1 nicht kennt, sondern nur HTTP/1.0 darf nichts zwischenspeichern.

Schau mal ob es bei dir so ähnlich aussieht:

• online auf http://web-sniffer.net, oder
• mit dem Firefox Add-on Live HTTP Headers, oder
• mit Wget: wget -S http://example.com/example.jpg. Bei jeder Linux-Distribution dabei, eine Windows-Version gibt's unter http://gnuwin32.sourceforge.net/packages/wget.htm

Damit kann man prüfen, über welche Zwischenstationen Netzwerkpakete gesendet werden. Eigenet sich aber nicht wirklich, um HTTP-Proxies zu finden.

--

Den aktuell verwendeten Header-Code kann man im HTML-Quellcode der Webseite begutachten.

Traceroute

Man sitzt an einem Rechner und der Browser holt eine URL ab. Die kommt auch von einem Rechner. Zwischen beiden Rechnern koenne viele verschiedene andere Rechner stehen. Die Verfolgung des Verwendeten Weges ueber alle Rechner nennt sich Traceroute/Tracerouting.
Im Web gibt es Dienste die kostenloses Tracerouting anbieten. Linux kann das selber. Fuer Win muss man sicherlich was installieren.

Ganz Allgemein hat man in Drupal neben der Performance- und Caching-Konfiguration in der Administration erst mal keine Moeglichkeiten was einzustellen oder falsch zu machen.

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Date: Fri, 07 Dec 2007 10:26:04 GMT CRLF
Server: Apache/1.3.33 (Debian GNU/Linux) FrontPage/5.0.2.2623 mod_ssl/2.8.10 OpenSSL/0.9.7 PHP/4.4.7 CRLF
Cache-Control: store, no-cache, must-revalidate CRLF
Expires: Sun, 19 Nov 1978 05:00:00 GMT CRLF
X-Powered-By: PHP/4.4.7 CRLF
CRLF
Last-Modified: Fri, 07 Dec 2007 10:26:04 GMT CRLF
Cache-Control: post-check=0, pre-check=0 CRLF
Connection: close CRLF
Transfer-Encoding: chunked CRLF

Header:
Content-Type: text/html; charset=utf-8

Soweit ich das beurteilen kann sollte alles in Ordnung sein!!
Was würdet ihr als nächsten Schritt vorschlagen? Denn an Drupal scheint´s dann ja aufkeinfall zu liegen!!

- erstmal abwarten und gucken wie sich das System verhält oder der Browsercache schon auszuschließen?
- Traceroute/Tracerouting in Angriff nehmen?

Aber was das Tracerouting angeht ist es doch komisch wenn es von unterschiedlichen Standorten auftritt, oder? Vielleicht ist es dann ein Rechner in der Nähe des Hoster!?

Nicht unbedingt.

Die vom Websniffer gemachte Aussage betrifft nur eine Website selbst/allgemein. Ein Proxy kann neben einer Konfig fuer HTML/Text Seiten fuer Bilder eine extra Konfig mit einer ertra Lifetime haben. Die wuerde man in der allgemeinen Headerinfo Content-Type: text/html; charset=utf-8 nicht sehen. Anders formuliert: Die Aussage ueber HTML ist keine ueber Bilder.

So bleibt also Dein Hoster immer noch im Kreis der Verdaechtigen.

Wenn man mich als Hoster fragen wuerde waere meine Antwort auch erst mal nach dem Motto "alles normal". Gerade bei Bildern macht eine lange Lifetime in der Proxykonfig am meisten Sinn - gesparte Bandbreiten sind am groessten. Diese Bandbreiten muessen nicht zwingend die nach draussen sein. Auch fehlende Bandbreiten im internen Netzwerk des Hoster koennen Grund fuer lange Lifetime von Bildern sein - und wer gibt schon zu das seine Infrastruktur zu schwachbruestig ist.

Aber um nicht zu sehr auf dem Proxy Thema rumzureiten und damit eventuell in die falsche Richtung zu rennen.

Betrifft das Caching Problem mit den Bildern nur den IE oder auch andere Browser wie FF oder Opera?

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Shit, aber ich glaube ich habe die Pferde einwenig scheu gemacht....

Erstmal beantworte ich mal die Frage bzgl. des Browsers: Ja, beim IE und beim FF tritt das Problem auf!

Oh man, es tut mir riesig leid das ich euch jetzt so in Anspruch genommen habe. Sitze gerade beim Mittagessen und dann kommt mir doch glatt die Idee den Cache vom IE und FF zu löschen :-((( (PEINLICH)

SORRY!!!

Es lag dann wohl am Browser!!! Denn direkt danach hat er mir die aktuellen Bilder angezeigt.... Aber die Frage ist immer noch, wie lange greift er auf diese Inhalte zurück und läd nicht neu. Denn so ganz habe ich mir die Sache nicht eingebildet! Teilweise war ich zwei Tage nach dem ich mein Bild geändert habe bei einem Kollegen am Rechner und dort war noch mein altes Bild zu sehen. Gibt es quasi eine Browser-Lifetime?

Nochmal vielen Dank für Eure Unterstützung! Und nochmals sorry!!!
Habe schon begonnen mich mit dem Befehl "tracert" unter Windows zu beschäftigen.....

Schon mal davon gehoert, das man um eine Seite im Browser zu reloaden beim Klick auf den Reload-Button gleichzeitig die Shift-Taste druecken kann?
Das hat das Laden einer Webseite mit Ignorierung des Browser-Cache zur Folge. Funktioniert bei fast allen Browsern. ;-)

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

:-) Ja ich habe davon gehört......
Aber es geht dabei ja nicht um mich sondern um die User die sich vielleicht wundern wenn sie Ihr Bild ändern und dann immer noch ihr altes Profilbild sehen. Ist doch auch komisch wenn ich jedem erklären muss was er zu tun hat um dem Problem aus dem Weg zu gehen.

Du kannst auch den Seitenbesuchern nicht erklaeren das sie den Browsercache leeren sollen. Manch wissen vermutlich nicht mal was das ist.

Apropos,
Du hast von Mittagspause gesprochen. Steht der gesuchte Proxy in der Firma in der Du Mittagspause machst? Oder habe ich Mittagessen falsch interpretiert?

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Ich denke nicht!!!

Aber die Proxy-Server-Suche wollte ich jetzt erstmal auf Eis legen und die nächsten Tage und das Userverhalten abwarten. Oder sollte ich noch weiter in der Browser-Wunde bohren? ....

Drupal speichert die Userbilder doch immer unter dem gleichen "Namen" des jeweiligen Users ab, kann man Drupal beibringen diesen zu ändern? Obwohl das würde beim Abgleich des Caches mit der Seite wohl nichts ändern....

Folgenden Code habe ich in meiner user_profile.tpl benutzt:

?php endif; ?
div class="img"
div id="imgprofile"
?php if($user->picture) {print theme('user_picture', $user);}?>