Non credo che ci siano state modifiche recenti a Discourse che possano aver causato questo problema. Tuttavia, S3 ha una nota stranezza di lunga data con CORS, che può causare ai CDN di memorizzare nella cache una versione dell’asset priva dell’intestazione Access-Control-Allow-Origin. E se si tratta di un problema di cache errata, ciò potrebbe spiegare perché l’impatto si riscontra solo su alcuni dei vostri utenti (probabilmente in base alla loro posizione).
Se non ricordo male, S3 fornisce l’intestazione Access-Control-Allow-Origin solo alle richieste che inviano un’intestazione Origin (cioè quelle provenienti da un normale browser web). Quando Access-Control-Allow-Origin viene omesso, S3 non fornisce Vary: origin nella sua risposta. E quindi: se la prima richiesta per un determinato asset viene inviata da un contesto non browser (ad esempio curl o un crawler web), il CDN può memorizzare nella cache la versione priva dell’intestazione CORS. Molto fastidioso!
L’impostazione DISCOURSE_CORS non sarà di alcun aiuto in questo caso. È rilevante solo per il server dell’applicazione, non per S3.
Nel nostro hosting, aggiriamo questo problema configurando Cloudfront per aggiungere Access-Control-Allow-Origin: * a tutte le risposte. Ciò garantisce che il comportamento bizzarro di S3 non possa causare la memorizzazione nella cache di un risultato errato.
In alternativa, è possibile configurare Cloudfront per includere l’intestazione di richiesta Origin nella chiave di cache, il che manterrebbe separate le risposte non-CORS da quelle CORS.
Amazon ha un’ampia documentazione su CORS qui. Avevo questo link nei miei appunti, che apparentemente era un thread del forum su esattamente questo problema… ma sembra che lo abbiano eliminato ![]()