bonsoir,

je rencontre une énigme.

je viens de refaire un site..... l'ancien était en html avec des frames, le nouveau est en php,et l'hébergement physique a changé (sur un pack Amen, je suis passé de l'hébergement statique à l'hébergement hosting starter Linux, pour ceux qui connaissent ce prestataire).

donc les fichiers en html ne sont plus sur l’hébergement et malgré ça quand je charge la page sur un autre pc chez moi j'ai encore l'ancienne page d'accueil qui s'affiche. c'est rentré dans l'ordre quand j'ai réactualisé (ctrl + f5) le rechargement mais comment cela est il possible?
le navigateur ne vérifié pas si la page a changé ou disparu, avant de charger celle du cache du navigateur??

bizarre ça, non?

j'ai bien fait une page d'erreur 404 custom, mais elle se charge dans la frame, c'est pas beau, vous pouvez expliquer ça??

merci
a écrit :
Comportement inexplicable du navigateur

Mais bien sûr que si c’est explicable Smiley cligne

a écrit :
le navigateur ne vérifié pas si la page a changé ou disparu, avant de charger celle du cache du navigateur??

Et bien pas toujours… cela dépend de la configuration du serveur web et de ce que l’on cherche à faire.

a écrit :
bizarre ça, non?

Non, pas plus que ça quand on sait comment fonctionnent les choses.

Les dialogues entre un navigateur et un serveur web peuvent prendre de nombreuses formes en fonction des entêtes envoyés par chacun.

Pour faire simple, lors de la première demande d’accès à une ressource, on peut avoir un dialogue du genre :

a écrit :
– navigateur : bonjour serveur, je voudrais la ressource « exemple.html »
– serveur web : hé, salut navigateur, aucun problème, voila la ressource en question.


Dans cet exemple, le navigateur envoi des entêtes pour demander la page et le serveur renvoi le contenu de la page mais également diverses informations dans les entêtes.
Il peut par exemple envoyer la date de modification du fichier ou un numéro de version et là, la prochaine fois que le
navigateur demandera la page, le dialogue ressemblera à :

a écrit :
– navigateur : je demande la page « exemple.html » et j’ai la version du 22 avril (ou la version 238ABF7292)
– serveur : j'ai pas de version plus récente !


Dans ce cas, le navigateur demande la page mais indique également la version qu'il a en cache et si le serveur n’a pas une version plus récente alors il ne renvoie que les entêtes pour dire : ok utilise ta version en cache, j'ai pas mieux (il renvoie un code 304 Not Modified). C’est plus rapide car le contenu de la page n’est pas envoyé.

Mais il existe un autre cas possible encore plus rapide. Les développeurs ou administrateurs le mettent souvent en place histoire d'optimiser au maximum les temps de chargement et éviter les dialogues entre navigateur et serveur web.

a écrit :
– navigateur : salut, je demande la page « exemple.html »
– serveur web : ¡Hola, OK là voila et garde la pendant 1 mois


Là encore, le navigateur demande une ressource, le serveur web lui envoie mais lui précise qu’elle sera valide pendant 1 mois avec les entêtes « Expires » ou « Cache-Control » afin d’indiquer une date de péremption ou une durée de validité.
La prochaine fois que le navigateur à besoin du fichier… il ne demande même plus au serveur, il n'y aucun dialogue : c’est bien plus rapide.

Ce genre de chose est très souvent utilisé pour les fichiers statiques (javascript, css). Alsacréations l’utilise d’ailleurs sur ce forum.
Ton navigateur ne demande plus la feuille de style par exemple tant qu'elle est valide dans son cache et ceci même si elle change sur le serveur.


Pour en revenir à tes problèmes :

Il est possible que le serveur eût envoyé une durée de mise en cache car un fichier html est un fichier statique et du coup, le navigateur ne lui demande pas si une autre version existe pendant la durée de validité du cache ; à moins bien évidement que tu forces la demande avec ton rafraichissement forcé.

Dans, firefox par exemple, tu peux voir les fichiers en cache et leur date d’expiration avec l’adresse : "about:cache?device=disk".
Tu verras sans doute des dates d’expiration dans le passé : les pages seront redemandées au serveur (c'est souvant le cas pour les fichiers PHP qui par défaut indique une date d’expiration dans les années 70 ou 80) mais tu verras aussi des dates éloignées de plusieurs mois pour les fichiers javascript et css.

Pour ton problème de 404… je ne vois pas trop et sans adresse pour tester c’est pas évident de trouver mais c’est peut-être un problème similaire.
Il faudrait que tu essayes de vider complètement le cache de ton navigateur afin de voir si le comportement est toujours le même.


… en espérant n’avoir pas été trop barbant.
Merci d'avoir pris le temps de me faire cette réponse très argumentée, mais le cas est beaucoup plus simple....

les pages n'existent plus sur le serveur....elles ont été remplacées: index.htm (oui sans le l de html ça datait de 2004) à été remplacé par index.php et en plus je tape une adresse du style
http://www.domaine.com/ donc je ne comprends pas comment le serveur peut renvoyer une page qui n'existe plus..

c'est pas tellement pour moi, je sais vider le cache, c'est surtout pur l’utilisateur lambda qu iva aller sur le site et qu aura visité avant l'ancienne version.
Si si, le cas semble bien être celui que je décris.

Quand le navigateur demande la ressource « http://www.domaine.com/ », que ce soit un index.htm, index.html ou index.php qui soit derrière n’a pas d’importance. Le navigateur ne le saura pas.

Pour un navigateur et un serveur, les ressources sont identifiées par l’url demandée et non pas le fichier qui est derrière.

Par exemple :
- http://www.domaine.com/
est bien considérée comme une ressource différente de :
- http://www.domaine.com/?plop
même si ce paramètre n’influe pas le contenu de la page.

De la même façon,
- http://www.domaine.com/
- http://www.domaine.com/index.php
- http://www.domaine.com/index.php?exemple
sont bien considérées comme trois ressources différentes même si dans tous les cas c'est le index.php qui est utilisé.


Pour forcer le rafraichissement d’une ressource (images, fichiers, etc.) on peut par exemple passer un paramètre bidon dans l’adresse (genre : style.css?20120422) pour que le navigateur considère qu'on demande une nouvelle ressource.

Dans le cas l’adresse de base… je ne vois pas de solution si ce n’est attendre que le cache des internautes se mette à jour de lui même.
Bonsoir à toutes et à tous,

très intéressant cette discussion ! Smiley smile

Afin de forcer le "rafraichissement" de la page, le nombre dont parle Jules-F (genre : style.css?20120422) doit être un nombre aléatoire, c'est à dire un nombre qui change à chaque fois. Si c'est toujours le même, cela ne sert pas à grand chose.

Ensuite, dans le head de la page web, on peut mettre un truc de ce genre :
<META HTTP-EQUIV="Cache-Control"    CONTENT="no-cache, must-revalidate" />
<META HTTP-EQUIV="EXPIRES"          CONTENT="0" />
<META HTTP-EQUIV="Pragma"           CONTENT="no-cache" />

afin de ne pas stocker la page dans la mémoire cache du navigateur.

@ Jules-F : si tu as des conseilles à nous communiquer sur ce que l'on doit mettre dans le head de la page web, du genre les <meta>, je suis preneur !

Au niveau du serveur, existe-t-il d'autres déclarations à faire ?
(je sous sous apache 2.2.21 par l'intermédiaire de wampserver 2.2dX32

@+
Modifié par Artemus24 (25 Apr 2012 - 00:15)
@Artemus24 : Je n’ai pas tellement de chose à ajouter… en général ce que je fais dépend beaucoup du projet, c’est du cas par cas. J’essaye néanmoins d’utiliser le plus possible les différents cache à disposition car un site rapide c’est quand même bien agréable et quand par exemple c’est un e-commerce ça se traduit par des ventes en plus et très souvent un meilleur référencement.

Ce que tu indiques, c’est bien quand tu souhaites à chaque fois recharger la page du serveur, moi j’essaye en général de faire justement l’inverse à l’aide des header « Etag » ou « Cache-Control ». Je tente d’éviter à devoir passer par les choses du genre styles.css?20120425 car cela empêche la ressource d’être mise en cache par certain proxy.

Le site http://fr.html5boilerplate.com/ regorge de petites informations pour optimiser les performances d’un site… faut pas hésiter à télécharger et à étudier (il y a un fichier .htaccess dans le zip pour les directives apache).

Quand j’ai débuté le développement web il y a des années, je considérais le cache navigateur comme une véritable plaie qu’il fallait absolument éviter car certaines de mes modifications ne se voyaient pas immédiatement… maintenant c’est le contraire, je tente de l’utiliser au maximum car j’ai compris son fonctionnent et je sais le dompter Smiley cligne
Bonjour Jules-F,

merci pour tes conseils !

Il y a tellement de choses à maitriser dans le monde web, que je n'arrive pas toujours à bien comprendre l'intérêt de telle ou telle manipulation. Mais cela s'acquière par l'expérience, et en ce domaine, je ne suis pas le seul à en manquer.

Sinon, pour ton problème, comment penses-tu solutionner le rafraichissement de ton site web sur les navigateurs des internautes ?

@+
@Artemus24

a écrit :
merci pour tes conseils !
C’est avec plaisir que je le fais.

a écrit :
Mais cela s'acquière par l'expérience, et en ce domaine, je ne suis pas le seul à en manquer.
mais ça c'est certain, j’ai 12 ans d’expérience dans le développement web et j’en apprends encore, ça évolue très vite… c’est parfois difficile de trouver le temps pour tout suivre.

a écrit :
Sinon, pour ton problème, comment penses-tu solutionner le rafraichissement de ton site web sur les navigateurs des internautes ?


Il y a méprise… moi je n’ai pas de problème Smiley cligne .

Mais en résumé, voila ce que je fais quand je le peux :

Pour les fichiers statiques (css, javascript, voir images)

J’évite les adresses du genre :
<script src="/scripts/mon-script.js?20120426"></script>

afin de profiter de la mise en cache des proxy.

Je préfère donc :

Soit changer directement le nom du fichier dans la page… c’est pas un travail enorme mais faut également renomer le fichier physique, supprimer l’ancien etc.
<script src="/scripts/mon-script-20120426.js"></script>


Soit utiliser une adresse du genre
<script src="/scripts/version2/mon-script.js"></script>

et changer le numéro de version lorsque le script est modifié.

Si on veut éviter d’avoir à changer le nom physique du fichier et de supprimer l'ancien, on peut mettre en place une réécriture d’url comme par exemple :
RewriteRule   ^/scripts/version([0-9]*)/(.*)$  /scripts/$2


BoilerPlate par exemple, regénère un nouveau nom de fichier script et remplace les références qu'il trouve dans les pages… mais effectivement les scripts de pré-traitement d'un site ne sont pas à la porté de tout le monde, faut un minimum d’expérience.

Pour les pages web dynamiques
Je ne force rien, je prends en compte… c’est là la grosse différence.
Je ne passe pas par une directive apache pour gérer les entêtes mais je le fais en PHP par exemple, justement pour faire du cas par cas.

Prennons un exemple concret, j’ai encore la plume légère ce soir Smiley cligne

Admettons que tu génères avec PHP une page d’accueil un peu lourde parce qu’il y a beaucoup d’informations dedans et que tu veuilles gérer le cache du navigateur en fonction de la date de dernière modification de ta page.

À l’aide de PHP et de la variable $_SERVER, tu peux écouter les entêtes indiqués par le navigateur et répondre en fonction.
Par exemple voici le début de ta page fictive :


<?php
/*
    La tu dois avoir un petit traitement de ton cru pour récupérer la date de dernière modification que tu as peut-être enregitrée dans une table de la base ou en RAM ou dans un fichier, etc.
*/
$lastModificationDate	=	''; // Tu enregistres ta date dans cette variable

/*
    si le navigateur a déjà visité la page et l’a en cache, il va indiquer dans cet entête la date du document qui lui avait été indiquée par le serveur
*/
$navigatorPageCacheDate	=	isset($_SERVER['HTTP_IF_MODIFIED_SINCE']) ? $_SERVER['HTTP_IF_MODIFIED_SINCE'] : false;

/*
    Si la date de modification du document en cache sur le navigateur est la même que celle de dernière modification des informations alors on envoie juste un code 304 et on stop le script : de cette façon, il n'y a que les entetes qui sont envoyés. Le contenu de la page n’est ni généré (soulagement du serveur) ni envoyé (soulagement de la bande passante).
*/
if ($navigatorPageCacheDate == $lastModificationDate) {
	header('HTTP/1.0 304 Not Modified');
    exit();
}

/*
    Sinon, ça veut dire que soit le navigateur n’a jamais visité la page ou que sa version n’est plus bonne dans ce cas, on indique dans l’entête la nouvelle date et on fait tout le gros traitement : recherche des infos dans la base de données, construction de la page et le contenu sera ensuite envoyé au navigateur.
*/
header('Last-Modified: ' . $lastModificationDate);

// Suite de ton traitement PHP :
// L'appel aux fonctions
// Les grosses requètes SQL ...
// La construction de la page ...
// etc.
?>


Bon ce code n’est pas testé, c’est pour donnée une idée. D’ailleurs il vaudrait mieux en faire une fonction (attention, les dates des entetes sont dans un format particulier) et il y en a d’autres entêtes que tu peux utiliser (pour utiliser des numéros de version à la place de dates de dernières modifications par exemple).
Modifié par Jules-F (26 Apr 2012 - 21:31)