SESSION Problem mit Safari / Opera

[mcmurphy]

Also habs nochmal mit Safari getestet - kein Erfolg.
Mich wundert ja das es beim googlen einige englischsprachige Beiträge zu dem Thema gibt (Safari Back button not honouring PHP logout session - Stack Overflow aber auch da leider keine Lösungen...

Kann doch nicht sein , klappt bei anderen Seiten auch ...

[onemorenerd]

Das Prinzip ist dir aber schon klar oder?
Beim Login setzt du ein Session Cookie. Der Browser schickt das bei jedem weiteren Request mit. Als Antwort bekommt er von dir immer eine Seite mit dem Hinweis "darf gecacht werden". Beim Logout weist du den Browser an, das Session Cookie zu löschen und diese eine Seite nicht zu cachen.
Aber die früheren Seiten verbleiben im Cache - jedenfalls bei Safari. Andere Browser erkennen evtl. dass das zu löschende Session Cookie auch zu anderen Seiten im Cache gehört und löschen diese. Safari eben nicht. Völlig legitim, denn es gibt keine Vorschrift, keinen Standard, der das verlangt.

Die einzige Lösung des Problems "Seiten werden aus Cache geladen" ist, das Caching von vornherein zu verbieten. Also immer wenn ein User eingeloggt ist, solltest du Header senden, die das Caching verbieten.
Welche Header das sind, kann man überall im Netz nachlesen, z.B. im Manual zu header (Beispiel #2, beachte auch den Hinweis darunter).

[mcmurphy]

Als Antwort bekommt er von dir immer eine Seite mit dem Hinweis "darf gecacht werden".

Na ich sende doch immer als erstes header die das cachen unterbinden sollen

Das von dir genannte Beispiel #2 aus header war ja mein Ausgangspunkt .....

Habe gerade nochmal

header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Datum in der Vergangenheit 

aus deinem Beispiel im Code eingesetzt, Safari zurückgesetzt (Caches leeren & Cookies Löschen) und neu ihn gestartet:
Die Entwickler Tools zeigen mir folgendes:

Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0, no-store, no-cache, must-revalidate
Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:930
Content-Type:text/html; charset=UTF-8
Date:Thu, 06 Jan 2011 16:47:29 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive:timeout=1, max=100
Pragma:no-cache
Server:Apache
Vary:Accept-Encoding
X-Powered-By:PHP/5.2.12-nmm2 

und session_cache_limiter(); gibt mir nocache - aber er holt immer noch Seiten aus dem Cache *seufz*

Wie gesagt - es wird ja auch nur eine seite (index.php) aufgerufen und dann der Content included - und ganz oben (direkt nach error_reporting(E_ALL) stehen meine header();

[onemorenerd]

Habe gerade nochmal

header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Datum in der Vergangenheit 

aus deinem Beispiel im Code eingesetzt, Safari zurückgesetzt (Caches leeren & Cookies Löschen) und neu ihn gestartet:
Die Entwickler Tools zeigen mir folgendes:

Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0, no-store, no-cache, must-revalidate
...
Expires:Thu, 19 Nov 1981 08:52:00 GMT 

Wieso kommen bei Safari ganz andere als die von dir gesendeten Header an? Kann es sein, dass du weiter unten im Script nochmal andere Header setzt oder rufst du sogar ein ganz anderes Script auf?

[mcmurphy]

das wird mir durch session_start ausgegeben.
Habe mal alle Header und session_start auskommentiert, dann bekomme ich

Cache-Control:no-cache, must-revalidate
Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:895
Content-Type:text/html
Date:Thu, 06 Jan 2011 17:48:41 GMT
Expires:Sat, 26 Jul 1997 05:00:00 GMT
Keep-Alive:timeout=1, max=100
Server:Apache
Vary:Accept-Encoding
X-Powered-By:PHP/5.2.12-nmm2 

als Antwort

mit Session_start dann:
Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0



habe ich anscheinend mal wieder was zum googeln
Und hier mein Ergebniss:
Laut http://php.net/manual/de/function.session-start.php unter Anmerkungen:

In Abhängigkeit von der Konfiguration sendet diese Funktion verschiedene HTTP-Header. Siehe session_cache_limiter() um diese Header anzupassen,

und in http://de2.php.net/manual/de/functio...he-limiter.php
Dann unter User Contributed Notes:

FALSE parameter disables any automatic cache limiter
In this case no additional headers are sent

<?php
session_cache_limiter( FALSE );
?>

Dann sendet mein Script nur die in header(); angegeben caching anweisungen - aber nach erstem Test ohne Erfolg (in meinem Sinne....)

[mcmurphy]

HAbe jetzt nochmal nen test gemacht:
2 Dateien, index.php & index2.php mit folgenden Inhalt:

<?php
    header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
    header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Datum in der Vergangenheit
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/transitional.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
<head>
  <title>test 1</title>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head>
<body>
<?php    echo time(); ?>
<br />
<a href="index2.php">nach 2</a>
</body>
</html>

sind identisch bis auf <a href="index2.php">nach 2</a>, da steht in Index2.php natürlich als Ziel index.php drin

Safari ignoriert einfach die Cache Anweisungen...
Überlege mir morgen was - wenn einer ne Vorschlag für einen Würgaround hat....

[mcmurphy]

So, wenn einen des Rätsels Lösung interessiert:
Safari & Opera reagieren auf die caching Header nur bei einer https Verbindung.

aus:
php - CodeIgniter session issue on Opera and Safari - Stack Overflow

Short answer: the only way to prevent Opera from using cache on history navigation (back/forward button) is to serve the page over https with Cache-control: must-revalidate header.