Похоже, загрузка изображений в onebox сломана. Возможно, это недавний регресс из-за изменений в onebox или secure media. @vinothkannans, не могли бы вы посмотреть?
Пример: Oneboxing https://www.samsung.com/us/mobile/galaxy-z-flip не показывает изображение, потому что оно загружается по HTTP.
Проблема заключается в том, что при загрузке изображения onebox по URL “http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg” возвращается файл в формате “.webp” (samsung-logo-191-1.webp). Поэтому мы не можем его загрузить, так как формат “.webp” не включён в белый список в настройке сайта authorized_extensions.
Иконка сайта (favicon) не загружается, так как это файл формата ".ico``. Стоит ли по умолчанию разрешать файлы ico` в onebox?
Интересно, появляется ли WebP только из-за использования User-Agent Chrome 
Я так не думаю. Он возвращает файл в формате webp, даже когда я вручную скачиваю его в Firefox.
В моей версии Firefox (77.0.1 (64-разрядная) для macOS) заголовок Accept в запросе к указанному выше URL выглядит так:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
(то есть браузер запрашивает формат image/webp, если он доступен)
В Safari, с другой стороны, заголовок Accept имеет вид:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
и веб-сервер Samsung возвращает изображение в формате JPEG. Onebox отображается корректно (с изображением) в Safari.
Samsung использует Akamai Image Manager для обслуживания этих файлов.
Если я передаю заголовок Accept со значением image/jpeg,image/gif, сервер возвращает image/jpeg, как и ожидалось.
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
Resolving image-us.samsung.com (image-us.samsung.com)... 23.217.144.69
Connecting to image-us.samsung.com (image-us.samsung.com)|23.217.144.69|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 83094 (81K) [image/jpeg]
Saving to: 'samsung-logo-191-1.jpg.6'
Discourse пытается загрузить изображение, вызывая FileHelper.download, который вызывает FinalDestination.get, что в конечном итоге запрашивает файл с UserAgent:
Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Таким образом, если мы запросим то же изображение с тем же заголовком Accept, что и выше, но добавим этот User-Agent, мы получим:
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
Resolving image-us.samsung.com (image-us.samsung.com)... 23.217.144.69
Connecting to image-us.samsung.com (image-us.samsung.com)|23.217.144.69|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 45540 (44K) [image/webp]
Saving to: 'samsung-logo-191-1.jpg.10'
И возвращается image/webp. Похоже, что они игнорируют заголовок Accept и используют собственную логику для определения лучшего типа файла на основе User-Agent.
Apple исторически не поддерживала WebP, поэтому давайте попробуем это:
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
Resolving image-us.samsung.com (image-us.samsung.com)... 23.217.144.69
Connecting to image-us.samsung.com (image-us.samsung.com)|23.217.144.69|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 83094 (81K) [image/jpeg]
Saving to: 'samsung-logo-191-1.jpg.16'
Успех!
Я считаю, что можно привести довольно веские доводы в пользу того, что веб-сервер всегда должен уважать заголовок Accept и не пытаться быть «умнее» его. С другой стороны, кто-то может возразить, что если вы предоставляете конкретную строку User-Agent, то должны быть готовы вести себя как этот пользователь (хотя подмена User-Agent не редкость и имеет множество применений).
Как оказалось, Apple добавила поддержку WebP в iOS 14 (выпущен недавно) и MacOS Big Sur (выпущен вчера), поэтому мы, вероятно, должны добавить эту поддержку (добавив её как расширение по умолчанию) и настроить ImageMagick для работы с ней (что потребует зависимости от libwebp или аналогичной библиотеки), чтобы мы могли оптимизировать и изменять размер изображений и т. д.
Это ужасное поведение со стороны Akami, ох.
Легко ли изменить наш поддельный User-Agent? В любом случае, нам не следует притворяться Chrome 58, который был выпущен в 2017 году.
У @eviltrout должна быть полная картина того, почему Discourse притворяется и не использует специальный User-Agent только для Discourse. У меня смутное воспоминание, что если мы не будем притворяться, некоторые сайты будут запрещать нам скачивать изображения и oneboxes. Мы могли бы:
Возможно, мы можем разрешить «прозрачное» преобразование WebP в JPEG после загрузки файла, чтобы мы всё ещё могли проксировать несовместимые изображения, если оператор сайта не обеспечивает полную поддержку. (это может быть полезно для некоторых других экзотических форматов изображений)
Или нам просто двигаться дальше и поддерживать WebP по умолчанию, добавив его во все наши настройки по умолчанию? (Мне интересно, не слишком ли рано)
К сожалению, ответ таков: многие сайты не предоставляют правильный контент, если запрос не выглядит как запрос браузера. Я предполагаю, что если мы изменим это, то обнаружим, что большинство источников будут работать нормально, но один или два могут вести себя странно.
Onebox — это часто большая игра в «бей крота». Исправляешь одну ошибку, а другая появляется в другом месте.
Теперь, когда Apple сдалась и добавила поддержку в Safari и iOS, кажется, что это правильное время для этого.
Вышеуказанный коммит добавил поддержку загрузки файлов .webp.
После некоторых усилий по пересборке оригинального поста, похоже, что эта проблема теперь решена (то есть логотип ‘Samsung’ был загружен/кеширован локально).
Я считаю, что эту проблему можно считать решённой.