Cette fonctionnalité nommé IBR - Intelligent Browser Referencing – permet d’optimiser le cache côté client. Le BIGIP va modifier les informations de cache control et va modifier le contenu web afin que les navigateurs gardent en cache les objets bien plus longtemps que prévu initialement par le serveur WEB.
Un mécanisme de réécriture permet d'éviter les faux positifs au niveau du cache.
Voici l’explication et la démonstration en images.
Bonjour Mathieu,
Comment est-ce que le module vérifie si l’élément dans le cache a change sur le serveur final ? Il y a des requêtes régulières pour cet objet depuis le boitier F5 ?
Merci,
Bonjour Mobo, désolé du retard, je n'avais pas flagué mon article, du coup, pas de notification :)
Exact, en faite, l'AAM garde comme information de Cache Control, soit ce que le serveur lui a dit (par exemple si c'est 2 jours, alors l'AAM ira au bout de 2 jours vérifier auprès du server), soit l'admin de l'AAM a changer cette info et alors l'AAM ira au moment défini par l'admin.
Exemple :
- Tu te rends compte que le logo.gif de la société est configuré avec un cache control de 4 heures côté server. Il est fort probable que dans 4 heures, le logo soit le même :). Du coup, l'admin (dans la policy AAM, sur les object .GIF) change l'info de cache dans l'AAM à 5 jours par exemple.
- Et si le logo venait à changer du jour au lendemain (dans la période des 5 jours), l'admin peut révoquer l'ensemble du cache en un clic.
