Il semble que le téléchargement des images dans les oneboxes soit cassé. Peut-être une régression récente due à des modifications dans onebox ou les médias sécurisés. @vinothkannans, pourriez-vous jeter un coup d’œil, s’il vous plaît ?
Exemple : Le oneboxing de https://www.samsung.com/us/mobile/galaxy-z-flip n’affiche pas d’image car l’image est chargée via HTTP.
Le problème est que lors du téléchargement de l’image onebox depuis l’URL « http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg », le fichier est renvoyé au format « .webp » (samsung-logo-191-1.webp). Nous ne pouvons donc pas le télécharger, car le format de fichier « .webp » n’est pas autorisé dans le paramètre de site authorized_extensions.
L’icône de site n’est pas téléchargée car il s’agit d’un fichier « .ico ». Devrions-nous autoriser les fichiers « .ico » dans les oneboxes par défaut ?
Je me demande si le format WebP n’apparaît que parce que l’agent utilisateur Chrome est utilisé 
Je ne pense pas. Il renvoie un fichier webp même lorsque je le télécharge manuellement dans Firefox.
Sur ma version de Firefox (77.0.1 (64 bits) pour macOS), l’en-tête Accept de la requête pour l’URL ci-dessus est :
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
(c’est-à-dire que le navigateur demande une image au format webp, si disponible)
Safari, quant à lui, a un en-tête Accept de :
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
et le serveur web de Samsung renvoie un fichier jpeg. La Onebox s’affiche correctement (avec l’image) dans Safari.
Samsung utilise Akamai Image Manager pour servir ces fichiers.
Si je passe un en-tête Accept avec image/jpeg,image/gif, il retourne bien un image/jpeg, comme prévu.
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 tente de récupérer l’image en appelant FileHelper.download, qui appelle FinalDestination.get, lequel finit par demander le fichier avec 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
Ainsi, si nous demandons la même image avec le même en-tête Accept que ci-dessus, mais en ajoutant cet agent utilisateur, nous obtenons :
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’
Et il retourne un image/webp. Il semble qu’ils ignorent l’en-tête Accept et utilisent leur propre logique pour déterminer le meilleur type de fichier en fonction de l’agent utilisateur.
Apple n’a historiquement pas pris en charge WebP, alors essayons cela :
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’
Succès !
Je pense que l’on peut avancer un argument assez solide selon lequel le serveur web devrait toujours respecter l’en-tête Accept et ne pas essayer de le contourner. D’un autre côté, quelqu’un pourrait dire que si vous présentez une chaîne d’agent utilisateur spécifique, vous devriez être prêt à vous comporter comme cet agent utilisateur (bien que le spoofing d’agent utilisateur ne soit pas rare et ait diverses utilités).
Il se trouve qu’Apple a ajouté la prise en charge de WebP à iOS 14 (sorti récemment) et macOS Big Sur (sorti hier), nous devrions donc probablement le prendre en charge (en l’ajoutant comme extension autorisée par défaut) et en configurant ImageMagick pour le supporter (ce qui introduira une dépendance vers libwebp ou similaire) afin que nous puissions optimiser et redimensionner, etc.
C’est un comportement terrible de la part d’Akami, ouf.
Est-il trivial de modifier notre faux agent utilisateur ? Quoi qu’il en soit, nous ne devrions pas faire semblant d’être Chrome 58, qui a été publié en 2017.
@eviltrout devrait avoir le contexte complet sur la raison pour laquelle Discourse fait semblant et n’utilise pas un agent utilisateur spécial uniquement pour Discourse. De ce que j’ai vaguement en tête, si nous ne jouons pas la comédie, certaines personnes nous empêchent de télécharger des images et des oneboxes. Nous pourrions :
Possiblement, nous pourrions permettre une traduction « transparente » de WebP vers JPEG après le téléchargement du fichier, afin que nous puissions toujours faire le relais pour des images non compatibles si l’opérateur du site ne les prend pas encore totalement en charge. (cela pourrait être utile avec d’autres formats d’image exotiques)
Ou alors, nous passons simplement à autre chose et prenons en charge WebP par défaut en l’ajoutant à tous nos paramètres par défaut ? (Je me demande si ce n’est pas encore trop tôt)
La réponse est malheureusement que de nombreux sites ne servent pas le bon contenu à moins que la requête ressemble à celle d’un navigateur. Je soupçonne que si nous modifions cela, vous constaterez que la plupart des sources fonctionneront bien, mais qu’une ou deux seront étranges.
Le onebox est souvent un grand jeu de whack-a-mole. On corrige un bug, un autre apparaît ailleurs.
Maintenant qu’Apple cède et ajoute la prise en charge dans Safari et iOS, il semble que ce soit le bon moment pour le faire.
Le commit ci-dessus a ajouté la prise en charge des uploads au format .webp.
Après quelques efforts pour forcer le recalcul du message d’origine, il semble que ce problème soit désormais résolu (c’est-à-dire que le logo ‘Samsung’ a été téléchargé et mis en cache localement).
Je pense que ce problème peut être considéré comme résolu.