Firefox - mieses Cache Management

[hurga_gonzales]

Hi,

vielleicht kennt Ihr ein Workaround dazu.
Ich schreibe viele viele Internet Anwendungen und immer wieder gibt es Probleme mit Firefox. Denn dieser Browser hat ein absolut unbrauchbares Cache Management. Das heisst, ich habe eine Bildergalerie. Der Anwender im Backend darf diese bearbeiten und ändert beispielsweise von normaler DIV Ansicht auf Float left mit fester Breite. Dabei schreibt die Anwendung eine CSS Datei mit den Styledefinitionen.
Lade ich nun per Link die Vorschau der Galerie, zeigt mir FF immer noch die "alte" Darstellung, das heisst, er nimmt die alte CSS Datei aus seinem Cache, den man praktisch nicht steuern kann.

Gibt es dazu vielleicht ein Workaround, dass praktisch ist? Leider lässt der FF auch ein no-cache nicht zu.

Ehrlich gesagt, würde ich diesen untauglichen Browser links liegen lassen, aber er ist mittlerweile weit verbreitet und darum wäre es toll, wenn es dazu eine Lösung gäbe.

So muss der User die neue Seite immer erst komplett neu laden oder seinen Cache manuell löschen. Danach geht es natürlich.

Übrigens: Im IE funktioniert das einwandfrei.

Opera und Safari sind da gleich unbrauchbar.

Nicht zum erstenmal zeigen die Entwickler von FF ein sehr unprogessionelles Produkt, das zwar zum Browsen für DAUs geeignet ist, aber nicht weiter. Anwender von CMS Systemen haben immer Probleme mit dem Ding. Wenn auch der HTML Parser sehr gut ist, so ist die Anwendung an sich ein totaler Witz. Da denkt der IE und viele andere Browser wesentlich weiter. Denn der Browser ist nicht nur zum Browsen da, sondern ist auch ein Client für Anwendungen. Der FF macht in dieser Hinsicht so gut wie alles falsch. Ein wahrer Alptraum für Webentwickler.

Die Frage ist kurz:
Wie bringe ich FF, Opera oder auch Safari dazu, die CSS Datei immer neu zu laden?

 

[Hancock]

Was hast du bisher ausprobiert?
Auch mal im Header z.B. "Expires: xxx" gesetzt?
Sonst wie wäre es mit einem zufälligen Parameter im Link zur CSS Datei, dann würde Firefox immer neu laden müssen, weil es eine andere Datei ist/zu sein scheint.

 

[hurga_gonzales]

Danke für die Antwort.

Wie gesagt, kann man dem FF gar nichts sagen. Ich habe keine Ahnung, warum, aber die Entwickler meinen wohl, der Programmierer darf dem User gar nix sagen. Dass ein Browser eventuell auch als Anwendungsclient dienen soll, ist den Pfuschern total entgangen.

<meta http-equiv="expires" content="0">
<meta http-equiv="cache-control" content="no-cache">

Keine Änderung mit dieser Anweisung.

 

[agraaaaa]

Sonst wie wäre es mit einem zufälligen Parameter im Link zur CSS Datei, dann würde Firefox immer neu laden müssen, weil es eine andere Datei ist/zu sein scheint.

An die Lösung dachte ich auch direkt, nur brauch es nicht unbedingt was zufälliges zu sein, sondern kann ja auch ein normaler UNIX Timestamp sein. Gibt einige Webseiten, frag mich grad nicht welche, die genau diese Methode nutzen. :-)

 

[Amischos]

Haste mal geguckt ob das in der neusten Firefox 4 beta auch noch so ist ?

 

[hurga_gonzales]

Ich lade nun mit einem ufälligen Wert am ENDE der URL, aber keine Änderung.

Kurze Beschreibung:
- ich bearbeite die Galerie, setze diese von float:left auf ganze Breite, speicher und die CSS Datei wird (habe ich natürlich überprüft) neu geschrieben
- klicke ich auf "Vorschau", wird per JS location.href die Vorschauseite aufgerufen

Die Vorschau ist eine Webseite, wo oben die Liste aller Galerien angezeigt wird und unten ein iFrame ist, in dem die eigentliche Vorschau angezeigt wird. Leider laden FF, Safari und Opera immer die alte CSS Datei. Ich muss also zuerst den Inhalt im iFrame neu laden, dann wird die richtige CSS Datei nachgeladen und die Anzeige stimmt. Fortan kann ich innerhalb der selben Galerie Änderungen machen und bei Vorschau wird die richtige CSS Datei geladen.

Wechsle ich aber die Galerie, klicke also auf eine andere in der Liste, gehe auf EDIT, speichere ab, zeigt er mir von der wieder die alte Version, bis ich den iFrame refreshe und der Browser die aktualisierte CSS Datei nachlädt.

Voll komisch.

 

[darkarchon]

Naja. Javascript verbunden mit iframes... was erwartest du? Dass bei javascript-seitigem Wechsel der Seite nicht der ganze Cache neugeladen wird ist nur logisch. Ausser du forcierst das irgendwie. Ich wuerde ja sagen: Nicht Firefox - mieses Cachemanagement, sondern Developer - mieser Programmierstil.

 

[DjNDB]

Woher soll firefox wissen, dass sich die CSS datei geändert hat?
Die normale Vorgehensweise aus Anwendersicht ist die Seite unter Umgehung des Caches neu zuladen. Das geht z.B. mit STRG-SHIFT-R.

 

[Hancock]

Die CSS Datei braucht den zufälligen Wert, genauso wie die Vorschauseite (im iFrame).
Mit "Expires" hab ich eher an PHP und header("Expires","1970-1-1 00:00 GMT") gedacht...
Also über good-old HTTP, weil ein CSS ist ja kein HTML. Ich glaub daher auch nicht, dass ein meta-Tag überhaupt gültig ist.

EDIT: Was wäre eigentlich mit einfach einem CSS wo alles drin ist, die Styles aber über Klassen eingestellt werden.

 

[ice-breaker]

Vor dem Problem stand ich auch schon desöfteren, scheinbar ignoriert der FF auch manchmal die HTTP-Header fürs Cache Control (Etag, No-Cache, Expires 1970), die einzige Lösung, die ich gefunden habe, und in jedem Browser und mit jedem Proxy perfekt funktioniert ist folgende:
Hänge an deine Dateinamen eine Revision oder das Datum an.

Aus logo.png wird somit logo09012010.png, funktioniert garantiert, oder eben logo_rev2.png.

 

[hurga_gonzales]

äh, hallo?
location.href lädt die Seite neu. Ist im Grunde nichts anderes als ein normaler href.
Ich ändere den Inhalt des iFrames NICHT per JS!

Da wär mir das schon klar.

Ja, ice-breaker, das habe ich gemacht. Leider funktioniert das auch nicht. Irgendwie behält er sich den Inhalt des iFrames von seiner ersten Ansicht. erst ein iFrame neu Laden bringt dann die Besserung.

Blitzmerker
Eine CSS Datei geht nicht, da es sich hierbei um die Verwaltung von Bildergalerien handelt. Logischerweise bekommt jeder Galerie, die von diversen berechtigten Usern angelegt werden feinsäuberlich ihre eigene CSS Datei. Der Dateiname ist immer gallery-[id-der-galerie].css.

Ich werds vielleicht ohne iFrame machen, dann muss es ja funktionieren. Dass es beim IE funktioniert ist ja klar. Der iFrame ist im Grunde ja eine MS Erfindung (für Webanwendungen aber durchaus eine sehr gute, wie ich finde, ansonsten benutze ich sowas nie).

 

[Hancock]

Ist der href immer der gleiche (für das iframe). Für das iframe müsste es irgendwie so sein
date=new Date();
frame.location.href="./iframe.php?date="+date.getTime();

 

[Fleshgrinder]

In CSS gibt es keine META-Tags. Auch besitzen die Browser alle ein Top Cache-Management (egal ob FF, Opera, Safari, …). Das Problem sind die Programmierer, da sie nicht wissen wie sie die Caches ansprechen können. Es gibt verschiedene Möglichkeiten zu steuern wie die Webbrowser Dateien cachen oder eben nicht.

Sehr einfach aber sehr ineffizient sind Querys. Beispiel:

<link rel="stylesheet" type="text/css" href="/css/style.css?123456789" />

Durch Veränderung des Querys sollte der Webbrowser die Datei neu herunterladen. Wie gesagt, diese Methode ist ineffizient und sollte nicht verwendet werden. Besonders in Zusammenarbeit mit Proxys (wie sie teilweise auch von ISPs eingesetzt werden für ihre Kunden) führt dies oft zu Caching Problemen.

Die beste Methode ist es, den Dateinamen direkt zu verändern. Beispiel:

<link rel="stylesheet" type="text/css" href="/css/style-123456789.css" />

Wird nun der Wert verändert muss jeder Browser die Datei neu herunterladen, da in keinem Cache eine entsprechende Datei vorhanden ist.

„Wie kontrolliere ich den Cache von statischen Dateien?“

Dies ist erstmal abhängig vom verwendeten Server, jeder Server wird anders konfiguriert. Ich nehme hier einmal Apache als Beispiel her, da Apache am weitesten verbreitet ist und bei billigerem Hosting aufgrund der .htaccess sehr beliebt ist.

Es gibt verschiedene HTTP-Header mit denen sich das Caching steuern lässt, da wären:

• Expires Header
• Cache-Control Header
• ETags (Entity Header)

Expires Header bieten sich an für statische Dateien, Cache-Control für dynamische und ETags bei Konfigurationen mit einem einzigen Server der immer antwortet.

Ein Konfigurationsbeispiel wodurch Dateien extrem gecached werden von allen Webbrowsern:

## Send appropriate Expires headers.
<IfModule mod_expires.c>
  # Turn on Expires headers.
  ExpiresActive On

  # Set default Expires header to 2 weeks.
  ExpiresDefault A1209600

  # Set up caching on media files for 2 month.
  <FilesMatch "\.(css|flv|gif|ico|jpg|jpeg|js|mov|mp3|pdf|png|ppt|swf|txt|wmv|xml)$">
    ExpiresDefault A4838400
  </FilesMatch>

  # Do not cache our sitemap.xml for 2 months!
  <FilesMatch "sitemap\.xml$">
    ExpiresDefault A0
  </FilesMatch>

  # Force no caching for dynamic files.
  <FilesMatch "\.(php|cgi|pl|htm|htm\.gz|html|html\.gz)$">
    # Do not allow PHP scripts to be cached unless they explicitly send cache
    # headers themselves. Otherwise all scripts would have to overwrite the
    # headers set by mod_expires if they want another caching behavior.
    ExpiresDefault A0
  </FilesMatch>
</IfModule>

## Send appropriate HTTP headers.
<IfModule mod_headers.c>
  # Vary Accept-Encoding
  Header set Vary Accept-Encoding

  # Set up caching on media files for 2 month.
  <FilesMatch "\.(css|flv|gif|ico|jpg|jpeg|js|mov|mp3|pdf|png|ppt|swf|txt|wmv|xml)$">
    Header append Cache-Control "public"
  </FilesMatch>

  # Do not cache our sitemap.xml for 2 months!
  <FilesMatch "sitemap\.xml$">
    Header set Cache-Control "no-store, no-cache, must-revalidate, max-age=0"
    Header set Pragma "no-cache"
  </FilesMatch>

  # Force no caching for dynamic files.
  <FilesMatch "\.(php|cgi|pl|htm|htm\.gz|html|html\.gz)$">
    # Do not allow PHP scripts to be cached unless they explicitly send cache
    # headers themselves. Otherwise all scripts would have to overwrite the
    # headers set by mod_expires if they want another caching behavior.
    Header set Cache-Control "no-store, no-cache, must-revalidate, max-age=0"
    Header set Pragma "no-cache"
  </FilesMatch>
</IfModule>

## The HTTP-Header is big enough, delete ETags.
FileETag None

Was was macht kann den Kommentaren entnommen werden.

Ich empfehle dir dringend die Dateinamen der CSS-Dateien zu verändern oder einfach verschiedene CSS-IDs (oder CSS-Klassen) im HTML zu verwenden. Also anstatt das CSS zu ändern, einfach das HTML ändern. Statische Dateien sollten extrem lange im Cache bleiben und dynamische nicht, entsprechend ist es logischer eine CSS-Datei mit beiden Deklarationen anzubieten und das HTML zu ändern.

 

[hurga_gonzales]

Nene, ich lade die ganze Seite neu und im "src" des iFrame wird dann halt per Variable das Ziel eingesetzt. Der Wert ist immer ein anderer und ich habe sogar schon einen UUID an den Wert angehängt, damit er auch wirklich immer unterschiedlich ist.

Ergänzung (1. September 2010)

Das hier, war die Lösung:

Sehr einfach aber sehr ineffizient sind Querys. Beispiel:
<link rel="stylesheet" type="text/css" href="/css/style.css?123456789" />

Wir gesagt, ich muss hier nicht auf die Effizienz der Seite achten, denn es handelt sich um das Backend und ich möchte nur sehr einfach eine Vorschau anbieten. Logistisch gesehen, ist dies der einfache und im Gesamtbild der "effizienteste" Weg.

Auf der Webseite selbst wirkt sich dieses Problem nicht aus und da verwende ich ohnehin keine CSS Queries.

Danke für Eure Zeit und den rettenden Tipp.

 

[Fleshgrinder]

Wenn es funktioniert ist es die richtige Lösung. Querys zu verwenden ist nicht böse, schlecht oder sonst was, wenn es um Langzeitcaching geht nur ineffizient. Wird dies gar nicht erwünscht sind sie absolut valide.