Je vais vous étonner, je me suis moi-même étonné de mon savoir-faire. Je vous présente aujourd'hui le résultat d'une recherche sur une problématique sur laquelle je me suis cassé la tête pendant plusieurs semaines.
Dans le cadre de mon emploi, dont le travail est de gérer de la documentation, l'ensemble de ma documentation est en train d'être migré sur Joomla. Toutefois, l'existant est un ensemble de pages web statiques HTML avec des liens hypertexte vers des fichiers PDF. En cliquant sur ces liens, mes utilisateurs téléchargent le fichier souhaité.
Mon travail est en la mise à disposition de ces fichiers PDF au sein de l'ensemble des pages statiques de notre site. Nous sommes en train de migrer sur Joomla, mais le travail n'étant pas totalement fini, je continue à maintenir ce site web statique.
Ma problématique
Avant toute chose, il faut replacer le contexte. Je reprends le travail de mon prédécesseur, qui ignorant totalement HTML, a "codé" l'ensemble de ces pages web sur une vieille version de Word ! (Oui oui !!) Cette version génère des fichiers HTML 100 % compatible ... avec les anciens navigateurs Microsoft uniquement. Autant dire, rien n'est fonctionnel. Il faut aussi savoir que la politique de" Micro$soft est l'utilisation uniquement de Firefox.. Tout cela étant incompatible, Il faut donc tout remigrer sur un langage HTML propre en attendant la migration Joomla.
En attendant cette migration vers Joomla, je continue à devoir maintenir ce "site", ces pages. Je me suis rendu compte récemment, à mon avis cette problématique étant liée, je suppose, au navigateur Internet Explorer 7 de mémoire (et je n'ai pas le choix dans ce navigateur) que lorsque je fais une mise à jour d'un fichier PDF sur un serveur, le nom de fichier ne changeant pas, contrairement à son contenu totalement modifié, que lorsque l'utilisateur, une fois ma mise à jour effectuée, clique sur le lien du fichier, le navigateur de Microsoft de télécharge pas directement le nouveau fichier mais propose à l'utilisateur le fichier contenu dans la mémoire cache du navigateur.
Mes utilisateurs étant avant tout des techniciens mais pas informaticiens, leur demander à chaque fois d'utiliser la combinaison de touche Contrôle F5 et totalement impossible. D'autant plus que je ne connais pas l'ensemble de mes utilisateurs de mon intranet. J'ai dû donc trouver une solution pour que le navigateur ne stocke jamais en cache les fichiers PDF.
La première piste que j'ai creusé, c'est l'utilisation de balises <méta>, qui devrait avoir pour but de ne rien enregistrer dans le cache du navigateur. Je vous rappelle que nous travaillons avec Microsoft qui ne fait jamais rien comme le W3C le dit... j'ai donc dû rechercher une solution fonctionnelle de manière à contourner l'absence de suivi des normes du géant Microsoft.
La solution
La solution théorique ne vient pas de moi mais cette solution fonctionne extrêmement bien. Pour comprendre, nous devons faire un petit focus sur le cache du navigateur.
En effet, le cache va associer une URL avec un fichier tampon, ce fichier étant stocké dans le répertoire "cache" du navigateur Web. Lorsque vous rechargez une page, si cette page a déjà été chargée depuis le serveur, le navigateur vous recharge automatiquement la page stockée dans le cache (la mémoire tampon) de ce dernier, évitant un aller-retour client<->serveur. La problématique était que l'utilisateur, qui demandait un fichier PDF que je venais de mettre à jour sur le serveur, ne voyait jamais la dernière version de ce fichier PDF déposé/remplacé sur le serveur. L'utilisateur voyait en général le fichier à son tout premier chargement sur le poste. Si on comprend bien ce problème, la seule solution était de contourner le cache (ou que l'utilisateur vide son cache ... mais "il n'est pas technicien lui".
Bien que des balises META sont censées effectuer ce travail, je n'ai jamais réussi dans l'outil Internet Explorer, à bien faire fonctionner ces méta. De vous à moi, rien ne m'étonne. Mais alors, comment faire ?
Bien que des balises META sont censées effectuer ce travail, je n'ai jamais réussi dans l'outil Internet Explorer, à bien faire fonctionner ces méta. De vous à moi, rien ne m'étonne. Mais alors, comment faire ?
Ma solution
Pour comprendre la solution que j'ai mise en place et qui fonctionne parfaitement bien, il faut bien avoir en tête que le navigateur, dans son cache, associe une URL à un fichier PDF. Je ne parle pas des fichiers HTML dans mon exemple mais c'est exactement le même problème.
La seule différence lorsque nous sommes dans un contexte de fichier HTML nous pouvons appliquer des balises MET à ses fichiers HTML pour forcer la non utilisation du cache.
Or comme nos navigateurs "récents" savent charger et afficher un fichier PDF nativement et c'est cette fonctionnalité qui est utilisée chez nous. Techniquement, il est impossiuble d'appliquer dans mon fichier PDF une quelconque "balise" ou "fonctionnalité" pour demander au navigateur qu'il contourne son cache pour les fichiers PDF.
Il faut aussi connaître un petit peu le fonctionnement du cache d'un navigateur et je reviens dessus.
Fonctionnement du cache
Vous le savez sûrement, pour pouvoir recharger du cache du contenu, le navigateur s'appuie sur les URL. Et comme une URL est unique, le navigateur recharge exactement la page de son cache associée à l'URL demandée, et ce de manière transparente pôur l'utilisateur, sans la redemander au serveur. Et c'est exactement le contraire que je souhaite faire.
Au lieu de m'énerver sur la gestion du cache, ou encore la gestion des pages et des valises meta dans les pages HTML, en cherchant un peu sur internet, j'ai trouvé une personne qui a trouvé elle-même une solution plutôt originale, mais extrêmement fonctionnelle. Pour chacun des fichiers PDF, elle va générer une URL unique vers le fichier PDF. Mais allez-vous me dire, tu changes de nom de fichier à chaque fois ?
La solution
Faire et de faire c'est toujours travailler. Mais j'ai passé un peu l'âge de faire et refaire et de faire et remonter des URL unique à chaque chargement de page de mes utilisateurs. J'ai donc opté pour une petite fonction en javascript, que vous retrouverez facilement sur le net, qui va me générer une chaîne de caractère totalement aléatoire, basée sur un timestamp.
Cette chaîne de caractères, je la passe dans l'URL après mon ?, symbolisant dans l'url un paramètre, de la manière suivante :
www..../monfichierPDF.pdf?
De mémoire, je crois que la chaîne de caractère générée fait 50 caractères, mais vous pouvez opter pour beaucoup plus. L'idée étant que pour un client donné, un navigateur d'un utilisateur donné, le client ne retombe jamais deux fois sur cette url complète, prenant en compte cette chaîne de caractère particulière.
Ainsi, dans le cache du navigateur, quasiment jamais n'est stocké deux URL identiques. On croise les doigts, c'est grâce aux fonctions aléatoires de JavaScript de génération de chaînes que j'ai généré cette chaîne de caractères point ainsi, nous avons une URL complète, qui se termine par le nom du fichier PDF avec en paramètre un truc bidon qui ne sert à rien, sauf à contourner mieux cache du navigateur.
Eet le navigateur Internet Explorer est extrêmement bête, et heureusement, il prend en compte l'ensemble de l'URL, il s'abstient de faire une troncature après le point d'interrogation.
Ainsi, je n'ai jamais deux fois et à même URL dans le cache d'un navigateur, je force donc le téléchargement de la dernière version du fichier PDF que je mets à disposition de mes utilisateurs
Le Script
<script>
function lien(link, description){
document.write('<a href="'+link+'?'+Math.random().toString(36)+'+">'+fr'+description+'</a>');
}
</script>