Non pas complètement. Cela n'affecte pas les requêtes indirectes effectuées par les framework javascripts qui contrôlent la cachabilité et ne tiennent pas compte de l'action utilisateur initiale, ces requêtes sont effectuées séparément et via des actions différées indépendantes de la page affichée dans sont état actuel.
Pour Chrome je dois encore utiliser CTRL+SHIFT+DEL et demander cette purge complète (cependant cela n'efface pas les éléments encore référencés dans les onglets ouverts et qui restent dans le cache, sinon ça boguerait leur affichage : presser F5 ou SHIFT+F5 ne suffit pas, il faut encore naviguer ailleurs pour fermer les utilisations des éléments du cache et lui permettre de se vider, mais pour les tuiles on peut simpler zoomer, purger, et dézoomer pour supprimer cette association. Il n'y a pas encore d'action dans Chrome qui éviter d'utiliser le cache pendant une durée définie (par exemple le chargemetn de la page puis les requêtes différées déclenchées à la demande des framework : il faudrait pouvoir faire SHIFT+F5 pour commencer la purge et maintenir la touche SHIFT enfoncée pour que cette purge continue à s'appliquer à toutes les autres requêtes indirectes: ces éléments ajoutés viennent compléter/modifier le DOM de la page qui vient d'être complètement chargée et réffraichie et validée hors cache, mais avant que la page soit raffraichie réellement à l'écran, il reste aussi un délai de déclenchement pendant le quel ce n'est même pas le DOM qui maintient directement l'association, mais un cache interne du moteur de rendu qui dispose de sa propre copie séparée de l'ancien DOM dont les éléments ne sont pas encore remplacé par le nouveau DOM qui s'est chargé séparément dans un autre contexte. Et j'ai bien vu que cette purge même avec CTRL+SHIFT+DEL maintenait encore en mémoire (et dans le cache sur disque) des éléments dont ceux permettant le suivi (y compris les cookies traceurs, et des identifiants de session, sans compter les cookies internes de certains codecs) Ces astuces commencent à être connues des annonceurs publicitaires: la purge est superficielle, pas totale et maintient des éléments en vie assez longtemps pour pouvoir les réutiliser aussitôt la page raffraichiet et remettre dans le cache visible. Et je pense que les auteurs de Chrome ont justement fait en sorte que ça marche comme ça pour répondre aux demandes des réseaux d'annonceurs publicitaires (y compris ceux de Google Ads, Youtube, et les réseaux sociaux qui veulent pouvoir vous pister le plus longtemps possible de façon certaine sans avoir à utiliser des heuristiques). Une purge complète devrait aussi terminer tous les événements différés en les mettant en échec et invalidant leur contenu totalement, comme s'il n'y avait plsu de connexion internet du tout pour les connecter. Cela devrait terminer toutes les sessions en cours, tous les codecs actifs, tous les plugins et composants intégrés du navigateur qui référencent des éléments de la page, en les faisant pointer tous sur un objet d'erreur pour les forcer à recevoir des exceptions si c'était des événements bloquants, et briser toutes les associations avec des éléments en cache à tous les niveaux. Le mer. 19 sept. 2018 à 18:27, Jérôme Seigneuret < jerome.seigneu...@gmail.com> a écrit : > Pour ce qui utilise Chromium ou Chrome le cache se vide avec majuscule + > F5. my 2 cents ;-) > > Le mer. 19 sept. 2018 à 18:22, Philippe Verdy <verd...@wanadoo.fr> a > écrit : > >> Je ne vois pas de grande zone "grise" au **Nord** de la Ferté-Gaucher, >> mais à l'Est oui (et vu sa taille ce doit être un vieux polygone Corine >> 2006 qui a commencé à être retravaillé...) >> Et aussi bien dans le rendu OSM.ORG que .FR. >> >> Pense à vider de temps en temps ton cache navigateur si tu t'attends à >> des changements, la durée de péremption indiquée par les caches de tuiles >> est assez longue avant que ces tuiles soient automatiquement purgées et >> rechargées par le navigateur (mais en pratique le navigateur ne nettoie pas >> grand chose tant qu'il juge qu'il y a largement assez de place pour garder, >> il stocke, et pour les images (surtout celles chargés par un framework >> javascript et non directemetn référencé par le DOM d'une page HTML, il omet >> de vérifier les dates de péremption et affiche le plus vite possible les >> images trouvées dans sont cache sans interroger le réseau, surtout s'il a >> d'autres requêtes réseau en attente et plus urgentes: l'affichage est alors >> immédiat, le rafraichissement réel par une requête du navigateur (qui va >> monopoliser une session TCP et des tas de ressources, est mis en attente et >> sera annulé et reporté tant qu'il y a d'autres requêtes plus urgentes à >> faire, car le navigateur privilégie le temps de réponse et ne considère pas >> que les images statiques cachables ont une durée de vie *maximale* à ne >> jamais dépasser; et même s'il déclenche un rafraichissement en arrière-plan >> de son cache, et qu'il réussit à purger l'ancienne version en la remplaçant >> par une nouvelle version avec une nouvelle date de péremption, cela ne >> déclenche pas nécessairement un rafraichissemetn de l'affichage mais pour >> le voir il faut naviguer sur une autre page et y revenir...) >> Les serveurs de tuiles d'OSM sont tous conçus pour maximiser >> l'utilisation des caches par les clients (mais aussi les proxies >> intermédiaires, bien que ceux-ci adoptent des durées de péremption plus >> courtes que celles annoncée si le proxy est un proxy tiers partagé par des >> nombreux clients, tels que les proxies des FAI mobiles qui font tous de la >> mise en cache local pour régler le problème de surcharge des serveurs web >> par une adresse IP unique partagée par des clients qui n'ont pas eux-même >> d'adresse IPv4 propre mais se partagent un bloc d'adresses via un gros NAT: >> si ces FAI mobiles ne faisaient pas de cache local, ils se feraient tous >> bloquer par les serveurs pour abus d'usage comme si c'était un client >> unique, et l'accès mobile serait inutilisable. On attend que les FAI >> passent tous à l'IPv6 pour tous pour supprimer ces proxies gênants, et en >> plus qui font du traçage et du filtrage sans le dire aux abonnés!) >> >> >> >> Le mer. 19 sept. 2018 à 12:48, Nicolas Bétheuil <nbethe...@free.fr> a >> écrit : >> >>> Bonjour, >>> >>> Comment vous interprétez cette grande zone gris / vert plutôt que le >>> rose pâle qu'il y a autour >>> https://www.openstreetmap.org/#map=12/48.8106/3.5091 >>> c'est au nord est de la ferté gaucher >>> >>> Sur le rendu FR cette zone est plus petite >>> >>> merci >>> >>> _______________________________________________ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > > -- > Cordialement, > Jérôme Seigneuret >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
