Safari auf Mac kann kein HTML mehr?

[Helmut]

Hallo,

da gibt es eine ganz normale Anzeigeseite mit HTTP, also ohne "s". Die zeigt eine Tabelle an und eine Select-Box.

Und es existiert ein Link auf eine HTTPS-Ressource in der Seite. Die Seite ist laut validator/nu voll in Ordnung, keine Fehler.

Alle Leute können die Seite auf ihren Gräten anzeigen, nur der Freund mit dem MacOS und Safari bekommt nur die Anzeige der Seite, ohne dass die Selectbox neu geladen, wird. Die Seute ist wie eingefroren.

Es kommt immer wieder die Seite, die er beim allerersten Mal aufrufen konnte. Die Selectbox müsste inzwischen schon mehr als 10 Einträge anzeigen. Da kommen aber immer nur die drei initialen.

Was kann das sein?

Einen Link auf die Seite darf ich leider nicht posten, da es nicht mein Projekt ist.

LG Helmut

[Nico R.]

Hallo Helmut,

... ohne dass die Selectbox neu geladen, wird. Die Seute ist wie eingefroren.

Wird das select über eine JS-Datei befüllt? Dann könnte es eventuell daran liegen, dass Safari noch auf eine alte Version der Datei aus dem Cache zugreift. Safari bietet keinen wirklichen Hard Refresh. Daran bin ich selbst mehrmals verzweifelt, als ich mal auf einem Mac arbeiten musste. Am besten an den JS-Dateinamen einen Timestamp o.ä. anhängen und neu einbinden.

Schöne Grüße Nico

[Helmut]

Hallo Nico,

... ohne dass die Selectbox neu geladen, wird. Die Seute ist wie eingefroren.

Wird das select über eine JS-Datei befüllt? Dann könnte es eventuell daran liegen, dass Safari noch auf eine alte Version der Datei aus dem Cache zugreift. Safari bietet keinen wirklichen Hard Refresh. Daran bin ich selbst mehrmals verzweifelt, als ich mal auf einem Mac arbeiten musste. Am besten an den JS-Dateinamen einen Timestamp o.ä. anhängen und neu einbinden.

JS ist hier nicht im Spiel.
Die Seite wird durch ein PHP-Skript generiert. Die URL bleibt immer gleich, aber der Inhalt ändert sich.

Nach deinem Posting hat der Programmirer unterschiedliche Header eingebaut:

header("Cache-Control: no-store, no-cache, must-revalidate");

hat nichts gebracht.

und dann ergänzt:

header("Cache-Control: no-store, no-cache, must-revalidate");
header('Expires: 0');
header('Last-Modified: ' . gmdate('D, d M Y H:i:s T'));

hilft auch nicht.

Was da auf dem MAC vergurkt ist, verstehe ich nicht. Denn auf allen anderen Geräten funktioniert es, auch im Safari.

Grüße
Helmut

[Rolf B]

Hallo Helmut,

ich kann der Beschreibung des Ablaufs nicht wirklich folgen. Du setzt zuviel als bekannt voraus.

Alle Leute können die Seite auf ihren Gräten anzeigen, nur der Freund mit dem MacOS und Safari bekommt nur die Anzeige der Seite, ohne dass die Selectbox neu geladen, wird. Die Seute ist wie eingefroren.

Wieso sollte die Selectbox neu geladen werden? Welche Bedienschritte finden statt, was wird an welcher Stelle erwartet, was passiert wirklich? Das ist komplett unklar. Wir kennen eure Webseite schließlich überhaupt nicht.

Aber bevor Du Dich damit bemühst, hätte ich noch eine Hypothese: Da ihr keine clientseitige Logik habt, würde ich auf dem Netzwerk-Tab der Entwicklerwerkzeuge kontrollieren, ob es auf dem Mac Probleme mit dem Session-Cookie gibt. Nimmt der Browser ihn an, sendet er ihn wieder mit, wird ggf. bei jedem Seitenabruf ein neuer Cookie erzeugt, so dass die Session verloren geht?

Rolf

[Auge]

Hallo

da gibt es eine ganz normale Anzeigeseite mit HTTP, also ohne "s".

Und es existiert ein Link auf eine HTTPS-Ressource in der Seite.

Ist das ein „normaler Link“, also ein Element a dessen Wert in href mit dem Protokoll „https“ beginnt, oder betrifft es ein Element link im head des Dokuments?

Tschö, Auge

[Helmut]

Hallo,

da gibt es eine ganz normale Anzeigeseite mit HTTP, also ohne "s".

Und es existiert ein Link auf eine HTTPS-Ressource in der Seite.

Ist das ein „normaler Link“, also ein Element a dessen Wert in href mit dem Protokoll „https“ beginnt, oder betrifft es ein Element link im head des Dokuments?

Die Seite wird ganz normal über eine URL aufgerufen: http://example.de/anzeige.php

In der Seite befindet sich noch ein https://-Link <a href="...">Info</a>.

In der Select-Box werden von PHP alle verfügbaren Dateien eines Verzeichnisses angezeigt, die einem Muster entsprechen.

Auf dem MAC mit Safari wird aber die Seite gar nicht neu geladen, sondern immer nur die erste Version angezeigt, die er jemals aufgerufen hat. Damals standen die Expire-Header natürlich noch nicht drin.

Und das irre ist, dass in der Selectbox auch nichts ausgewählt werden kann und deshalb auch die action nicht ausgeführt wird.

Das ist das, was mich so verwundert.

Grüße
Helmut

[Tabellenkalk]

Hallo,

Auf dem MAC mit Safari wird aber die Seite gar nicht neu geladen, sondern immer nur die erste Version angezeigt, die er jemals aufgerufen hat. Damals standen die Expire-Header natürlich noch nicht drin.

Ist das ein Tester, der mal eine statische, lokale Testversion bekommen hat, die er jetzt immer wueder aus seinem Dateisystem aufruft?

Gruß
Kalk

[Rolf B]

Hallo Tabellenkalk,

oder kennt Safari sowas wie "Offline-Version speichern"?

Klingt jedenfalls sehr merkwürdig und wie ein Bedienfehler.

Rolf

[Helmut]

Hallo Rolf, hallo Tabellenkalk,

oder kennt Safari sowas wie "Offline-Version speichern"?

Klingt jedenfalls sehr merkwürdig und wie ein Bedienfehler.

Es könnte durchaus ein Einstellungsfehler sein. Bei IE konnte man doch auch an der Cache-Strategie von Seiten rumfummeln. Ich erinnere mich aber nicht mehr genau.

Es ist der Arbeitsplatz von unserem Chef und der lässt uns da nur sehr widerwillig in die Eistellungen schauen, beschwert sich dann aber dass "es noch nicht läuft".

Der arme Programmierer (Freelancer) ist auch schon ganz genervt. Jetzt ist der Chef erstmal verreist. Es geht also erst nächste Woche weiter.

Grüße Helmut

[Nico R.]

Hallo Helmut,

Die Seite wird ganz normal über eine URL aufgerufen: http://example.de/anzeige.php

In der Seite befindet sich noch ein https://-Link <a href="...">Info</a>.

Ich weiß noch nicht, wieso du diesen Link immer explizit erwähnst. Der ist ja erstmal einfach nur da, oder? Hat also mit dem Problem nichts zu tun.

Das Einfachste wäre es meines Erachtens, den Dateinamen zu ändern und das Script z.B. über http://example.de/anzeige_neu.php aufzurufen. Damit könnte man zumindest ein Cache-Problem ausschließen.

Schöne Grüße

Nico

[Helmut]

Hallo Nico,

Die Seite wird ganz normal über eine URL aufgerufen: http://example.de/anzeige.php

In der Seite befindet sich noch ein https://-Link <a href="...">Info</a>.

Ich weiß noch nicht, wieso du diesen Link immer explizit erwähnst. Der ist ja erstmal einfach nur da, oder? Hat also mit dem Problem nichts zu tun.

Das weiß ich eben nicht.

Normalerweise sollten die Restriktionen anders herum sein. Keine HTTP-Ressourcen in einer HTTPS-Seite. Aber wer weiß schon, was im Safari so vorgeht?

Das Einfachste wäre es meines Erachtens, den Dateinamen zu ändern und das Script z.B. über http://example.de/anzeige_neu.php aufzurufen. Damit könnte man zumindest ein Cache-Problem ausschließen.

Das wäre eine Lösung, die im "Machtbereich" des Programmierers liegt. Allerdings hat das Anhängen eines Parameters an die URL auch nichts genützt.

Probieren wir aber glatt nochmal aus, wenn unser lieber Dieter wieder da ist.

Grüße
Helmut

[Rolf B]

Hallo Helmut,

Ein Link ist in dem Sinne keine Ressource. Ressourcen sind Bilder, Stylesheets oder Skripte.

Rolf

[Helmut]

Hallo Rolf,

Ein Link ist in dem Sinne keine Ressource. Ressourcen sind Bilder, Stylesheets oder Skripte.

Ich war mir da beim Safari auf einem MAC Desktop nicht mehr sicher.
Du hast vermutlich Recht, dass der Link keinen Einfluss haben dürfte und der Fehler demnach eher in den Systemeinstellungen des MAC oder Safari liegen muss.

Auf den mobilen MAC-Systemen mit den Safari funktioniert es schließlich auch.

Ich bin gespannt auf die Lösung. Die sollten wir hoffentlich nächste Woche finden. Ich öle schon mal meine Engelszungen, damit ich tiefer in die Einstellungen gucken darf. Unser Chef ist da etwas paranoid ...

Grüße Helmut

[Nico R.]

Hallo nochmal,

Das Einfachste wäre es meines Erachtens, den Dateinamen zu ändern und das Script z.B. über http://example.de/anzeige_neu.php aufzurufen. Damit könnte man zumindest ein Cache-Problem ausschließen.

Das wäre eine Lösung, die im "Machtbereich" des Programmierers liegt. Allerdings hat das Anhängen eines Parameters an die URL auch nichts genützt.

Sofern es sich um ein Cache-Problem handelt, wird ja nach wie vor das alte Script aufgerufen, das von dem Querystring gar nichts weiß und ihn daher einfach ignoriert.

Gib gerne mal Bescheid, was ihr herausgefunden habt.

Schöne Grüße

Nico

[Rolf B]

Hallo Nico R.,

Der Querystring ist Teil der URL und sollte einen gecacheten Eintrag umgehen.

Rolf

[Helmut]

Hallo,

hier wie versprochen das Ergebnis nach ca. zwei Wochen Pause:

Mit den Headern im PHP-Skript und einer Woche Benutzungspause hat der Safari die Seite nun tatsächlich endlich neu geladen und damit wurde auch neue Options für die Selectbox geladen.

Seitdem also nun auch die neuen Header im Safari angekommen sind, scheint auch das Updaten der Seite, also neue Options, alle paar Minuten zu funktionieren.

Woran es aber nun wirklich gelegen hat, weiß ich immer noch nicht. Da es ja nun "funktioniert", besteht für unseren Dieter auch kein Anlass mehr, mich mal etwas tiefer in sein System reinschauen zu lassen.

Kann natürlich auch daran liegen, dass der Rechner sonst durchläuft und für den Urlaub mal runtergefahren wurde. Vielleicht hat Safari da beim Neustart auch den Cache verworfen.

Erkenntnis:

Für mich sagt das aber, dass ich in unsere Lastehefte für derartige Webseiten auf jeden Fall Cache-Pragma (Header-Statements) verlangen muss, damit sich nicht erst eine Dokumenten-Dauerversion auf irgendwelchen Browsern festbeißt.

Danke für Mitüberlegen
Helmut

[Raketenwilli]

Hm. Und DAS hat nicht funktioniert?

https://www.heise.de/tipps-tricks/Safari-Cache-leeren-so-geht-s-4192874.html

(Freilich kann man das den Benutzern der Webseite nicht zumuten...)

[Der Martin]

Hhallo,

Hm. Und DAS hat nicht funktioniert?

https://www.heise.de/tipps-tricks/Safari-Cache-leeren-so-geht-s-4192874.html

vermutlich weil's niemand probiert hat.

(Freilich kann man das den Benutzern der Webseite nicht zumuten...)

Ja. Und außerdem erwarte ich, dass beim Schließen des Browsers der Cache sowieso gelöscht wird.
Meine Browser sind jedenfalls so eingestellt, dass sie das tun. Aber ich gehe auch nicht auf Safari.

Einen schönen Tag noch
 Martin

[Helmut]

Hallo Martin,

vermutlich weil's niemand probiert hat.

Nehme ich auch an, obwohl Cheffe behauptet hat, er hätte das schon getan. Ich war aber nicht dabei.

Ja. Und außerdem erwarte ich, dass beim Schließen des Browsers der Cache sowieso gelöscht wird.
Meine Browser sind jedenfalls so eingestellt, dass sie das tun. Aber ich gehe auch nicht auf Safari.

Das muss für mich aber irrelevant bleiben, weil ich für Kundenlösungen vom Worst Case ausgehen muss. Und die benutzen ihre Geräte meistens im "out-of-the-box"-Zustand oder schlimmer: total verkurbelt. Und da muss es dann auch funktionieren. Deshalb enthalten die Anzeigeseiten auch kein AJAX oder Vanilla, oder zumindest ein sicheres Fallback auf Plain HTML.

Hier hat mir unser eigener Chef nun gezeigt, dass es solche Nutzungsbedingungen geben kann. Und das war nicht gestellt. Ich hätte nur gerne mal hinter die Kulissen geschaut, was da denn die Standardeinstellungen des Safari auf einem MAC sind.

Grüße Helmut

[Raketenwilli]

[Browsercache löschen]

vermutlich weil's niemand probiert hat.

Nehme ich auch an, obwohl Cheffe behauptet hat, er hätte das schon getan. Ich war aber nicht dabei.

Nun ja. Es gibt in manchen privaten Netzen auch cachende Proxys, die auch via HTTPS gelieferte Daten entschlüsseln und (dafür braucht es dann eine eigene Infrastruktur für Zertifikate) wieder verschlüsseln und Richtung Client senden.

Möglicherweise hat Dein Chef so was oder er hat es behauptet, um Dir klar zu machen, dass im Netz vieles [un]möglich ist.

Ich regle das (via PHP) so, dass bei einem „404er“ folgendes stattfindet:

header( 'Cache-Control: no-cache, no-store, must-revalidate' );
header( 'Pragma: no-cache' );
header( 'Expires: 0' );
header( 'X-Robots-Tag: noindex');

um - im Rahmen der Möglichkeiten des Senders - wirklich jedes Cachen (und das Speichern durch Suchmaschinen) auszuschließen. Auch wenn es manchem übertrieben erscheinen mag.

unsere Lastenhefte

Hihi. Aber klar: Wenn die Programmierer nichts oder nur wenig über das Projekt an sich wissen sondern nur stur Teilbereiche runterschreiben, dann fehlt denen jede Information über das Ziel und ergo was zu tun sei. Das muss dann halt jemand höchst kleinlich vorgeben…

…Ich wieder wöllte so nicht arbeiten müssen.

was da denn die Standardeinstellungen des Safari auf einem MAC sind.

Die Standardannahme über die Standardeinstellung von Browsern ist, sich so zu verhalten, wie die HTTP-Header es vorgeben. Was sonst? Aber wie schon geschrieben ist der Browser nicht der einzige zu beachtende Punkt. Es kann nämlich über das oben genannte hinaus auch noch sein, dass der Hoster einen Proxy (a.k.a. "Reverse-Proxy") betreibt, der z.B. überhaupt erst verschlüsselt…

Du schreibst ja: „shared hosting“. Da ist für Dich vieles transparent, mithin unsichtbar.

[Rolf B]

Hallo Raketenwilli,

Es kann nämlich über das oben genannte hinaus auch noch sein, dass der Hoster einen Proxy (a.k.a. "Reverse-Proxy") betreibt, der z.B. überhaupt erst verschlüsselt…

Oder ein Varnish-Cache beim Hoster. Allerdings sollte der nicht clientspezifisch agieren.

Rolf