No creo que haya habido cambios recientes en Discourse que hayan provocado esto. Sin embargo, S3 tiene una peculiaridad de larga data con CORS, que puede hacer que las CDN almacenen en caché una versión del recurso sin la cabecera Access-Control-Allow-Origin. Y si se trata de un problema de caché defectuosa, eso podría explicar por qué solo afecta a algunos de tus usuarios (probablemente en función de su ubicación).
Si no recuerdo mal, S3 solo sirve la cabecera Access-Control-Allow-Origin a las solicitudes que envían una cabecera Origin (es decir, aquellas que provienen de un navegador web normal). Cuando se omite Access-Control-Allow-Origin, no sirve Vary: origin en su respuesta. Y así: si la primera solicitud para un recurso dado se envía desde un contexto que no es un navegador web (por ejemplo, curl o algún rastreador web), la CDN puede almacenar en caché la versión sin la cabecera CORS. ¡Muy molesto!
La configuración DISCOURSE_CORS no servirá de nada aquí. Solo es relevante para el servidor de aplicaciones, no para S3.
En nuestro alojamiento, evitamos este problema configurando Cloudfront para que agregue Access-Control-Allow-Origin: * a todas las respuestas. Eso asegura que el comportamiento extraño de S3 no pueda causar que se almacene un resultado incorrecto en caché.
Alternativamente, podrías configurar Cloudfront para incluir la cabecera de solicitud Origin en su clave de caché, lo que mantendría separadas las respuestas sin CORS de las respuestas con CORS.
Amazon tiene un montón de documentación sobre CORS aquí. Tenía este enlace en mis notas, que aparentemente era un hilo de foro sobre exactamente este problema… pero parece que lo eliminaron ![]()