php no-cache inefficace sur Safari?

[sabearts]

Hello,
je teste une série de pages dont je voudrais qu'elles ne soient pas du tout stockées en cache (en d'autres termes, cliquer sur la flèche "retour" de Safari devrait l'obliger à recharger) et j'utilise donc avant tout affichage et avant tout require:

header("Cache-control: no-cache, no-store, must-revalidate");
header("Expires: Sat, 10 Feb 2007 23:00:00 GMT");

mais ça ne va pas parfaitement. Mon problème est que si je me délogue, et que je clique sur la flèche retour du navigateur, pas de bol, la page précédente censée être confidentielle se réaffiche!
Bon, elle est inefficace car le logout est bel et bien fait, lui, cependant ça signifie que quiconque a accès à l'ordinateur concerné peut à son aise revisionner les pages privées de l'utilisateur précédent. Pas très privé...

Y a-t-il un moyen d'empêcher réellement Safari de mémoriser cela? (je précise que j'ai un vieux Safari 1.0.3...mais bon mon site doit marcher avec tous les navigateurs...)

 

[Anonyme]

D'habitude les navigateurs ne rechargent pas une page si elle n'a pas été changée, ce qui permet un affichage plus rapide car il ne faut par recharger les données d'internet. En ce qui concerne le no-cache, si j'ai bien compris, tu dis qu'il ne doit pas mettre la page en cache et que donc qu'il doit la recharger à chaque fois, ce qu'il fait.

Je ne vois pas pourquoi un système avec session et authentification ne serait pas efficace…

 

[GrandGibus]

Une section interessante dans cette doc apple à la page 51 Client-Side Page Cache.

Voici un résumé des valeurs que tu peux avoir dans le header:

• date : The time the response page was generated.
• expires : The time the response is to expire. (Same as date.)
• pragma : no-cache
• cache-control : private, no-cache, no-store, must-revalidate, max-age = 0

Je ne les ai pas testés... Dis-nous si ça fonctionne .

 

[sabearts]

merci, et je viens de trouver moi aussi dans les faq d'apple sur safari quelques conseils. Je les essaie et je dis quoi!
Pour Gloup Gloup: cela pose en effet un problème, car comme je l'ai dit il est possible de faire un backward sur une page loguée alors qu'on n'est plus logué, et pour info Gmail a le même problème: sur IE ça va bien (pour une fois), mais avec Safari je peux faire ce que je veux, même effacer l'historique, si je reviens en arrière je revois mon inbox. c'est assez emmerdant... sauf si je quitte l'application!

 

[sabearts]

La solution a donc été trouvée, et Apple fournit une astuce à l'adresse suivante:

http://developer.apple.com/internet/safari/faq.html#anchor5

il faut donc, en plus des headers, ajouter un iframe qui peut être invisible pour éviter le cache back/forward. ce que j'ai fait, ça marche à fond! Un vrai bonheur.

 

[p4bl0]

La solution a donc été trouvée, et Apple fournit une astuce à l'adresse suivante:

http://developer.apple.com/internet/safari/faq.html#anchor5

il faut donc, en plus des headers, ajouter un iframe qui peut être invisible pour éviter le cache back/forward. ce que j'ai fait, ça marche à fond! Un vrai bonheur.

c'est nul à chier comme solution ce que donne Apple ça ne respecte pas les standards... no iframe.

Le truc c'est que no-cache devrait fonctionner dans Safari et puis c'est tout. Obliger les webmaster à mettre une iframe... :rolleyes:

 

[PA5CAL]

c'est nul à chier comme solution ce que donne Apple ça ne respecte pas les standards... no iframe.

Le truc c'est que no-cache devrait fonctionner dans Safari et puis c'est tout. Obliger les webmaster à mettre une iframe... :rolleyes:

Je compatis...

Je me rappelle avoir pensé la même chose à propos de plusieurs versions de Microsoft Internet Explorer !

Force est de constater que les éditeurs de navigateurs Internet prennent des libertés avec la norme (les recommendations du W3C). De ce fait, ils imposent aux développeurs de sites Web de prévoir un codage spécifique pour chaque navigateur susceptible d'être utilisé par les visiteurs...

Ça ne fera donc qu'une particularité supplémentaire à ajouter à une liste déjà longue.