Éviter les problèmes de mise en cache HTTP lors de la mise à niveau d’applications ASP.NET Core Blazor

Lorsque les applications Blazor ne sont pas correctement mises à niveau ou configurées, cela peut entraver la fluidité des mises à niveau pour les utilisateurs existants. Cet article décrit certains des problèmes courants de mise en cache HTTP qui peuvent se produire lors de la mise à niveau d’applications Blazor entre des versions principales. Il fournit également certaines actions recommandées pour garantir une transition fluide pour vos utilisateurs.

Bien que les futures versions de Blazor puissent fournir de meilleures solutions pour traiter les problèmes de mise en cache HTTP, il revient finalement à l’application de configurer correctement la mise en cache. Une configuration de mise en cache appropriée garantit que les utilisateurs de l’application disposent toujours de la version la plus récente de l’application, ce qui améliore leur expérience et réduit la probabilité de rencontrer des erreurs.

Les problèmes courants qui ont un impact négatif sur l’expérience de mise à niveau de l’utilisateur sont les suivants :

• Gestion incorrecte des mises à jour de projets et de packages : cela se produit si vous ne mettez pas à jour tous les projets déployés de l’application pour qu’ils utilisent la même version principale du framework ou si vous utilisez des packages d’une version précédente lorsqu’une version plus récente est disponible dans le cadre de la mise à niveau majeure.
• Configuration incorrecte des en-têtes de mise en cache : les en-têtes de mise en cache HTTP contrôlent comment, où et pendant combien de temps les réponses de l’application sont mises en cache. Si les en-têtes ne sont pas configurés correctement, les utilisateurs peuvent recevoir du contenu obsolète.
• Configuration incorrecte d’autres couches : les réseaux de distribution de contenu (CDN) et d’autres couches de l’application déployée peuvent entraîner des problèmes s’ils sont mal configurés. Par exemple, les CDN sont conçus pour mettre en cache et fournir du contenu afin d’améliorer les performances et de réduire la latence. Si un CDN sert incorrectement des versions mises en cache des ressources, cela peut entraîner une remise de contenu obsolète à l’utilisateur.

Détecter et diagnostiquer les problèmes de mise à niveau

Les problèmes de mise à niveau apparaissent généralement comme un échec de démarrage de l’application dans le navigateur. Normalement, un avertissement indique la présence d’une ressource obsolète ou d’une ressource manquante ou incohérente avec l’application.

• Tout d’abord, vérifiez si l’application se charge correctement dans une instance de navigateur propre. Utilisez un mode de navigateur privé pour charger l’application, par exemple en mode InPrivate Microsoft Edge ou en mode Incognito Google Chrome. Si l’application ne parvient pas à charger, cela signifie probablement qu’un ou plusieurs packages n’ont pas été correctement mis à jour ou que l’infrastructure n’a pas correctement été mise à jour.
• Si l’application se charge correctement dans une instance de navigateur propre, il est probable que l’application soit traitée à partir d’un cache obsolète. Dans la plupart des cas, une actualisation forcée du navigateur avec Ctrl+F5 vide le cache, ce qui permet à l’application de charger et de s’exécuter avec les dernières ressources.
• Si l’application continue d’échouer, il est probable qu’un cache CDN obsolète serve l’application. Essayez de vider le cache DNS via le mécanisme proposé par votre fournisseur CDN.

Actions recommandées avant une mise à niveau

Le processus précédent de service de l’application peut rendre le processus de mise à jour plus difficile. Par exemple, avoir évité ou mal utilisé des en-têtes de mise en cache par le passé peut entraîner des problèmes actuels de mise en cache pour les utilisateurs. Vous pouvez effectuer les actions décrites dans les sections suivantes pour atténuer le problème et améliorer le processus de mise à niveau pour les utilisateurs.

Aligner les packages d’infrastructure avec la version du framework

Assurez-vous que les packages d’infrastructure correspondent à la version du framework. L’utilisation de packages à partir d’une version précédente lorsqu’une version plus récente est disponible peut entraîner des problèmes de compatibilité. Il est également important de s’assurer que tous les projets déployés de l’application utilisent la même version principale du framework. Cette cohérence permet d’éviter un comportement ou des erreurs inattendus.

Vérifier la présence d’en-têtes de mise en cache corrects

Les en-têtes de mise en cache corrects doivent être présents sur les réponses aux demandes de ressources. Cela inclut ETag, Cache-Control et d’autres en-têtes de mise en cache. La configuration de ces en-têtes dépend du service d’hébergement ou de la plateforme de serveur d’hébergement. Ils sont particulièrement importants pour les ressources telles que le script Blazor (blazor.webassembly.js) et tout ce que le script télécharge.

Des en-têtes de mise en cache HTTP incorrects peuvent également avoir un impact sur les workers de service. Les workers de service s’appuient sur la mise en cache des en-têtes pour gérer efficacement les ressources mises en cache. Par conséquent, les en-têtes incorrects ou manquants peuvent perturber la fonctionnalité du worker de service.

Utiliser Clear-Site-Data pour supprimer l’état dans le navigateur

Envisagez d’utiliser l’en-tête Clear-Site-Data pour supprimer l’état dans le navigateur.

En règle générale, la source des problèmes d’état du cache est limitée au cache du navigateur HTTP. L’utilisation de la directive cache doit donc être suffisante. Cette action peut vous aider à vous assurer que le navigateur récupère les ressources les plus récentes du serveur, plutôt que de servir du contenu obsolète à partir du cache.

Vous pouvez éventuellement inclure la directive storage pour effacer les caches de stockage locaux en même temps que vous effacez le cache du navigateur HTTP. Toutefois, les applications qui utilisent le stockage client peuvent rencontrer une perte d’informations importantes si la directive storage est utilisée.

Ajouter une chaîne de requête à la balise de script Blazor

Si aucune des actions recommandées précédentes n’est efficace ou utilisable pour votre déploiement, ou qu’elles ne peuvent être appliquées à votre application, envisagez d’ajouter temporairement une chaîne de requête à la source de balise <script> du script Blazor. Dans la plupart des cas, cette action devrait suffire à obliger le navigateur à contourner le cache HTTP local et à télécharger une nouvelle version de l’application. Il n’est pas nécessaire de lire ou d’utiliser la chaîne de requête dans l’application.

Dans l’exemple suivant, la chaîne de requête temporaryQueryString=1 est temporairement appliquée à l’URI source externe relative de la balise <script> :

<script src="_framework/blazor.webassembly.js?temporaryQueryString=1"></script>

Une fois que tous les utilisateurs de l’application ont rechargé l’application, la chaîne de requête peut être supprimée.

Vous pouvez également appliquer une chaîne de requête persistante avec le contrôle de version approprié. L’exemple suivant suppose que la version de l’application correspond à la version de publication .NET (8 pour .NET 8) :

<script src="_framework/blazor.webassembly.js?version=8"></script>

Pour connaître l’emplacement de la balise <script> du script Blazor, consultez ASP.NET Core Blazor structure du projet.