La nuova implementazione del service worker di Workbox utilizza UrlHelper.absolute. Poiché si tratta di un asset compilato, memorizza l’URL completo, contenente l’hostname completo dell’host principale in un ambiente multisito.
Penso che dovrebbe utilizzare UrlHelper.local_cdn_url invece. Questo evita anche la necessità di ricompilare gli asset dopo aver modificato l’hostname.
Penso che il consenso generale sia che i Service Worker non dovrebbero mai essere serviti da una CDN:
Ah, quindi intendi i file importScripts? Hai un cluster multisito in cui ogni sito ha un URL CDN diverso?
Sì, importScripts e modulePathPrefix, alle righe 3 e 6 di quel file ERB.
Ma non hai capito completamente. I problemi si verificano dove non c’è alcun CDN in un cluster multisito.
Sia UrlHelper.absolute che UrlHelper.local_cdn_url possono gestire situazioni con e senza CDN.
absolute:
nessun CDN: https://primarysite.ofmultisitecluster.com/javascripts/workbox/workbox-sw.js sbagliato - origine remota per tutti i siti tranne il primario, espone il nome host del cluster primario
cdn: //cdnurl/javascripts/workbox/workbox-sw.js
local_cdn_url:
nessun CDN: /javascripts/workbox/workbox-sw.js corretto - URL relativo
cdn: //cdnurl/javascripts/workbox/workbox-sw.js
quindi quest’ultimo è quello che vogliamo.
Il problema è che quelle righe (3 e 6) non riguardano il file del service worker.
Il service worker proviene dal dominio principale (poiché non può essere servito da una CDN), ma questo service worker importa script in modo lazy a runtime (in questo caso i file della libreria Workbox), che possono invece essere serviti da una CDN.
Quindi il problema è che il tuo cluster multisito non ha una CDN configurata, ed è questo che espone il bug, il quale rimane nascosto quando DISCOURSE_CDN è impostato. Volevo solo sapere perché non ci riguarda.
Hai ragione, ho modificato il mio secondo post per correggere gli errori.
Non riguarda il file del service worker, ma è contenuto all’interno del file del service worker.
Sì, è proprio in quel momento che il bug viene esposto.
Sto solo verificando: la mia diagnosi è corretta e si tratta di un bug che verrà risolto? C’è qualcosa di cui avete bisogno da parte nostra per aiutarvi?
Sì, sembra un bug da correggere. Me ne occuperò questa settimana!
Hmmm, l’ho appena provato su una console Meta:
## Attuale
[1] pry(main)> UrlHelper.absolute("/javascripts/workbox/workbox-sw.js")
=> "https://d3bpeqsaub0i6y.cloudfront.net/javascripts/workbox/workbox-sw.js"
### Modifica proposta
[2] pry(main)> UrlHelper.local_cdn_url("/javascripts/workbox/workbox-sw.js")
=> "/javascripts/workbox/workbox-sw.js"
A mio avviso, queste non sembrano funzioni intercambiabili.
Hai ragione, local_cdn_url sostituisce un URL locale con un URL CDN. E non si tratta nemmeno di un URL locale, ma di uno relativo.
Quindi penso che queste opzioni siano sufficienti al posto delle chiamate UrlHelper?
importScripts("<%= (Discourse.asset_host || '') + '/javascripts/workbox/workbox-sw.js' %>");
e
modulePathPrefix: (Discourse.asset_host || '') + '/javascripts/workbox',
Leggendo l’implementazione corrente di UrlHelper.absolute:
Sembra che componga l’URL concatenando Discourse.base_url_no_prefix con il parametro quando il CDN è nil, che è il tuo caso.
Quindi il problema è che Discourse.base_url_no_prefix restituisce sempre il primo host nell’ambiente multisito?
Analizzando il codice 
il nome della variabile qui, current_hostname alla riga 288, fortemente suggerisce qualcosa di consapevole del multisito 
e da
sembra che lo sia. Per ora siamo a un vicolo cieco…
Cercando altrove, questa rotta ha acquisito una certa “salsa speciale” perché i browser tendono a sollecitarla pesantemente, e non possiamo affidarla a un CDN per farne un problema altrui. Nel farlo, avevamo un bug relativo a una fuoriuscita di dati multisito, che è stato corretto da @sam un anno fa:
C’è la possibilità che il modo in cui stai servendo questo cluster multisito stia memorizzando in cache questa rotta in modo che causi fuoriuscite di dati, come succedeva all’inizio del 2018?
No, il problema è che lo fa durante la precompilazione delle risorse, e questo diventa un problema in ambiente multisito.
Quindi la soluzione è non includere mai il nome dell’host nelle risorse (tranne nel caso di un CDN per le risorse, se impostato, poiché è comunque condiviso tra tutti gli host multisito).
@falco hai visto la mia soluzione proposta due post più sopra?
Sì, ma nei miei test non copre le sottocartelle senza CDN 
Penso che dovremo usare:
"#{Discourse.asset_host}#{Discourse.base_prefix}/javascripts/workbox"
Hmm, buon punto riguardo alla sottocartella.
Ma… Discourse.asset_host può essere nil e non ho mai sentito parlare di Discourse.base_prefix?
Che ne dici di questo:
importScripts("<%= (Discourse.asset_host || GlobalSetting.relative_url_root) + "/javascripts/workbox/workbox-sw.js" %>");
modulePathPrefix: "<%= (Discourse.asset_host || GlobalSetting.relative_url_root) + "/javascripts/workbox" %>",
È esattamente ciò che vogliamo in questo caso:
irb(main):001:0> puts "a#{nil}bc"
abc
Ah, intendevo Discourse.base_path.
Ho appena inviato una correzione, per favore controllala.
Sembra tutto a posto per il nostro caso… grazie!
Ma… solo per essere sicuri… non sono sicuro di come voi gestiate le risorse su un CDN in combinazione con una sottocartella, ma se usate Discourse.asset_host, premete ancora tutte le percorsi sull’host delle risorse con il percorso della sottocartella anche? Perché è esattamente quello che sta facendo il codice ora.
Se è quello che state facendo, allora potete ignorare completamente questo paragrafo 
Tutto questo discorso di sottocartelle + CDN ci ha davvero causato molti problemi. @featheredtoast ha lavorato per razionalizzare la questione e abbiamo dedicato molto tempo a garantire che tutto il nostro codice per la distribuzione delle risorse funzioni correttamente con quelle strane combinazioni di bucket, sottocartelle, ecc.
Penso che siamo al sicuro 
, ma se necessario possiamo riaprire la discussione.
Grazie per la segnalazione del bug!
Questo argomento è stato chiuso automaticamente dopo 7 giorni. Non sono più consentite nuove risposte.