onebox 内の画像のダウンロードが壊れているようです。onebox またはセキュアメディアの変更による最近のリグレッションかもしれません。@vinothkannans 確認をお願いします。
例:https://www.samsung.com/us/mobile/galaxy-z-flip を onebox しても画像が表示されません。これは画像が HTTP で読み込まれているためです。
onebox 内の画像のダウンロードが壊れているようです。onebox またはセキュアメディアの変更による最近のリグレッションかもしれません。@vinothkannans 確認をお願いします。
例:https://www.samsung.com/us/mobile/galaxy-z-flip を onebox しても画像が表示されません。これは画像が HTTP で読み込まれているためです。
問題は、URL “http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg” から onebox 画像をダウンロードする際、ファイルが “.webp” 形式(samsung-logo-191-1.webp)で返されてしまうことです。そのため、当サイトの authorized_extensions 設定で “.webp” 形式がホワイトリストに登録されていないため、ダウンロードできません。
また、ファビコンは “.ico” ファイルであるためダウンロードされません。onebox で “ico” ファイルをデフォルトで許可すべきでしょうか?
WebP が Chrome のユーザーエージェントの使用によるものだけなのか気になります🤔
いいえ、そうではないと思います。Firefoxで手動でダウンロードしても、webpファイルが返ってきます。
私の Firefox のバージョン(MacOS 用 77.0.1 (64 ビット))では、上記の URL に対するリクエストの Accept ヘッダーは以下の通りです。
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 を使用しています。
image/jpeg,image/gif という Accept ヘッダーを渡すと、期待通り 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'
成功しました!
Web サーバーは常に Accept ヘッダーを尊重し、それを無視して賢く振る舞おうとすべきではないという強い主張ができると思います。一方で、特定の User-Agent 文字列を提示する場合は、その User-Agent のように振る舞う準備ができているべきだという意見もあるかもしれません(ただし、User-Agent のスプーフィングは一般的ではなく、様々な用途に使われています)。
実際、Apple は iOS 14(最近リリース)と macOS Big Sur(昨日リリース)で WebP サポートを追加 しました。したがって、WebP をサポートするべきでしょう(デフォルトで許可する拡張子として追加し、ImageMagick を設定して WebP をサポートできるようにする。これには libwebp などの依存関係が導入されます)。これにより、最適化やリサイズなどが可能になります。
Akami のあの行動はひどいね、やばい。
偽のユーザーエージェントを変更するのは簡単だろうか?いずれにせよ、2017 年にリリースされた Chrome 58 を偽るべきではない。
@eviltrout は、Discourse がなぜ特別なユーザーエージェントを使わずに偽装しているのか、その背景を完全に把握しているはずだ。私のぼんやりとした記憶では、偽装しなければ画像やワンボックスのダウンロードを拒否されるケースがあるらしい。そこで以下の方針が考えられる:
あるいは、ファイルダウンロード後に「透過的」な WebP から JPEG への変換を許可することで、サイト運営者が完全に対応していない場合でも、互換性のない画像をプロキシできるようにする手もある(これは他の特殊な画像フォーマットでも役立つ可能性がある)。
それとも、単に WebP をデフォルトでサポートし、すべてのデフォルト設定に追加して進むべきか?(まだ時期尚早かもしれないが)
残念ながら、多くのサイトは、リクエストがブラウザからのものに見えない限り、正しいコンテンツを提供してくれません。もしこれを変更すれば、ほとんどのソースは問題なく動作すると思いますが、1〜2 のソースでは不自然な挙動が見られるかもしれません。
ワンボックスの対応は、よく「ドツボ」のようなゲームです。あるバグを修正すると、別の場所で新たな問題が浮上します。
Apple が折れて Safari と iOS にサポートを追加した今こそ、これを行う適切な時期のようです。
上記のコミットにより、.webp アップロードのサポートが追加されました。
元の投稿を再レンダリングするために少し手間取りましたが、この問題は解決したようです(つまり、「Samsung」のロゴがローカルにダウンロード/キャッシュされました)。
この問題は解決したと見なしてよいでしょう。