Hallo BeRo, wieder einmal vielen herzlichen Dank für die bereichernde Hilfestellung. Ich dachte "pragma" wäre nur was für ältere Browser aus der Steinzeit und ich wusste auch nicht dass man die Metas alle nebeneinander packen darf. Wieder was gelernt.

Aber ich muss leider vermelden, dass es nicht funktioniert. Ich habe sogar mehrfach den Tab geschlossen und wieder aufgerufen. Hätte ja sein können, dass 1&1 halt ein bisschen braucht bis neue FTP-Daten abrufbar sind. Aber leider - auch nach 5 Minuten - half erst das Drücken auf F5 die neuen Daten anzuzeigen.

Hast du noch eine Idee was das sein könnte? Ich weiß mit Sicherheit, dass es vor ca. 1.5 Jahren mal funktioniert hat als ich es frisch eingebaut hatte. Aber ich habe es natürlich nicht ständig kontrolliert. Aktuell ist es nur durch Zufall aufgefallen, so dass ich hierzu keine erhellenden Angaben machen kann. (bis auf SSL, wie schon erwähnt).

Herzliche Grüße, Martina

[...] ich muss leider vermelden, dass es nicht funktioniert [...]

Hast Du daran gedacht, vor dem ersten Test den Cache zu leeren?

Wenn ja, dann musst Du wohl andere Methoden versuchen.

Leider sind Meta-Tags nicht besonders effektiv, weil sie nur von einigen Browser-Caches beachtet werden (das sind die, die den HTML-Code lesen), seltener von Proxy-Caches (die i. d. R. den HTML Code im Dokument nicht lesen). Auch ein Pragma: no-cache als Meta-Tag in eine Webseite eingefügt, erzwingt nicht automatisch das neu Laden.

Wenn Dein ISP (1&1) das Modul “mod_expires” im Apache aktiviert hat (beim Server Admin erfragen), kannst Du versuchen, mit einer entsprechend konfigurierten .htaccess Datei das Problem zu lösen.

Eine mit REDbot erstellte Analyse der Antwort des Webservers beim Aufruf Deiner Site, signalisiert zumindest die Möglichkeit der userdefinierten "lifetime" der Site (s. Screenshot).

Sollte das Modul “mod_expires” also aktiv sein, kannst Du hier  einen sehr gut gemachten Artikel lesen, in dem proog ausführlich (mit Beispielen) erklärt hat, wie das umgesetzt wird.

Mit ein bisschen Glück klappt Dein Vorhaben so.

Viel Erfolg

Hallo BeRo, vielen lieben Dank erneut.

Bei mir ergibt die Analyse mti Redbot eine andere Ausgabe. Leider kann ich nicht gut genug englisch um das wirklich zu verstehen (auch mit Übersetzungshilfe nicht). Das bekomme ich bei der entsprechenden "kränkelnden" Seite angezeigt:

Bezgl mod_expires muss ich tatsächlich fragen. Das konnte ich so nicht bei 1&1 finden. Apache-ja, mod_rewrite - ja. HTACCESS - kein Problem. Vorher habe ich aber noch eine Frage :

Hast Du daran gedacht, vor dem ersten Test den Cache zu leeren?

Öhm.... nein .

Wieso das? Meine Logik (*hahaha*)  Ich hatte die Seite als Tab in FF20 geöffnet. Sehe, das ich was ändern muss. Tab geschlossen.

Im WD geändert - hochgeladen - Seite aus den Favoriten erneut aufgerufen. Ein neuer Tab geht auf.

Ich dachte mit dem Code zu erreichen, wann immer ich die Seite aufrufe, sie eben nicht aus dem Browsercache geladen wird, sondern immer neu. Ob ich da dazwischen den FF mal schließe oder nicht (ist bei mir so eingestellt, dass dann immer der Cache gelöscht wird.)

Wo ist da der Denkfehler? Bin verwirrt  :)

Ergänzung: habe mich entwirrt und verstanden was du meinst . Es war natürlich "nur" die erste Meta-Angabe im Cache (die ja nicht funktioniert) aber noch nicht der neue Code. Sorry - das hat jetzt ein bisschen gedauert bei mir. Ich teste erneut mit bereinigtem Cache....

HG Martina

[...] Ich dachte mit dem Code zu erreichen, wann immer ich die Seite aufrufe, sie eben nicht aus dem Browsercache geladen wird [...]

Das wird auch funktionieren, wenn vor dem 1. Test der Cachespeicher leer ist. Andernfalls trittst Du in die Fußangel, die der FF ausgelegt hat, weil er eben (noch) nichts von Deinen Änderungen weiß, die Du per Meta Tag angelegt hast und er Dir folgerichtig zunächst die alten Inhalte anzeigt...

[...] Ob ich da dazwischen den FF mal schließe oder nicht (ist bei mir so eingestellt, dass dann immer der Cache gelöscht wird.)

Wo ist da der Denkfehler? [...]

Wenn der Browsercache standardmäßig beim Verlassen gelöscht wird, hast Du keinen Denkfehler drin.

[...] Das bekomme ich bei der entsprechenden "kränkelnden" Seite angezeigt: [...]

Ganz offensichtlich sind in der Antwort des Servers beim Seitenaufruf keine expliziten Infos zur Cache Behandlung enthalten.

Die Empfehlung: 'Cache-Control 'must-revalidate'' kannst Du aber benutzen, wenn Du die .htaccess Datei so anlegst wie als 2. Möglichkeit in diesem Artikel von proog erklärt.

Da Du nur gewinnen kannst, solltest Du es probieren...

Viel Erfolg

Hallo BeRo,

vielen herzlichen Dank für deine erneute Hilfe.

Ich weiß nun, dass

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

im Head leider auch nicht reicht. Auch nach bereinigtem Cache funktioniert das bei 1&1 leider nicht.

Also wird der Weg der sein, dass ich folgendes in der .htaccess ausprobieren muss:

<FilesMatch "\.(htm|html|php)$">
 FileETag None
 Header set Cache-Control "max-age=86400, public, must-revalidate"
 </FilesMatch>

Aber: leider ist das gar nicht so einfach zu machen, denn ich habe die Verschlüsselung der Seite per 1&1 gemacht. In der jetzigen .htaccess sind also lauter Passwörter drin - die ja auch recht regelmäßig geändert werden bzw ergänzt. Das bedeutet auch: die .htaccess wird von 1&1 regelmäßig überschrieben. Da rächt sich jetzt dieser eigentlich einfache, aber faule Weg diesen Passwortschutz über den Hoster zu machen.

Ich muss mir also einen anderen Weg einfallen lassen; und sei es dass ich diese eine Seite einfach in ein anderes Verzeichnis packe und dann eine eigene htaccess erstellen kann ohne das dies kollidiert. Ob das der sinnvollste Weg ist, muss ich nochmal in Ruhe überdenken (und die habe ich grade nicht so).

Auf jeden Fall habe ich durch deine Antworten wieder einen neuen und interessanten Einblick in die Materie bekommen. Und ich denke der Weg über ein eigenes Verzeichnis mit eigener htaccess funktioniert dann auf alle Fälle.  DANKE !

Gruß Martina