يبدو أن تحميل الصور في oneboxes معطّل. ربما يكون ذلك بسبب انتكاسة حديثة ناتجة عن تغييرات في onebox أو الوسائط الآمنة. @vinothkannans هل يمكنك إلقاء نظرة من فضلك؟
مثال: لا تظهر صورة عند oneboxing https://www.samsung.com/us/mobile/galaxy-z-flip لأن الصور تُحمّل عبر HTTP.
المشكلة هي أنه عند تنزيل صورة onebox من الرابط “http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg”، يتم إرجاع الملف بصيغة “.webp” (samsung-logo-191-1.webp). لذا لا يمكننا تنزيله لأن صيغة “.webp” غير مدرجة في القائمة البيضاء لإعداد الموقع authorized_extensions.
لم يتم تنزيل أيقونة الموقع (favicon) لأنها من نوع “.ico”. هل يجب أن نسمح بملفات “ico” في oneboxes افتراضيًا؟
أتساءل عما إذا كان WebP يظهر فقط بسبب استخدام وكيل مستخدم Chrome 
لا أعتقد ذلك. إنه يُرجع ملفًا بصيغة WebP حتى عند تنزيله يدويًا في فايرفوكس.
في نسختي من Firefox (77.0.1 (64-bit) لـ MacOS)، فإن رأس الطلب Accept في الطلب الموجه إلى URL المذكور أعلاه هو:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
(أي أن المتصفح يطلب صورة بتنسيق webp، إذا كانت متاحة)
أما Safari، في المقابل، فيحتوي على رأس Accept值为:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
ويرجع خادم الويب من سامسونج ملف jpeg. ويعرض Onebox بشكل صحيح (مع الصورة) في Safari.
تستخدم سامسونج مدير صور أكاماوي لتقديم هذه الملفات.
إذا أرسلت رأس 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.
لم تدعم شركة أبل صيغة 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 (على الرغم من أن تزوير الـ user agent ليس أمرًا نادرًا وله استخدامات متنوعة).
في الواقع، أضافت أبل دعم صيغة WebP إلى iOS14 (المُطلَق حديثًا) و macOS Big Sur (المُطلَق أمس)، لذا ربما ينبغي لنا دعم ذلك (بإضافته كإضافة افتراضية مسموح بها) وتكوين ImageMagick لدعمه (مما سيؤدي إلى إضافة اعتماد على libwebp أو ما شابه) حتى نتمكن من تحسين الصور وتغيير حجمها، وما إلى ذلك.
هذا سلوك فظيع من جانب Akami، يا إلهي.
هل من السهل تغيير عميل المستخدم الوهمي الخاص بنا؟ على أي حال، لا ينبغي لنا أن نتظاهر بأننا Chrome 58 الذي أُصدر في عام 2017.
يجب أن يكون لدى @eviltrout السياق الكامل حول سبب تظاهر Discourse وعدم استخدام عميل مستخدم خاص به فقط لـ Discourse. تذكرتي الغامضة هي أنه إذا لم نتظاهر، فقد يمنعنا بعض الأشخاص من تحميل الصور وروابط المعاينة (oneboxes). يمكننا:
ربما يمكننا السماح بـ “تحويل شفاف” من WebP إلى JPEG بعد تحميل الملف، حتى نتمكن من استضافة الصور غير المتوافقة إذا لم يدعم المشغل الموقع بشكل كامل. (قد يكون هذا مفيدًا مع بعض صيغ الصور الأخرى الغريبة).
أو يمكننا ببساطة المضي قدمًا ودعم WebP افتراضيًا وإضافته إلى جميع الإعدادات الافتراضية لدينا؟ (أتساءل عما إذا كان الوقت مبكرًا جدًا).
للأسف، الإجابة هي أن العديد من المواقع لا تقدم المحتوى الصحيح ما لم يبدو الطلب وكأنه صادر عن متصفح. أشك في أنه إذا قمنا بتغيير هذا، ستجد أن معظم المصادر تعمل بشكل جيد معه، لكن واحدًا أو اثنين سيكونان غريبين.
غالبًا ما تكون “onebox” لعبة كبيرة من مطاردة الفئران. أصلح خطأً واحدًا، ويظهر آخر في مكان آخر.
الآن بعد أن استسلمت أبل وأضفت الدعم إلى Safari و iOS، يبدو أن الوقت مناسب للقيام بذلك.
أضاف الإلتزام أعلاه دعمًا لرفع ملفات .webp.
بعد بعض الجهد اللازم لإعادة معالجة المنشور الأصلي، يبدو أن هذه المشكلة قد حُلّت الآن (أي تم تحميل/تخزين شعار ‘سامسونج’ محليًا).
أعتقد أنه يمكن اعتبار هذه المشكلة محلولة.