8798 sujets

Développement web côté serveur, CMS

[Résolu] Bonne pratique n°184 OPQUAST (cache) ?

Bonjour à tous,

Je suis embêté par la Bonne pratique Opquast n° 184 pour mon site perso : www.id-generator.com.

Je parcours le web depuis une bonne semaine sans trouver une solution technique explicite pour que :
a écrit :
le serveur devra envoyer les champs ETag , Date et Last-Modified correspondant respectivement à l'identifiant de la ressource, à la date de traitement de la requête et à la date de dernière modification de la ressource demandée.


Je suis allé voir : Un tutoriel de la mise en cache qui est d'ailleurs très bien expliqué; Les spécifications HTTP Mais comment faire (avec quel language, quel code, ...) ?

J'ai essayé ceci en php :
<?php
$offset = 60 * 60 * 24 * 3;
$ExpStr = "Expires: " . gmdate("D, d M Y H:i:s", time() + $offset) . " GMT";
header("Cache-Control: must-revalidate");
header("Etag: ");
header($ExpStr);
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
?>

Que j'ai testé avec www.ircache.net mais le champ ETag n'est pas renseigné !? Smiley decu

Et surtout, est-ce que cette bonne pratique me concerne ?

Merci d'avance...
Modifié par ideas generator (17 Nov 2006 - 00:20)
Concernant les en-têtes à renvoyer:

- Date sera automatiquement ajouté par ton serveur web (Apache, LightTPD, etc...)
- tu n'est pas obligé d'envoyer ETag et Last-Modified, un seul suffit

Mais envoyer ces en-têtes n'est pas tout, ce n'est que la moitié du boulot. Si tu renseignes Last-Modified, la prochaine requête du document possèdera un en-tête If-Modified-Since correspondant à la valeur reçue précédemment. Il faut alors que ton serveur la compare à la date de mise à jour du document et si ce dernier n'a pas changé il faut répondre avec le statut 304 (et donc ne pas renvoyer le document). Pour ETag c'est pareil, si ce n'est qu'il est généré de façon arbitraire (ça peut être une combinaison de la date de modification, contenu du fichier, emplacement sur le disque, etc...). L'en-tête de requête qui correspond est If-None-Match. En général, il est plus pratique pour les languages comme PHP de répondre avec Last-Modified.

Sinon, si ton but est uniquement de forcer un fichier à rester dans le cache du navigateur pendant X secondes (et donc ne pas être mis à jour à chaque visite) sans pour autant qu'un proxy re-serve la même page à un autre utilisateur tu peux te contenter de quelque chose comme
Cache-Control: private, max-age=60


Tout dépend du type de données que tu sers, à chaque cas une stratégie est mieux adaptée.

Bonne continuation Smiley cligne
Pour info : C'est un serveur Apache (OVH).

a écrit :
tu n'est pas obligé d'envoyer ETag et Last-Modified, un seul suffit

D’accord, mais est-ce en accord avec la bonne pratique opquast #184 qui stipule que les deux doivent être envoyés ?

a écrit :
Mais envoyer ces en-têtes n'est pas tout, ce n'est que la moitié du boulot. Si tu renseignes Last-Modified, la prochaine requête du document possèdera un en-tête If-Modified-Since correspondant à la valeur reçue précédemment. Il faut alors que ton serveur la compare à la date de mise à jour du document et si ce dernier n'a pas changé il faut répondre avec le statut 304 (et donc ne pas renvoyer le document). Pour ETag c'est pareil, si ce n'est qu'il est généré de façon arbitraire (ça peut être une combinaison de la date de modification, contenu du fichier, emplacement sur le disque, etc...). L'en-tête de requête qui correspond est If-None-Match. En général, il est plus pratique pour les languages comme PHP de répondre avec Last-Modified.

Le problème c'est qu'en php, je n'ai que des bases.

a écrit :
Sinon, si ton but est uniquement de forcer un fichier à rester dans le cache du navigateur pendant X secondes (et donc ne pas être mis à jour à chaque visite)

Le but de la manip. c'est que mon site soit en conformité avec la dite bonne pratique tout en respectant la mise en cache définie par défaut.

Ce que je ne comprend pas c'est que avant d'insérer le code php mentionné dans mon précédent message, google (ou autre) mettais déjà en cache par défaut mais le serveur ne renvoyai pas les champ demandés (Date, ETag et Last-Modified) lors du test avec www.ircache.net Smiley ohwell
Modifié par ideas generator (16 Nov 2006 - 00:53)
ideas generator a écrit :
est-ce en accord avec la bonne pratique opquast #184 qui stipule que les deux doivent être envoyés ?

C'est en accord avec la RFC 2616, je pense que l'article d'opquast est mal formulé : ces deux champs sont optionnels et leur fonctionnalité est identique (redondante).

a écrit :
Le problème c'est qu'en php, je n'ai que des bases.

Tu l'as dit, c'est ça le problème Smiley smile Il n'existe pas de gestion automatique du cache pour les scripts PHP, c'est à toi de tout faire. Mais il faut aussi savoir que très très peu de scripts sont, en pratique, "cachables". Ça demande beaucoup de rigueur, et à moins que tu n'utilises un reverse proxy et/ou que ton site est extrêmement populaire (centaines de pages par seconde) ça n'a que peu d'intérêt. Ceci dit, si tu as envie de t'investir pour apprendre à le gérer, c'est une excellente chose.

a écrit :
Le but de la manip. c'est que mon site soit en conformité avec la dite bonne pratique tout en respectant la mise en cache définie par défaut.

S'il ne s'agit pas d'un besoin d'ordre technique alors oublie la mise en cache. Tous les en-têtes cités sont optionnels, si tes pages sont dynamiques alors tu peux ajouter cet en-tête pour garantir que la page ne sera jamais mise en cache
Cache-Control: no-cache

C'est à peu près tout ce dont tu as besoin, d'ailleurs, même si tu n'envoies pas cet en-tête il est à peu près certain que le navigateur ne gardera pas la page en cache de toutes façons.

a écrit :
Ce que je ne comprend pas c'est que avant d'insérer le code php mentionné dans mon précédent message, google (ou autre) mettais déjà en cache par défaut

Il faut savoir que la mise en cache est à la discrétion du destinataire. Si tu n'indiques pas d'informations de validité ("max-age", "Expires", etc...) alors le destinataire est libre de garder une copie en cache aussi longtemps qu'il le décide (période déterminée par des heuristiques). Sauf bien sûr si tu indiques "no-cache" ou "private" dans Cache-Control.

Pour résumer, la mise en cache n'est pas fait pour tous. En fait, si tu vas sur l'index de google.com ou yahoo.com tu verras (https://addons.mozilla.org/firefox/966/) que le seul en-tête qu'ils renseignent est "Cache-Control: private". Même cette page que tu es en train de lire n'a aucun des headers qu'on a cité Smiley rolleyes (à part Date bien sûr).
Modifié par Hubert Roksor (16 Nov 2006 - 02:33)
a écrit :
Hubert Roksor a écrit :
S'il ne s'agit pas d'un besoin d'ordre technique alors oublie la mise en cache. Tous les en-têtes cités sont optionnels

En effet il ne s'agit pas d'un besoin d'ordre technique.

Merci pour toutes ces informations, elles ont éclairé ma lanterne.

Dois-je donc considérer la bonne pratique #184 comme "Non-applicable" pour moi ?
Modifié par ideas generator (16 Nov 2006 - 18:45)
ideas generator a écrit :
Dois-je donc considérer la bonne pratique #184 comme "Non-applicable" pour moi ?

On peut dire que oui. Sachant que de toutes façons Apache s'occupe déjà de la mise en cache (les en-têtes, les réponses 304, etc...) de tous les fichiers statiques : images, scripts, et fichiers CSS.
Sujet clos
Aller à