Application inaccessible via Chrome

4.0
Application inaccessible via Chrome
0
Tags: #<Tag:0x00007f5ff82d2558>
#1

depuis ce matin (passage à la P23 ?), je ne peux plus accéder à une application en utilisant chrome.
ça fonctionne sur firefox et ie …

(David AZOULAY) #2

Il faudrait essayer de fermer chrome et recommencer

Si ça ne suffit pas il faut essayer de vider le cache chrome et recommencer

Etc

(François Genestin) #3

Ca sent effectivement un problème cache navigateur.

(Bruno Montagnac) #4

Bonjour, je confirme que de notre côté, nous avons eu de nombreuses remontées utilisateurs qui indiquaient ne plus pouvoir accéder à notre instance (intranet Renault) suite à l’upgrade P23. La résolution du problème pouvait requérir un simple rechargement de la page /ui par Ctrl-F5 voire dans certains cas de vider tout le cache de Chrome (navigateur standard Alliance). Je n’ai effectivement pas rencontré le problème sur Firefox (utilisé uniquement à des fins de tests) et IE est indiqué chez nous comme déprécié / ne plus utiliser.

(François Genestin) #5

Oui, merci Bruno, c’est tout le problème de la stratégie de gestion de cache des ressource statiques lors des livraisons.

  • Au pire : no cache = on envoie toutes les ressources tout le temps : à éviter puisqu’on livre tous les N mois, lenteur + volumétrie inutile
  • A mieux : usage du cache navigateur entre 2 livraisons de socle

A date le compromis est que les ressources expirent/se rechargent après un jour. Mais visiblement ça ne sert à rien, il faut nécessairement un CTRL+F5 puisque les mises en production ne coïncident jamais avec la date d’expiration du cache.

La seule solution que je vois pour éviter ce problème suite à mise en production est de mettre la version “4.0.Pxx” (ou mieux la date de build, puisque un master P24 change tous les jours) dans l’URL de toutes les ressources statiques, pour que Chrome soit contraint d’aller les chercher en cas de montée de version du socle.

(David AZOULAY) #6

Plutôt la révision Git que la date de build

(David AZOULAY) #7

En fait toutes les resources dynamiques servies par Simplicité on une date d’expiration de cache explicite.

Les resources statiques servies par Tomcat n’ont, elles, visiblement pas de date d’expiration de cache, donc le navigateur fait comme il veut…

Dans le web.xml de notre webapp on à ça en commentaire:

	<!-- Expires management on static JS/CSS/images
	<filter>
		<filter-name>ExpiresFilter</filter-name>
		<filter-class>org.apache.catalina.filters.ExpiresFilter</filter-class>
		<init-param>
			<param-name>ExpiresByType image</param-name>
			<param-value>access plus 1 hour</param-value>
		</init-param>
		<init-param>
			<param-name>ExpiresByType text/css</param-name>
			<param-value>access plus 1 hour</param-value>
		</init-param>
		<init-param>
			<param-name>ExpiresByType application/javascript</param-name>
			<param-value>access plus 1 hour</param-value>
		</init-param>
	</filter>
	<filter-mapping>
		<filter-name>ExpiresFilter</filter-name>
		<url-pattern>/*</url-pattern>
		<dispatcher>REQUEST</dispatcher>
	</filter-mapping>
	-->

Peut être faudrait il l’activer…

(François Genestin) #8

Peu importe du moment que :

  • ce soit un identifiant unique du build/version
  • pas trop long car sera dans toutes les URL
  • et donc accessible dans les Globals pour le faire à la volée (pas de requete Git ou autre)
(David AZOULAY) #9

La révision Git correspond bien à ces contraintes (quite à ne prendre que les 8 1ers caractères)

Mais je pense que la piste de config Tomcat (cf. mon post précédent) est à creuser/tester d’abord.