Parece que o download de imagens em oneboxes está quebrado. Talvez seja uma regressão recente devido a alterações no onebox ou na mídia segura. @vinothkannans, você poderia dar uma olhada, por favor?
Exemplo: Oneboxing https://www.samsung.com/us/mobile/galaxy-z-flip não mostra uma imagem porque a imagem é carregada via HTTP.
O problema é que, ao baixar a imagem onebox da URL http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg, o arquivo é retornado no formato .webp (samsung-logo-191-1.webp). Portanto, não conseguimos baixá-lo, pois o formato .webp não está na lista branca da configuração do site authorized_extensions.
O favicon não é baixado porque é um arquivo .ico. Devemos permitir arquivos ico em oneboxes por padrão?
Será que o WebP só aparece por causa do uso do user agent do Chrome? 
Não acho que seja. Está retornando um arquivo webp mesmo quando eu faço o download manualmente no Firefox.
Na minha versão do Firefox (77.0.1 (64-bit) para MacOS), o cabeçalho Accept na solicitação para a URL acima é:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
(ou seja, o navegador está solicitando uma imagem webp, se disponível)
Já o Safari, por outro lado, possui um cabeçalho Accept de:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
e o servidor web da Samsung retorna um jpeg. O Onebox é exibido corretamente (com a imagem) no Safari.
A Samsung está usando o Akamai Image Manager para servir esses arquivos.
Se eu passar um cabeçalho Accept com image/jpeg,image/gif, ele retorna image/jpeg, como esperado.
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'
O Discourse tenta buscar a imagem chamando FileHelper.download, que chama FinalDestination.get, o qual, por fim, solicita o arquivo com um 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
Portanto, se solicitarmos a mesma imagem com o mesmo cabeçalho Accept acima, mas adicionando esse user agent, obtemos:
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'
E ele retorna um image/webp. Parece que eles estão ignorando o cabeçalho Accept e usando sua própria lógica para determinar o melhor tipo de arquivo com base no user agent.
A Apple não suportou o WebP historicamente, então vamos testar isso:
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'
Sucesso!
Acho que podemos fazer um argumento bastante sólido de que o servidor web deve sempre respeitar o cabeçalho Accept e não tentar ser mais esperto que ele. Por outro lado, alguém poderia argumentar que, se você apresenta uma string de user agent específica, deve estar preparado para agir como esse user agent (embora a falsificação de user agent não seja incomum e tenha vários usos).
Como acontece, a Apple adicionou suporte ao WebP no iOS 14 (lançado recentemente) e no macOS Big Sur (lançado ontem), então provavelmente devemos suportar isso (adicionando-o como uma extensão permitida padrão) e configurando o ImageMagick para suportá-lo (o que introduzirá uma dependência do libwebp ou similar) para que possamos otimizar e redimensionar, etc.
Isso é um comportamento terrível por parte da Akami, uau.
É trivial mudar nosso user agent fictício? De qualquer forma, não deveríamos estar fingindo ser o Chrome 58, que foi lançado em 2017.
@eviltrout deve ter todo o contexto sobre por que o Discourse finge e não usa um User Agent especial apenas para o Discourse. Minha lembrança vaga é que, se não fingirmos, algumas pessoas nos impedem de baixar imagens e oneboxes. Poderíamos:
Possivelmente, podemos permitir a tradução “transparente” de WebP para JPEG após o download do arquivo, para que ainda possamos fazer proxy de imagens incompatíveis se o operador do site não oferecer suporte total. (isso poderia ser útil com alguns outros formatos de imagem esotéricos)
Ou simplesmente seguimos em frente e damos suporte ao WebP por padrão, adicionando-o a todas as nossas configurações padrão? (Me pergunto se é cedo demais)
A resposta, infelizmente, é que muitos sites não servem o conteúdo correto a menos que a solicitação pareça vir de um navegador. Suspeito que, se mudarmos isso, a maioria das fontes funcionará bem, mas uma ou duas apresentarão problemas estranhos.
O onebox é frequentemente um grande jogo de “batata quente”. Corrigimos um bug e outro surge em outro lugar.
Agora que a Apple cedeu e adicionou suporte ao Safari e ao iOS, parece ser o momento certo para fazer isso.
O commit acima adicionou suporte para uploads em .webp.
Após alguns esforços para fazer o post original ser reprocessado, parece que esse problema foi resolvido (ou seja, o logotipo ‘Samsung’ foi baixado/armazenado em cache localmente).
Acho que esse problema pode ser considerado resolvido.