css-Datei nicht aus dem Cache nehmen

[Linuchs]

Moin,

wenn ich HTML-Seiten teste, funktioniert bei one.com der vollständige Neuaufbau mit [Strg][F5] nicht. Der Firefox bekommt nicht die neueste CSS-Datei, auch nicht dann, wenn ich sie in die Adressleiste eintrage und einzeln aufrufe. FF ist überzeugt, er müsste sie aus dem Cache nehmen.

Dass sie aber bei one.com per FTP angekommen ist, sehe ich durch Hochzählen des Parameters t in einem HTML-Dokument:

<link rel=stylesheet      href="css/basis.css?t=5">

Doch für jede Änderung der basis.css auch HTML-Dateien wegen einer höheren Nummer hochladen zu müssen, ist eine Behinderung der Arbeit.

Wie kann ich erreichen, dass während der Testphase die basis.css wenigstens bei [Strg][F5] neu geladen wird?

Fragt Linuchs

[Matthias Apsel]

Hallo Linuchs,

Wie kann ich erreichen, dass während der Testphase die basis.css wenigstens bei [Strg][F5] neu geladen wird?

Indem du nicht dein Produktivsystem(?) bei one.com zum Testen nimmst? Offenbar haben die globale Cache-Einstellungen, die du nicht verändern kannst.

Bis demnächst
Matthias

[Der Martin]

Hallo Matthias,

Wie kann ich erreichen, dass während der Testphase die basis.css wenigstens bei [Strg][F5] neu geladen wird?

Indem du nicht dein Produktivsystem(?) bei one.com zum Testen nimmst?

gegen die Empfehlung ist zwar nichts einzuwenden, aber @Linuchs: AFAIR ist der Tastatur-Shortcut für ein erzwungenes Neuladen nicht Ctrl-F5, sondern Shift-F5. Zumindest wende ich das für gewöhnlich so an ...

Fraglich ist, ob das erzwungene Neuladen auch auf Second-Level-Requests wie eingebundene Stylesheets und Bilder gilt. Ich hatte bisher den Eindruck, das sei so, aber ich will's jetzt nicht beschwören.

Ciao,
 Martin

[Rolf B]

Hallo Martin,

normalerweise lädt F5 das Dokument neu und Ctrl+F5 auch die referenzierten Ressourcen.

Frage ist, ob hier der Browser verantwortlich ist oder ein serverseitiger Cache bei one.com - ich meine nämlich, bei Spielereien auf meiner Ewigbaustelle ähnliches beobachtet zu haben. Keine Ahnung, ob man da mit .htaccess irgendwas tun kann.

Linuchs, lass die Seite mal mit offenen Entwicklerwerkzeugen laufen, da gibt's typischerweise eine Checkbox "Cache abschalten". Und man müsste auch sehen können, ob der Browser die Ressource nicht anfordert oder ob er vom Server ein "ist unverändert" bekommt.

Wenn Änderungen trotz Cacheabschaltung immer noch nicht greifen, empfehle ich für den Entwicklerbetrieb ein JavaScript, das den Anticache-Parameter automatisch durch den aktuellen Timestamp ersetzt. Ist lästig, ich gebe es zu…

Rolf

[Linuchs]

Hallo Rolf,

empfehle ich für den Entwicklerbetrieb ein JavaScript, das den Anticache-Parameter automatisch durch den aktuellen Timestamp ersetzt. Ist lästig, ich gebe es zu…

Danke für den Tipp, ich mache es mit PHP

<link rel=stylesheet href="/css/basis.css?t=<?=date("i",time())?>">

[Rolf B]

Hallo Linuchs,

achso, klar. War ja kein statisches HTML...

Musst dann nur drauf achten dass Du das nicht in der Produktion hast 😀

Rolf

[TS]

Hello,

Hallo Linuchs,

achso, klar. War ja kein statisches HTML...

Musst dann nur drauf achten dass Du das nicht in der Produktion hast 😀

Es würde der Timestamp genügen. Sekundengenau wird ja wohl reichen.

Und das Thema mit der Produktion könnte man mit einem Server-PHP-Parameter, den man im VirtHost festlegt:DEBUG lösen. Und derartige Dinge dann immer von if DEBUG mittels einheitlicher Funktion abhängig machen.

Glück Auf
Tom vom Berg

[Matthias Apsel]

Hallo TS,

Es würde der Timestamp genügen. Sekundengenau wird ja wohl reichen.

Es gibt Entwicklerumgebungen, da heißt die CSS-Ressource wie ihre Prüfsumme.

Bis demnächst
Matthias

[Mitleser]

Es gibt Entwicklerumgebungen, da heißt die CSS-Ressource wie ihre Prüfsumme.

Oder der Build-Prozess verwendet den Commit-Hash (aus wömöglich zig CSS-Dateien, die dann zu einer zusammengefasst werden) als Dateinamen.

[TS]

Hello,

im Stammdokument nur den URL-Parameter zu ändern und nicht den Dateinamen ist trotzdem schlauer, wenn es denn mit den eigentlich richtigen Cacheanweisungen nicht klappen will.

Der Name der CSS-Datei sollte sich nur ändern, wenn man das für eine History benötigt.

Glück Auf
Tom vom Berg

[Mitleser]

im Stammdokument nur den URL-Parameter zu ändern und nicht den Dateinamen ist trotzdem schlauer, wenn es denn mit den eigentlich richtigen Cacheanweisungen nicht klappen will.

Ob sich der "Dateiname" oder ein etwaiger Parameter ändert, ist bzgl. (clientseitigem) Caching wurscht. Es ist ein neuer Ressourcenaufruf, der bislang noch gar nicht im Cache liegen kann.

Der Name der CSS-Datei sollte sich nur ändern, wenn man das für eine History benötigt.

Der Name des eigentlichen CSS-Files kann sogar immer gleich bleiben, falls im Hintergrund dazu ein Rewrite hinterlegt ist.

[TS]

Hello,

im Stammdokument nur den URL-Parameter zu ändern und nicht den Dateinamen ist trotzdem schlauer, wenn es denn mit den eigentlich richtigen Cacheanweisungen nicht klappen will.

Ob sich der "Dateiname" oder ein etwaiger Parameter ändert, ist bzgl. (clientseitigem) Caching wurscht. Es ist ein neuer Ressourcenaufruf, der bislang noch gar nicht im Cache liegen kann.

Nee, eben nicht!

Aber ich habe jetzt keine Lust, das hier per Tablet ausführlich zu erläutern.

Nur soviel:
wenn kein Versionsverwaltungssystem betrieben wird, das die alten Dateien auf dem (Produktiv-)Server belässt, dann sollte sich der Dateiname der CSS-Datei nur bei grundlegenden Änderungen des Primärdokumentes mit ebensolchen gravierenden Änderungen der CSS-Dateiändern.

Glück Auf
Tom vom Berg

[Mitleser]

Nee, eben nicht!

Aber ich habe jetzt keine Lust, das hier per Tablet ausführlich zu erläutern.

Achso. Danke. Dann glaube ich Dir mal. Du hast bestimmt Recht.

[TS]

Hello,

Nee, eben nicht!

Aber ich habe jetzt keine Lust, das hier per Tablet ausführlich zu erläutern.

Achso. Danke. Dann glaube ich Dir mal. Du hast bestimmt Recht.

Danke für deinen humorvollen Hinweis.

Tut mir leid, wenn ich den Eindruck erweckt habe, dass ich gegenüber Linuchs keine Lust hätte zu antworten. Das hat aber mit meinem Tablet zu tun. Das spinnt seit einiger Zeit (nur im SelfForum!) bei längeren Antworten. Die kann ich dann oft nicht mehr abschicken und beim Versuch den Entwurf aus dem LocalStorage nutzbar zu machen, ist der dann auch meistens weg. Anschließend hängt die Verbindung zum Forum dann bis zu Minuten. Alle anderen Tabs zu anderen Domains funktionieren aber noch!

Ich habe noch nicht gefunden, woran das liegt.

Glück Auf
Tom vom Berg

[Der Martin]

Hallo Tom,

Tut mir leid, wenn ich den Eindruck erweckt habe, dass ich gegenüber Linuchs keine Lust hätte zu antworten. Das hat aber mit meinem Tablet zu tun. Das spinnt seit einiger Zeit (nur im SelfForum!) bei längeren Antworten. {...]

Ich habe noch nicht gefunden, woran das liegt.

was das SELF-Forum technisch von den meisten anderen Webseiten unterscheidet, ist Christians Websocket-Verbindung, die er wegen der vom Server aus getriggerten Aktualisierungen (Thread-Liste) permanent offen hält.

Eventuell liegt da der Hund begraben?

Ciao,
 Martin

[TS]

Hello,

Hallo Tom,

Tut mir leid, wenn ich den Eindruck erweckt habe, dass ich gegenüber Linuchs keine Lust hätte zu antworten. Das hat aber mit meinem Tablet zu tun. Das spinnt seit einiger Zeit (nur im SelfForum!) bei längeren Antworten. {...]

Ich habe noch nicht gefunden, woran das liegt.

was das SELF-Forum technisch von den meisten anderen Webseiten unterscheidet, ist Christians Websocket-Verbindung, die er wegen der vom Server aus getriggerten Aktualisierungen (Thread-Liste) permanent offen hält.

Eventuell liegt da der Hund begraben?

Nur mal eine ganz vorsichtige Vermutung:
Es könnte an einem Fehler im AJAX-Scripting/WebSocketProtocol liegen im Zusammenspiel mit einer empfindlichen Firewall aka fail2ban oder ähnlich.

Das hatte ich bei einem Kunden neulich auch. Da es zwei Abteilungen betraf, war sich keiner seiner "Schuld" bewusst. Und man hat es da ja mit ganz empfindlichen und hochsensiblen Leuten zu tun, die selber nie Fehler machen. Aber im Zusammenspiel... ;-)

Zum Glück hat der Kunde nach einem gaaanz vorsichtigen Hinweis von mir selber Leute für die Tiefenanalyse gehabt und die Fehlerkombination bald gefunden.

In diesem Fall hier kann aber durchaus noch das Browserupdate Verursacher sein.

Glück Auf
Tom vom Berg

[Linuchs]

Es würde der Timestamp genügen. Sekundengenau wird ja wohl reichen.

Ich weiß nicht, welchen Timestamp du meinst.

Das Anhängen von filemtime funktioniert prima:

<link rel=stylesheet href="/css/basis.css?t=<?=filemtime("css/basis.css")?>">

Die Anfrage-Zeit des filemtime sehe ich in der Konsole nicht, die Meldung „Not Modified“ benötigt um die 30ms

Das Anhängen von time liest die Datei immer neu:

<link rel=stylesheet      href="/css/basis.css?t=<?=time()?>">

Das dauert auch so um 35ms

Aus Zeitgründen scheint das Lesen einer (kleinen) Datei besser zu sein als vorheriges Ermitteln der letzten Änderung, um das Lesen zu sparen.

Linuchs

[JürgenB]

Hallo,

ich habe bei meiner Testdomain in der .htaccess durch Senden des Cache-Headers die Cache-Zeit auf 1 (Sekunde?) gesetzt.

Gruß
Jürgen

[pl]

Hallo,

ich habe bei meiner Testdomain in der .htaccess durch Senden des Cache-Headers die Cache-Zeit auf 1 (Sekunde?) gesetzt.

Bitte welcher Header?

MFG

[JürgenB]

Hallo,

ich habe bei meiner Testdomain in der .htaccess durch Senden des Cache-Headers die Cache-Zeit auf 1 (Sekunde?) gesetzt.

Bitte welcher Header?

den Cache-Control Header setze ich mit

Header set Cache-Control …

Gruß
Jürgen

[pl]

Hallo,

ich habe bei meiner Testdomain in der .htaccess durch Senden des Cache-Headers die Cache-Zeit auf 1 (Sekunde?) gesetzt.

Bitte welcher Header?

den Cache-Control Header setze ich mit

Header set Cache-Control …

Tipp: mod_expires setzt diesen Header automatisch.

MFG

[pl]

Mein Vorschlag in .htaccess:

ExpiresByType text/css A0

MFG

[Camping_RIDER]

Aloha ;)

wenn ich HTML-Seiten teste, funktioniert bei one.com der vollständige Neuaufbau mit [Strg][F5] nicht.

One.com verwendet eine eigene Cache-Lösung - das hat mir bei einer ähnlich lautenden Anfrage mal deren Support mitgeteilt.

Man kann ihn auch deaktivieren, und zwar durch folgende Zeilen in der .htaccess (im Beispiel was ich damals für einige bestimmte Dateiendungen gemacht habe, kann man aber natürlich auch für alle machen):

# disable one.com varnish cache
<FilesMatch "\.(htm|html|css|js|png|gif|jpg|svg)$"> 
	Header add "disablevcache" "true" 
</FilesMatch>

Bei sowas (d.h., wenn man schon sicher ist, dass das nur bei einem bestimmten Provider so ist) lohnt es sich übrigens immer, den Support anzuschreiben. Eine allgemeine Anfrage wie hier im Forum ist zu sowas fast immer völlig fruchtlos, weil niemand ahnen kann, was der Provider jetzt da konkret tut. Dass ich durch puren Zufall eben über das Posting gestolpert bin und durch puren Zufall beim selben Provider schon das selbe Problem hatte, ist nur purer Zufall - und auf den willst du dich ja hoffentlich nicht verlassen.

Mehr als wirkungslose Glaskugelleserei (siehe oben, ohne jemandem zunahe treten zu wollen) wirst du da normalerweise nicht kriegen.

Also sowas besser nicht irgendwo ins Forum kippen, sondern gleich beim Provider selbst anfragen.

Grüße,

RIDER