Es sieht so aus, als wäre das Herunterladen von Bildern in Oneboxes defekt. Möglicherweise liegt eine kürzliche Regression aufgrund von Änderungen in Onebox oder Secure Media vor. @vinothkannans Könntest du das bitte prüfen?
Beispiel: Beim Oneboxen von https://www.samsung.com/us/mobile/galaxy-z-flip wird kein Bild angezeigt, da die Bilder über HTTP geladen werden.
Das Problem besteht darin, dass beim Herunterladen des Onebox-Bildes von der URL „http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
Ich frage mich, ob WebP nur aufgrund der Verwendung des Chrome-User-Agents kommt 
Das glaube ich nicht. Es wird auch dann eine WebP-Datei zurückgegeben, wenn ich sie manuell in Firefox herunterlade.
In meiner Firefox-Version (77.0.1 (64-Bit) für macOS) lautet der Accept-Header in der Anfrage für die oben genannte URL:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
(d. h. der Browser fragt nach einem image/webp, falls verfügbar)
Safari hingegen hat einen Accept-Header von:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
und der Samsung-Webserver liefert ein JPEG zurück. Die Onebox wird in Safari korrekt angezeigt (mit dem Bild).
Samsung verwendet Akamai Image Manager, um diese Dateien auszuliefern.
Wenn ich einen Accept-Header mit dem Wert image/jpeg,image/gif sende, wird wie erwartet ein image/jpeg zurückgegeben.
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 versucht, das Bild abzurufen, indem es FileHelper.download aufruft, was wiederum FinalDestination.get aufruft, welches letztendlich die Datei mit einem UserAgent anfordert:
Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Wenn wir also dasselbe Bild mit demselben Accept-Header wie oben anfordern, aber diesen User-Agent hinzufügen, erhalten wir:
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'
Es wird ein image/webp zurückgegeben. Es scheint, als würden sie den Accept-Header ignorieren und ihre eigene Logik verwenden, um den besten Dateityp basierend auf dem User-Agent zu bestimmen.
Apple hat WebP historisch nicht unterstützt, also probieren wir das aus:
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'
Erfolg!
Ich denke, man kann ein ziemlich starkes Argument dafür anführen, dass der Webserver den Accept-Header immer respektieren und nicht versuchen sollte, ihn zu überlisten. Andererseits könnte man argumentieren, dass man, wenn man eine bestimmte User-Agent-Zeichenfolge übermittelt, bereit sein sollte, sich wie dieser User-Agent zu verhalten (obwohl User-Agent-Spoofing nicht ungewöhnlich ist und verschiedene Verwendungszwecke hat).
Tatsächlich hat Apple WebP-Unterstützung hinzugefügt in iOS 14 (vor kurzem veröffentlicht) und macOS Big Sur (gestern veröffentlicht), also sollten wir das wahrscheinlich unterstützen (indem wir es als standardmäßig erlaubte Erweiterung hinzufügen) und ImageMagick so konfigurieren, dass es WebP unterstützt (was eine Abhängigkeit von libwebp oder Ähnlichem einführt), damit wir optimieren und die Größe ändern usw. können.
Das ist ein schreckliches Verhalten von Akami, oh je.
Ist es trivial, unseren vorgetäuschten User-Agent zu ändern? Unabhängig davon sollten wir uns nicht so verhalten, als wären wir Chrome 58, das 2017 veröffentlicht wurde.
@eviltrout sollte den vollständigen Kontext dazu haben, warum Discourse sich so verhält und keinen speziellen User-Agent nur für Discourse verwendet. Meine vage Erinnerung ist, dass uns manche Leute das Herunterladen von Bildern und Oneboxes verwehren, wenn wir uns nicht so verhalten. Wir könnten:
Möglicherweise können wir eine „transparente
Die Antwort ist leider, dass viele Seiten den richtigen Inhalt nicht ausliefern, es sei denn, die Anfrage sieht nach einem Browser aus. Ich vermute, wenn wir das ändern, wird die meisten Quellen problemlos funktionieren, aber ein oder zwei werden seltsam sein.
Onebox ist oft ein großes Spiel von „Whack-a-Mole“. Man behebt einen Fehler, und ein anderer taucht woanders wieder auf.
Da Apple nachgibt und Unterstützung für Safari und iOS hinzufügt, scheint dies der richtige Zeitpunkt dafür zu sein.
Der obige Commit hat Unterstützung für .webp-Uploads hinzugefügt.
Nach etwas Hin und Her, um den ursprünglichen Beitrag neu zu rendern, scheint dieses Problem nun behoben zu sein (d. h. das ‘Samsung’-Logo wurde lokal heruntergeladen/gecachet).
Ich denke, dieses Problem kann als gelöst betrachtet werden.