Trotz richtige gesetzter Header: Bilder werden gecached

Hallo zusammen,

ich habe mal ein Frage bezüglich des FF Version 2.0.0.13 und dem Caching von Bildern.

Wir betreiben eine Internetseite, bei der in verschiedenen Teilen die Bilder vom Browser nicht gecached werden sollen (z.B. beim Upload von Bildern ins eigene Profil, um sicher immer das neue Bild anzuzeigen).
Damit das funktioniert, liefern wir direkt über den Sourcecode folgende Header aus

Cache-Control: max-age=0, no-store, no-cache, private, must-revalidate
Expires: "0"

Darüberhinaus haben wir in unserem Apache2 in Zusammenhang mit "mod_headers" folgende Anweisungen für das Ausliefern von Bilder aus bestimmten Verzeichnissen gesetzt, um das Caching der Bilddateien direkt zu beeinflussen:

<Directory>
Header set Expires "0"
Header set Cache-Control "max-age=0, no-store, no-cache, private, must-revalidate"
Header unset ETag
FileETag None
</Directory>

Die Header werden auch genauso in der entsprechenden Seite ausgegeben und bei anderen Browsern werden die Bilder auch nicht gecached. Beim FF allerdings kommt es immer wieder vor, daß die Bilder trotzdem gecached ausgeliefert werden. Das Seltsame daran ist, daß das Verhalten nicht nachvollziehbar ist. Überwiegend werden die Bilder korrekt vom Server nachgeladen, aber bei ca. 10 Versuchen die Seite neu zu laden, ist einer dabei, bei dem die Bilder aus dem Cache kommen, obwohl sie gar nicht gespeichert werden dürften.

Ich würde Euch gerne einen Link geben, aber der entsprechende Sourcecode läuft momentan nur auf unserem Testsystem.

Mir wäre daran gelegen, eine Lösung zu bekommen, bei der auf alle Fälle sichergestellt ist, daß der FF auf den betroffenen Seiten die Bilder immer vom Server holt.

Hat hier jemand schon mal ähnliche Erfahrungen?

Viele Grüße

Udo

Hallo Börsenfeger,

vielen Dank für den Willkommensgruß!

Sofern es nur mich betreffen würde, dann würde ich Dir zustimmen. Das Problem was wir aber damit haben, ist, daß wir der Betreiber der Seite sind und Besucher unserer Seite unter Umständen nicht die aktuellste Version des FF einsetzen und wir es vermeiden möchten, irgendwo einen Satz a la "Falls Sie Firefox verwenden, kann es sein, daß ..." zu posten.

Es muß doch ne Möglichkeit geben, dem Firefox definitiv dazu zu bringen, Seiten und deren Inhalte nicht zu cachen, sondern immer die Seiten vom Server aktuell zu holen. Die Frage ist nur, welche Header brauche ich dazu bzw. wie bringe ich das dem FF bei. Bei den anderen Browsern funktionierts ja, zu meiner eigenen Überraschung sogar im IE

Ich denke, das Problem wurde hier bestimmt auch schon mal in einem anderen Thread diskutiert. Allerdings konnte ich trotz Suche dazu nix finden.

Mir würde ja auch ein Link reichen, der auf einen entsprechenden Thread verweist.

Gruß

Udo

Hallo Ulli,

habe ich schon gemacht. Die Header werden alle richtig ausgeliefert, genauso, wie wir sie eingestellt haben.

Hier mal ne Beispielausgabe des Headers der HTML-Seite, die ausgeliefert wird:

http://www..../benutzer/raptile/edit

GET /benutzer/raptile/edit HTTP/1.1
Host: www....
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.13) Gecko/20080316 SUSE/2.0.0.13-0.1 Firefox/2.0.0.13
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: HomepageTownUser="N�rnberg"; KeepLoginInfo=14241O-283560453; loginPresent=true; JSESSIONID=09B42D719EFFD85B3880521BFE8B871C; selectedHomepage="N�rnberg"
Cache-Control: max-age=0

HTTP/1.x 200 OK
Date: Mon, 26 May 2008 15:03:15 GMT
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: text/html;charset=UTF-8
Content-Language: de
Connection: close
Transfer-Encoding: chunked

Für die Bilder werden entsprechende Header generiert:

http://www..../photos/U14241-Raptile-1.jpg

GET /photos/U14241-Raptile-1.jpg HTTP/1.1
Host: www....
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.13) Gecko/20080316 SUSE/2.0.0.13-0.1 Firefox/2.0.0.13
Accept: image/png,*/*;q=0.5
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www..../benutzer/raptile/edit
Cookie: HomepageTownUser="N�rnberg"; KeepLoginInfo=14241O-283560453; loginPresent=true; JSESSIONID=09B42D719EFFD85B3880521BFE8B871C; selectedHomepage="N�rnberg"
Cache-Control: max-age=0

HTTP/1.x 200 OK
Date: Mon, 26 May 2008 15:03:15 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Mon, 26 May 2008 14:07:07 GMT
Accept-Ranges: bytes
Content-Length: 5018
Expires: Mon, 1 Jan 1970 00:00:00 GM
Cache-Control: no-store, no-cache, must-revalidate
Connection: close
Content-Type: image/jpeg

Nur der FF ist von Zeit zu Zeit der Meinung, daß es besser ist, Bilder aus dem Cache auszuliefern.
Mach ich danach über F5 einen Reload, werden die Bilder wieder korrekt vom Server geholt.

Gruß

Udo

Hallo Börsenfeger,

der von Dir gepostete Thread geht schon annähernd in die richtige Richtung. Vielleicht liegt das wirklich an der dort beschriebenen Einstellung.

Für uns wäre das insofern ungeschickt, weil wir dann keine Möglichkeit hätten, dem FF unserer Seitenbesucher explizit mitzuteilen, daß sich bei uns auf dem Server was geändert hat.

Wenn das wirklich das Problem ist, finde ich dieses "Feature" des FF doch etwas seltsam! Für was soll das gut sein, wenn der FF dadurch nicht mehr erkennt, daß sich auf Serverseite was geändert hat?

Ich hoffe, es gibt noch ne andere Lösung, als den User explizit aufzufordern, seinen Cache mit [STRG][F5] zu löschen.

Gruß

Udo

Hallo Börsenfeger,

na ja, daß war ja genau das, was ich vorhin meinte. Wenn das userabhängig ist, dann ist das für den Webseitenbetreiber schlecht, weil der dann Header senden kann, was er will und der FF des betroffenen Users bleibt trotzdem stur und liefert weiter aus dem Cache aus.

Für was ist das denn überhaupt gut, wenn ich als Webseitenbetreiber dem User nicht mitteilen kann, daß sich was auf meiner Seite geändert hat.

@Ulli: Wir testen gerade und lassen mal LiveHTTPHeaders mitschneiden. Ich poste dann mal das Ergebnis hier.

Gruß

Udo

... aber endlich ist der Fehler wieder aufgetreten!

Ich habe heute den ganzen Nachmittag getestet und lange Zeit hat es so ausgesehen, daß das Problem erledigt wäre. Aber dann ist der Fehler wieder aufgetreten.

Ich habe das Ganze wie folgt getestet:

Wenn User Ihr Profil bei uns editieren wollen, erhalten sie eine Form in der auch das jeweils, beim Account hinterlegte Bild angezeigt wird. Klicken die User auf das Bild, werden sie auf eine weitere Seite geleitet, in der ihr aktuelles Bild als Icon angezeigt wird und wo sie ein neues Bild hochladen und zuschneiden können.

Den Test selber habe ich nun mit zwei Bilder durchgeführt, die ich im Wechsel hochgeladen, zugeschnitten und abgespeichert habe.

Und vorhin trat der Fehler beim Wechsel von der Profilübersichtsseite auf die Upload-Seite wieder auf. Ich hatte zuvor ein neues Bild hochgeladen, welches mir nun auch in der Profilübersicht angezeigt wurde. Beim Wechsel auf die Upload-Seite wurde mir jedoch mein altes Bild als Icon angezeigt, daß so schon längst nicht mehr existiert hat.

Beim Überprüfen der Ausgabe von LiveHTTPHeaders habe ich dann festgestellt, daß das Icon beim fehlerhaften Aufruf vom Server gar nicht angefordert wurde. Hier mal die Ausgabe von LiveHTTPHeaders (um Platz zu sparen, nur die Header des Icons):

1.) Wechsel auf die Upload-Seite (Icon wurde erfolgreich vom Server geladen)

------------
Ausgabe des Seitenheaders der Uploadseite
------------

http://www.

GET /benutzer/<benutzername>/foto HTTP/1.1
Host: www.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.13) Gecko/20080316 SUSE/2.0.0.13-0.1 Firefox/2.0.0.13
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.
Cookie: HomepageTownUser="N�rnberg"; KeepLoginInfo=14241O-283560453; loginPresent=true; JSESSIONID=73508A2CC77CA1303DFFBF5F29AF2907; selectedHomepage="N�rnberg"

HTTP/1.x 200 OK
Date: Tue, 27 May 2008 13:49:21 GMT
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: text/html;charset=UTF-8
Content-Language: de
Connection: close
Transfer-Encoding: chunked

------------
Ausgabe des Headers des Icons
------------
http://www.

GET /photos/ico/U14241-Raptile-1.jpg HTTP/1.1
Host: www.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.13) Gecko/20080316 SUSE/2.0.0.13-0.1 Firefox/2.0.0.13
Accept: image/png,*/*;q=0.5
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.
Cookie: HomepageTownUser="N�rnberg"; KeepLoginInfo=14241O-283560453; loginPresent=true; JSESSIONID=73508A2CC77CA1303DFFBF5F29AF2907; selectedHomepage="N�rnberg"

HTTP/1.x 200 OK
Date: Tue, 27 May 2008 13:49:23 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 27 May 2008 13:48:14 GMT
Accept-Ranges: bytes
Content-Length: 1925
Expires: 0
Cache-Control: max-age=0, no-store, no-cache, private, must-revalidate
Connection: close
Content-Type: image/jpeg

2.) Wechsel nach dem Upload in die Profilübersicht

---------------
Ausgabe des Headers der Profilseite
---------------
Ausgabe der Seiten-Header:
http://www.

GET /benutzer/<benutzername>/edit HTTP/1.1
Host: www.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.13) Gecko/20080316 SUSE/2.0.0.13-0.1 Firefox/2.0.0.13
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.
Cookie: HomepageTownUser="N�rnberg"; KeepLoginInfo=14241O-283560453; loginPresent=true; JSESSIONID=73508A2CC77CA1303DFFBF5F29AF2907; selectedHomepage="N�rnberg"

HTTP/1.x 200 OK
Date: Tue, 27 May 2008 13:49:38 GMT
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache, max-age=0, no-store, no-cache, private, must-revalidate
Expires: Thu, 01 Jan 1970 00:00:00 GMT, Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: text/html;charset=UTF-8
Content-Language: de
Connection: close
Transfer-Encoding: chunked

3.) Wieder Wechsel zur Uploadseite

--------
Ausgabe der Seitenheader der Upload-Seite
--------

http://www.

GET /benutzer/<benutzername>/foto HTTP/1.1
Host: www.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.13) Gecko/20080316 SUSE/2.0.0.13-0.1 Firefox/2.0.0.13
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.
Cookie: HomepageTownUser="N�rnberg"; KeepLoginInfo=14241O-283560453; loginPresent=true; JSESSIONID=73508A2CC77CA1303DFFBF5F29AF2907; selectedHomepage="N�rnberg"

HTTP/1.x 200 OK
Date: Tue, 27 May 2008 13:49:41 GMT
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: text/html;charset=UTF-8
Content-Language: de
Connection: close
Transfer-Encoding: chunked

---------
Hier fehlt nun plötzlich der Headers des Icons
----------

Der Test lief genau so ab, wie hier mit den Punkten 1-3 geschildert. Upload eines neuen Bildes (korrekt) -> Wechsel zur Profilseite (korrekt) -> Wechsel zur Upload-Seite (Fehler!). Der Test wurde mit zuvor geleertem Cache durchgeführt.

Wenn Ihr wollt, kann ich Euch auch mal die vollständige Ausgabe von LiveHTTPHeaders zur Verfügung stellen, die für diesen Fall relevant sind. Nachdem das aber eine ziemlich große Textdatei ist, wollte ich die hier nicht posten.

Jetzt ist die Frage, warum wurde beim 2. Wechsel zur Upload-Seite das Icon nicht mal mehr vom Server angefragt bzw. wie krieg ich nun den FF dazu, daß Icon auch beim zweiten Durchgang korrekt anzufragen. Der Header fehlt hier komplett, weil hier anscheinend keine Anfrage durch den FF gestellt wurde, trotz "no-cache", "Expires" usw.

Gruß + Danke

Udo

Kein Problem ... Danke Dir für die Hilfe und die Tipps ...

Hallo Ulli,

na ja, wir haben seit Gestern so einige Konstellationen der Headers auspropiert. Aktuell sieht das Ganze so aus:

<Directory>
#Header set Expires "Thu, 01 Jan 1970 01:00:00 GMT"
Header set Cache-Control "no-store, no-cache"
Header unset ETag
FileETag None
</Directory>

wir hatten aber auch schon

<Directory>
Header set Expires "Thu, 01 Jan 1970 01:00:00 GMT"
Header set Cache-Control "no-store, no-cache, private, must-revalidate"
Header unset ETag
FileETag None
</Directory>

gesetzt und trotzdem gabs die Probleme.

Die E-Tags habe ich bewußt mal rausgenommen, damit er da nicht auf dumme Gedanken kommt.

Ich hatte aber auch schon nur die E-Tags gesetzt und explizit angegeben, daß sich das Tag nur aus "Inode" und "Modified Time" zusammen setzen soll. Da war das Cachingproblem allerdings noch schlimmer.

Mit der o.g. Methode kriegen wir es wenigstens hin, daß nur einer von ca. 10 Versuchen fehl schlägt.

Gruß

Udo

Ja, habe ich mir schon gedacht!

Nur eins noch ... ich hab Gestern auch mit about:cache die gecachten Sachen angeschaut. In diesem Zuge habe ich auch einige Bilder mal direkt mit dem FF aufgerufen und da ist mir was seltsames aufgefallen:

Key: http://<webseite>/photos/ico/U14241-Raptile-1.jpg
Data size: 13500 bytes
Fetch count: 1
Last modified: 2008-05-28 17:19:50
Expires: 1970-01-01 01:00:00

Key: http://<webseite>/photos/ico/U14241-Raptile-1.jpg
Data size: 986 bytes
Fetch count: 1
Last modified: 2008-05-28 17:19:50
Expires: 1970-01-01 01:00:00

Die Datei wird aber nur einmal vom Server gezogen. Das entspricht hier dem zweiten Eintrag mir 986 Bytes. Woher der erste kommt, konnte ich leider nicht feststellen.

Der Cache, den ich dazu aufgerufen habe, war der Memory-Cache.

Ist das ein Mechanismus vom FF um z.B. Speicherplatz für unbekannte Objekte zu allokieren? Und wenn ja, warum taucht der Eintrag im Cache auf ...?

Gruß

Udo

Ok, dann hat das damit nichts zu tun. Ich dachte, daß wäre ein möglicher Ansatzpunkt.

Dann bleibt das alte Problem bestehen. Gibts irgendwo ne ausführliche Beschreibung, wie der Cache des FF aufgebaut ist, bwz. wie er genau funktioniert?

Außer Angaben zu den "üblichen" Befehlen wie "about:cache" und die Beschreibungen für solche Einstellungen wie "cache_check_doc_frequency" usw. habe ich im Netz nichts gefunden, was uns noch weiter Hilfe bei dem Problem gibt.

Vielleicht liesse sich damit ein wenig Licht ins Dunkel bringen.

Gruß + Danke

Udo