Parece que la descarga de imágenes en oneboxes está rota. Tal vez sea una regresión reciente debido a cambios en onebox o en los medios seguros. @vinothkannans ¿Podrías echar un vistazo, por favor?
Ejemplo: Al oneboxear https://www.samsung.com/us/mobile/galaxy-z-flip no se muestra ninguna imagen porque las imágenes se cargan a través de HTTP.
El problema es que, al descargar la imagen de onebox desde la URL “http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg”, el servidor devuelve el archivo en formato “.webp” (samsung-logo-191-1.webp). Por lo tanto, no podemos descargarlo ya que el formato “.webp” no está incluido en la lista blanca de la configuración del sitio authorized_extensions.
El favicon no se descarga porque es un archivo “.ico”. ¿Deberíamos permitir archivos “ico” en los oneboxes de forma predeterminada?
Me pregunto si WebP solo aparece debido al uso del agente de usuario de Chrome 
No creo. Incluso cuando lo descargo manualmente en Firefox, devuelve un archivo webp.
En mi versión de Firefox (77.0.1 (64-bit) para MacOS), el encabezado Accept en la solicitud para la URL anterior es:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
(es decir, el navegador solicita una imagen en formato webp, si está disponible)
Safari, por otro lado, tiene un encabezado Accept de:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
y el servidor web de Samsung devuelve un archivo jpeg. El Onebox se muestra correctamente (con la imagen) en Safari.
Samsung está utilizando Akamai Image Manager para servir estos archivos.
Si envío una cabecera Accept con image/jpeg,image/gif, devuelve image/jpeg, como era de esperar.
wget --header="Accept: image/jpeg,image/gif" http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
--2020-11-13 11:43:58-- http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
Resolviendo image-us.samsung.com (image-us.samsung.com)... 23.217.144.69
Conectando con image-us.samsung.com (image-us.samsung.com)|23.217.144.69|:80... conectado.
Solicitud HTTP enviada, esperando respuesta... 200 OK
Longitud: 83094 (81K) [image/jpeg]
Guardando en: ‘samsung-logo-191-1.jpg.6’
Discourse intenta descargar la imagen llamando a FileHelper.download, que llama a FinalDestination.get, el cual finalmente solicita el archivo con un UserAgent de:
Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Por lo tanto, si solicitamos la misma imagen con la misma cabecera Accept que antes, pero añadiendo ese agente de usuario, obtenemos:
wget --header="Accept: image/jpeg,image/gif" --header="User-Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36" http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
--2020-11-13 11:52:50-- http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
Resolviendo image-us.samsung.com (image-us.samsung.com)... 23.217.144.69
Conectando con image-us.samsung.com (image-us.samsung.com)|23.217.144.69|:80... conectado.
Solicitud HTTP enviada, esperando respuesta... 200 OK
Longitud: 45540 (44K) [image/webp]
Guardando en: ‘samsung-logo-191-1.jpg.10’
Y devuelve image/webp. Parece que están ignorando la cabecera Accept y utilizando su propia lógica para determinar el mejor tipo de archivo según el agente de usuario.
Históricamente, Apple no ha soportado WebP, así que probemos eso:
wget --header="Accept: image/jpeg,image/gif" --header="User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15" http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
--2020-11-13 12:27:02-- http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
Resolviendo image-us.samsung.com (image-us.samsung.com)... 23.217.144.69
Conectando con image-us.samsung.com (image-us.samsung.com)|23.217.144.69|:80... conectado.
Solicitud HTTP enviada, esperando respuesta... 200 OK
Longitud: 83094 (81K) [image/jpeg]
Guardando en: ‘samsung-logo-191-1.jpg.16’
¡Éxito!
Creo que se puede argumentar con bastante firmeza que el servidor web siempre debería respetar la cabecera Accept y no intentar ser más listo que ella. Por otro lado, alguien podría argumentar que si presentas una cadena específica de agente de usuario, deberías estar preparado para actuar como ese agente de usuario (aunque la suplantación de agente de usuario no es infrecuente y tiene diversos usos).
Como resultado, Apple ha añadido soporte para WebP en iOS 14 (lanzado recientemente) y macOS Big Sur (lanzado ayer), por lo que probablemente deberíamos soportarlo (añadiéndolo como una extensión permitida por defecto) y configurando ImageMagick para que lo soporte (lo cual introducirá una dependencia de libwebp o similar) para poder optimizar y redimensionar, etc.
Eso es un comportamiento terrible por parte de Akami, ¡uf!
¿Es trivial cambiar nuestro agente de usuario ficticio? De todos modos, no deberíamos estar fingiendo ser Chrome 58, que fue lanzado en 2017.
@eviltrout debería tener todo el contexto sobre por qué Discourse finge y no utiliza un agente de usuario especial solo para Discourse. Mi recuerdo vago es que si no fingimos, algunas personas nos niegan la descarga de imágenes y oneboxes. Podríamos:
Posiblemente, podríamos permitir la traducción “transparente” de WebP a JPEG después de la descarga del archivo, para que aún podamos actuar como proxy de imágenes no compatibles si el operador del sitio no ofrece soporte completo (esto podría ser útil con otros formatos de imagen esotéricos).
O simplemente seguimos adelante y admitimos WebP de forma predeterminada, agregándolo a todas nuestras configuraciones predeterminadas? (Me pregunto si es demasiado pronto).
La respuesta es que, lamentablemente, muchos sitios no sirven el contenido correcto a menos que la solicitud parezca provenir de un navegador. Sospecho que si cambiamos esto, encontrarás que la mayoría de las fuentes funcionarán bien, pero una o dos serán extrañas.
Onebox suele ser un gran juego de «matar topos». Arreglas un error y otro aparece en otro lugar.
Ahora que Apple está cediendo y añadiendo soporte en Safari e iOS, parece el momento adecuado para hacerlo.
El commit anterior agregó soporte para cargas de archivos .webp.
Después de varios trámites para que el mensaje original se volviera a procesar, parece que este problema ya está resuelto (es decir, el logotipo de ‘Samsung’ se ha descargado y almacenado en caché localmente).
Considero que este problema puede darse por resuelto.