La nouvelle implémentation du service worker workbox utilise UrlHelper.absolute. Comme il s’agit d’une ressource compilée, elle stocke l’URL complète, contenant le nom de domaine complet de l’hôte principal dans un environnement multisite.
Je pense qu’il faudrait utiliser UrlHelper.local_cdn_url à la place. Cela permet également d’éviter de devoir recompiler les ressources après avoir modifié le nom de domaine.
Je pense que le consensus général est que les Service Workers ne devraient jamais être servis via un CDN :
Ah, vous voulez dire les fichiers importScripts ? Avez-vous un cluster multi-sites où chaque site a une URL CDN différente ?
Oui, importScripts et modulePathPrefix, aux lignes 3 et 6 de ce fichier ERB.
Mais vous ne me comprenez pas entièrement. Les problèmes surviennent là où il n’y a pas de CDN dans un cluster multisite.
Les deux UrlHelper.absolute et UrlHelper.local_cdn_url peuvent gérer les situations avec et sans CDN.
absolute :
sans CDN : https://primarysite.ofmultisitecluster.com/javascripts/workbox/workbox-sw.js **mauvais - origine distante pour tous les sites sauf le principal, exposant le nom d’hôte du cluster principal **
avec CDN : //cdnurl/javascripts/workbox/workbox-sw.js
local_cdn_url :
sans CDN : /javascripts/workbox/workbox-sw.js **bon - URL relative **
avec CDN : //cdnurl/javascripts/workbox/workbox-sw.js
donc c’est cette dernière option que nous voulons.
Le problème, c’est que ces lignes (3 et 6) ne concernent pas le fichier du service worker.
Le service worker provient du domaine de base (car il ne peut pas être servi via un CDN), mais ce service worker importe de manière paresseuse des scripts au moment de l’exécution (dans ce cas, les fichiers de la bibliothèque Workbox), lesquels peuvent être servis via un CDN.
Le problème vient donc du fait que votre cluster multisite n’a pas de CDN configuré, ce qui expose ce bug, alors qu’il est masqué lorsque DISCOURSE_CDN est défini. Je voulais simplement savoir pourquoi cela ne nous affecte pas.
Vous avez raison, j’ai édité mon deuxième message pour corriger mes erreurs.
Il ne s’agit pas du fichier du service worker, mais bien de ce qui se trouve dans ce fichier.
Oui, c’est exactement à ce moment-là que le bug est exposé.
Juste pour vérifier : mon diagnostic est-il correct et s’agit-il d’un bug qui sera corrigé ? Y a-t-il quelque chose dont vous auriez besoin de notre part pour nous aider ?
Oui, cela ressemble à un bug qu’il faut corriger. Je m’en occuperai cette semaine !
Hmmm, je viens de tester cela dans une console Meta :
## Actuel
[1] pry(main)> UrlHelper.absolute("/javascripts/workbox/workbox-sw.js")
=> "https://d3bpeqsaub0i6y.cloudfront.net/javascripts/workbox/workbox-sw.js"
### Modification proposée
[2] pry(main)> UrlHelper.local_cdn_url("/javascripts/workbox/workbox-sw.js")
=> "/javascripts/workbox/workbox-sw.js"
Ces fonctions ne me semblent pas interchangeables.
Vous avez raison, local_cdn_url remplace une URL locale par une URL CDN. Et ce n’est même pas une URL locale, mais une URL relative.
Je pense donc que cela suffirait à la place de ces appels UrlHelper ?
importScripts("<%= (Discourse.asset_host || '') + '/javascripts/workbox/workbox-sw.js' %>");
et
modulePathPrefix: (Discourse.asset_host || '') + '/javascripts/workbox',
En lisant l’implémentation actuelle de UrlHelper.absolute :
On dirait qu’elle compose l’URL en concaténant Discourse.base_url_no_prefix avec le paramètre lorsque le CDN est nil, ce qui est votre cas.
Donc, le problème est que Discourse.base_url_no_prefix renvoie toujours le premier hôte dans un environnement multisite ?
En examinant le code 
le nom de la variable ici, current_hostname à la ligne 288, suggère fortement une prise en compte du multisite 
et par
on dirait bien que c’est le cas. Pour l’instant, c’est une impasse…
En cherchant ailleurs, cette route a reçu une attention particulière car les navigateurs ont tendance à la solliciter intensément, et nous n’avons pas le droit de la placer sur un CDN pour en faire le problème de quelqu’un d’autre. En faisant cela, nous avions un bug impliquant une fuite multisite, qui a été corrigé par @sam il y a un an :
Existe-t-il une possibilité que la manière dont vous servez ce cluster multisite mette en cache cette route de façon fuiteuse, comme c’était le cas au début de 2018 ?
Non, le problème est qu’il le fait lors de la précompilation des ressources, ce qui pose problème en environnement multisite.
La solution consiste donc à ne jamais inclure le nom d’hôte dans les ressources (sauf pour un CDN de ressources, s’il est configuré, car il est de toute façon partagé entre les hôtes multisite).
@falco as-tu vu ma solution proposée deux messages au-dessus de celui-ci ?
Oui, mais dans mes tests, cela ne couvre pas les sous-dossiers sans CDN 
Je pense que nous devrons utiliser :
"#{Discourse.asset_host}#{Discourse.base_prefix}/javascripts/workbox"
Hmm, bonne remarque concernant le sous-dossier.
Mais… Discourse.asset_host peut être nil et je n’ai jamais entendu parler de Discourse.base_prefix ?
Que diriez-vous de ceci :
`importScripts("<%= (Discourse.asset_host || GlobalSetting.relative_url_root) + “/javascripts/workbox/workbox-sw.js” %>);
modulePathPrefix: "<%= (Discourse.asset_host || GlobalSetting.relative_url_root) + "/javascripts/workbox" %>",
C’est exactement ce que nous voulons dans ce cas :
irb(main):001:0> puts "a#{nil}bc"
abc
Ah, je voulais dire Discourse.base_path.
J’ai tout juste commis une correction, veuillez la vérifier.
Cela semble correct pour notre cas… merci !
Mais… juste pour être sûr… je ne suis pas sûr de la façon dont vous gérez les ressources sur un CDN en combinaison avec un sous-dossier, mais si vous utilisez Discourse.asset_host, préfixez-vous toujours tous les chemins sur le serveur de ressources avec le chemin du sous-dossier également ? Parce que c’est ce que fait le code actuellement.
Si c’est bien ce que vous faites, vous pouvez ignorer complètement ce paragraphe 
Tout ce système de sous-dossier + CDN nous a effectivement causé pas mal de problèmes. @featheredtoast a travaillé à simplifier cela, et nous avons passé beaucoup de temps à nous assurer que tout notre code de diffusion des ressources fonctionne correctement avec ces combinaisons étranges de buckets, sous-dossiers, etc.
Je pense que nous sommes à l’abri 
, mais si nécessaire, nous pouvons rouvrir ce ticket.
Merci pour le signalement du bug !
Ce sujet a été automatiquement fermé après 7 jours. De nouvelles réponses ne sont plus autorisées.