توقف تضمين مقاطع يوتيوب عبر Onebox عن العمل

منذ بضعة أيام (أعتقد أن ذلك كان مباشرة بعد التحديث إلى Discourse 2.5 النسخة التجريبية 5 - واستمر في النسخة التجريبية 6 - لكنه قد يكون مجرد صدفة)، فإن تضمين مقاطع فيديو YouTube يعمل بشكل متقطع.
بعد بضع ساعات من عدم العمل، عاد التضمين للعمل بشكل طبيعي تلقائيًا.
منذ أمس، توقف العمل تمامًا.

لا أرى أي خطأ محدد مثير للشك في سجلات المنتدى.

هل يمكن أن يكون ذلك مشكلة في مهلة الانتظار؟ هل توجد طريقة للتحقيق في هذا الأمر بشكل محدد؟

شكرًا مقدّمًا!

لاحظت شيئًا غريبًا عند فحص حركة المرور الناتجة عن طلب إعادة معالجة منشور يحتوي على رابط يوتيوب.
يفشل الطلب مع خطأ 404. :thinking:

بعض التفاصيل الإضافية الصغيرة.
أنا أستخدم Discourse 2.5.0.beta6 المحدّث إلى الإصدار 2d880b42a3 (تم إعادة البناء مباشرة قبل إرسال هذا المنشور).

عند إنشاء منشور جديد يحتوي على رابط يوتيوب، ألاحظ في وحدة تحكم Google Chrome خطأً إضافيًا قبل ظهور خطأ 404 عند طلب GET إلى onebox، ويشير هذا الخطأ إلى مشكلة في تسجيل Service Worker.

أود التنبيه إلى أن أي onebox يعمل باستثناء يوتيوب. :confused:

لا يمكن للمتصفح إخبارك بالسبب الحقيقي لفشل صندوق واحد. تحتاج إلى محاولة إرسال طلب مماثل من خادمك.

أفهم ما تقترحه، لكن:

  • إذا قمت بتكرار استدعاء GET البسيط (مع تمرير الرؤوس وما إلى ذلك كما هو متوقع) إلى /onebox?url=…، فستحصل ببساطة على خطأ HTML 404.

  • إذا قمت بتكرار الطلب الذي يقوم به onebox على الخادم، بنسخه من كود Ruby في ملف youtube_onebox.rb، وهو curl 'https://www.youtube.com/oembed?format=json&url=https://www.youtube.com/watch?v=Xl-PTTeRsik' لأحد مقاطع الفيديو غير المدمجة، فإنه يبدو أنه يعمل بشكل مثالي.
    في الواقع، يعيد الاستدعاء ما يلي:
    {"author_name":"AstronautiCAST","version":"1.0","height":270,"author_url":"https:\/\/www.youtube.com\/user\/AstronautiCAST","provider_name":"YouTube","provider_url":"https:\/\/www.youtube.com\/","thumbnail_height":360,"width":480,"html":"\u003ciframe width=\"480\" height=\"270\" src=\"https:\/\/www.youtube.com\/embed\/Xl-PTTeRsik?feature=oembed\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen\u003e\u003c\/iframe\u003e","type":"video","thumbnail_width":480,"title":"Loading cargo into HTV-9 Konutori","thumbnail_url":"https:\/\/i.ytimg.com\/vi\/Xl-PTTeRsik\/hqdefault.jpg"}root@fait-2020:/var/discourse#
    الذي يحتوي على كل ما يحتاجه onebox للتضمين.

لا أفهم السبب :confused:

@Falco، آسف جدًا لإزعاجك، لكن غياب دمج مقاطع YouTube (oneboxing) يُعيق تجربة المستخدم في منتدانا بشكل كبير.

في اليوم السابق، جربت عدة أشياء، مثل محاولة قراءة الكود المصدري (لفهم المرحلة ونوع الشرط الذي قد يؤدي إلى استجابة 404 من دمج YouTube)، وصولًا إلى نسخ منتدانا الحالي المنتج إلى قطرة Digital Ocean منفصلة جديدة.

قراءة الكود لم تكن مفيدة حقًا، وذلك بشكل رئيسي بسبب نقص معرفتي الحقيقية بالمنصة.
تبقى سؤال واحد مفتوحًا هنا: هل عملية دمج YouTube تُسجل في مكان ما؟ سيكون ذلك مفيدًا جدًا لفهم الخطأ الذي يجعل دمج YouTube يتخلى عن المحاولة ويعيد استجابة 404.

كانت قطرة النسخ محاولة للتحقق مما إذا كان عنوان IP للخادم المنتج محظورًا من قِبل YouTube، وفي الوقت نفسه ما إذا كان هناك شيء متعلق باسم النطاق الذي نستخدمه.
حسنًا، على الرغم من أن عنوان IP واسم النطاق كانا مختلفين، فإن دمج YouTube لم يعمل.

آمل حقًا أن يتمكن شخص ما من اقتراح طريقة على الأقل لتتبع ما تفعله عملية دمج YouTube.

لدينا السبب الجذري: قامت يوتيوب بحظر عنوان IP الخاص بنا، لكن ليس واضحًا السبب، حيث أننا في وقت حدوث ذلك لم نكن نقوم بأي إعادة معالجة ضخمة أو ما شابه.

سؤال لـ @Falco أو @codinghorror: هل كان تثبيت الإصدار 2.5.0beta 5 أو 6 يؤدي إلى أي إعادة معالجة، مما يتجاوز حد الطلبات؟

لا، لم نضيف أي إعادة معالجة حديثة. يبدو أن الأمر يتعلق بتغيير في يوتيوب، حيث اشتكى مستخدمون آخرون أيضًا.

جرب الزحف عبر الوكيل باستخدام "Onebox Assistant", crawl for those previews reliably!

شكرًا لكم جميعًا على الردود.
غير واضح لي بعدُ لماذا، عندما أحاكي الطلب الذي يقوم به محرك Onebox (أو على الأقل أتوقع أن يكون هذا هو الحال. هل هذا صحيح يا @Falco؟)، أحصل على استجابة JSON بإجابة صحيحة، وليس على خطأ 429.

هل هناك طلب آخر يقوم به Onebox ويتلقى خطأ 429 قبل تنفيذ الطلب كما هو موضح في لقطة الشاشة الخاصة بي، وهو curl 'https://www.youtube.com/oembed?format=json&url=https://www.youtube.com/watch?v=Xl-PTTeRsik' ؟

من البديهي أن هذه الطلبات قد تم إجراؤها من نفس الخادم الذي يشغّل Discourse (أي نفس عنوان IP الصادر).

من غير المرجح أن يؤدي أمر curl واحد إلى تجاوز حد المعدل؟

جرّب تشغيل سلسلة منها في تتابع سريع؟ أو شغّلها في نص bash متكرر؟ (ولكن لا تبالغ في ذلك وإلا قد يتم حظر حسابك)

حسناً، مجرد محاولة إعادة نشر منشور واحد يحتوي على رابط واحد إلى يوتيوب يؤدي إلى الحصول على خطأ 404 من onebox…

نتيجة مثيرة للاهتمام بعد عطلة نهاية أسبوع من استكشاف الأخطاء وإصلاحها.
ربما ترغب @Falco أو @codinghorror في إلقاء نظرة على هذا؟

في الوقت الحالي، أثناء قراءة كود المصدر لملف youtube_onebox.rb، أرى أنه يدعم ثلاث روابط يتم استخراج معرف الفيديو منها:

  1. http://youtu.be/<videoid>
  2. https://www.youtube.com/embed/<videoid>
  3. https://www.youtube.com/watch?v=<videoid>

تفشل كل محاولات تضمين مقاطع الفيديو ذات الروابط بالصيغتين 1 و 3، حيث يعيد onebox رمز خطأ 404 (وأعتقد أن هذا مرتبط بحظر عنوان IP الخاص بنا).

عندما أحاول تضمين روابط بالصيغة 2، تعمل بنجاح!

أتساءل عما إذا كان هذا مرتبطًا وكيف يرتبط بالواقع الموضح في هذا المنشور.

سيكون من المفيد جدًا الحصول على فهم (وتسجيل) لكيفية عمل onebox من الداخل (أي ما هي الدعوة/الدعوات الدقيقة التي تُرسل إلى YouTube)…

عدتُ هنا لإغلاق هذا الموضوع.
أمس أزال يوتيوب الحظر عنا وعُدنا إلى العمل.

هناك نقطتان أعتقد أن من المفيد فهمهما على أي حال:

  • هل يمكن لـ onebox تسجيل التفاصيل في حال فشل عملية الـ oneboxing؟ سيكون ذلك مفيدًا جدًا لفهم سبب فشلها بالضبط.
  • بما أن العنصر الوحيد الضروري لعملية الـ oneboxing لفيديوهات يوتيوب هو معرف الفيديو، أليس من الجيد محاولة جلب البيانات من كل أنواع الروابط الثلاثة الثلاثة قبل إرجاع خطأ 404 (وكما ذُكر أعلاه، فإن رابط /embed/ لم يتوقف عن العمل أبدًا بطريقة ما، حتى أثناء الحظر)؟

شكرًا لكل من أجاب على أسئلتي المقلقة! :clap:

هذا!!! (فكرة جيدة جدًا ذكرتها من قبل)

أعتقد أن جزءًا من التحدي هنا هو أنه إذا أعادت الصفحة المستهدفة صفحة بدون وسوم og، فلن يعرف Onebox أن ذلك كان بسبب إعادة توجيه ما. ومع ذلك، يمكن تسجيل ذلك (“ONEBOX: لم يتم العثور على وسوم og”)، ويجب بالتأكيد تسجيل جميع الأخطاء التي تؤدي إلى ظهور oneboxes فارغة.

tl;dr أود أن أضيف أننا نواجه نفس المشكلة على ما يبدو. إذا كانت هناك مشكلة في حد المعدل (rate-limit) بسبب تغيير حديث، فأعتقد أن مستخدمين آخرين سيبدأون في مواجهتها أثناء الهجرة أو إعادة معالجة المنشورات، أو ربما ببساطة بسبب نشاط مكثف في المنتدى. حقيقة أن “واين بوكس” (onebox) يفشل ظاهريًا بصمت تعني أن هذه المشاكل لا تظهر إلا عندما يبدأ المستخدمون في الشكوى من غياب مربعات يوتيوب.

الخلفية

نحن نستخدم الإصدار 2.6.0.beta 1

كان المستخدمون يتلقون رسائل حول محتوى غير آمن. وعند التحقيق، بدا أن متصفح كروم يشتكي من الصور المرتبطة من مواقع تستخدم بروتوكول HTTP. لذا قمت بضبط Discourse لتحميل جميع الصور والوسائط وتقديمها عبر HTTPS.

بمجرد تغيير الإعداد، تطلب ذلك إعادة معالجة (re-bake) للمنشورات التاريخية. ومنذ تلك المعالجة، تغيرت كثير من مقاطع فيديو يوتيوب التي كانت سابقًا معروضة كـ “واين بوكس” إلى روابط عادية.

لدينا موضوع واحد يحتوي على 10,000 منشور يتكون حصريًا من ردود تحتوي على مقاطع فيديو من يوتيوب، وجميع المنشورات عبارة عن روابط وليست “واين بوكس”.

أثناء إعادة المعالجة، تم تنفيذ جميع الوظائف المجدولة بشكل طبيعي، لذا لا توجد وظائف عالقة في قائمة انتظار للحذف.

لم أرَ رسائل الخطأ نفسها التي وصفها @marcozambi، لكنني أعتقد أننا نتجاوز حد المعدل أيضًا.

ما الذي جربته؟

دعمًا لنظرية حد المعدل، فإن قطعة صغيرة من الكود التي كتبتها لإعادة معالجة المنشورات نجحت (حولت إلى “واين بوكس”) في أول 80+ فيديو من يوتيوب في موضوع ما، ثم فشلت في تحويل الفيديوهات المتبقية.

عند هذه النقطة، حتى عند تعديل المنشور وإجراء تعديل بسيط ثم حفظه مرة أخرى، لم يُجبر الرابط على التوسع كـ “واين بوكس”. وفي الوقت نفسه، كانت جميع قوائم الانتظار فارغة أو تحتوي على وظائف بسيطة تتم معالجتها فورًا كما هو متوقع.

حاولت إعادة تشغيل هذا الكود على مدار 30 دقيقة، لكنه فشل في إجبار الروابط على التحول إلى “واين بوكس”. لا أعتقد أن الرقم 80 سحري هنا، بل هو مجرد ما كان متاحًا من الحصة التي نملكها.

ذكر @marcozambi أن رابط يوتيوب بصيغة /embed/ نجح بينما فشلت الروابط الأخرى، لذا قمت بتعديل الكود لاستخدام بحث واستبدال عبر تعبيرات نمطية (regex) لتحويل روابط يوتيوب إلى صيغة /embed/.

نجح الكود.

إعادة تشغيل الكود لإعادة معالجة المنشورات فقط لم ينجح في تحويلها إلى تمثيلات “واين بوكس”.

خطتي هي تجربة مهمة تحول جميع روابط يوتيوب في الموضوع الكبير إلى صيغة /embed/. إذا فشلت هذه المحاولة أو تجاوزنا حد معدل أعلى، فسألقي نظرة على أداة Onebox Assistant الخاصة بـ @merefield.

سأشارك تحديثًا لاحقًا.

حسنًا، هناك بالتأكيد شيء غريب يحدث ويبدو أنه مرتبط بالحد من المعدل (rate-limit).

لا أعرف ما إذا كنا نواجه حدًا في المعدل لأنني قمت بعملية إعادة معالجة (rebake) ضخمة فوقعنا في مشكلة، أو أننا نتجاوز حدودًا قد يراها الآخرون أيضًا.

يبدو أن عملية تضمين مقاطع فيديو YouTube (Oneboxing) لها حد معين، وبمجرد بلوغ هذا الحد، تفشل العملية بصمت دون إشعار.

أعتقد أنه يجب تغيير هذا السلوك لأسباب واضحة على الأرجح، وتحديدًا لأي شخص يقوم بهجرة أو إعادة معالجة (rebake) دون أن يدرك أن العديد من الروابط المضمنة (Oneboxes) التي لم تُوسَّع أو التي وُسِّعت سابقًا أصبحت الآن مجرد روابط نصية عادية.

ذكر @marcozambi أعلاه أن تنسيق عنوان URL الخاص بـ YouTube الذي يحتوي على /embed/ قبل معرف الفيديو يعمل عندما تفشل التنسيقات الأخرى (على الأرجح بسبب مشكلة في الحد من المعدل).

إليك مقطع فيديو يوضح هذه الظاهرة جيدًا.

عندما تم تسجيل هذه اللقطة، لم تكن هناك مهام تسد الطابور، وكان المنتدى يعمل بشكل جيد بشكل عام.

قبل هذا الفيديو، بدأت روابط YouTube بالفعل في الفشل عند محاولة توسيعها بواسطة OneBox.

ستلاحظ نافذة التكوين حيث يفشل OneBox في توسيع رابط YouTube بتنسيق https://youtu.be/<video-id>.

ثم قمت بتغيير التنسيق إلى https://youtube.com/embed/<video-id> فنجح OneBox في توسيعه.

ثم جربت مرة أخرى بالتنسيق الأصلي ففشل.

أثناء تسجيل هذا الفيديو، راقبت تبويبات وحدة تحكم المتصفح وشبكة الاتصال. أدرك أن المشكلة تقع بالتأكيد بين خادمنا وYouTube وليس بين متصفحي وخادمنا، لكنني أدرجها أدناه في حال كانت مفيدة.

(اعتذارات عن طبيعة الصورة المكبرة جدًا - أتمنى أن تكون مرئية عند التكبير)

وهنا تتبع الشبكة عندما نجح OneBox.

لستُ مقتنعًا بأن تنسيق الرابط /embed/ هو الحل السحري في هذه الحالة،

أعتقد أنه يبدو كطريق له حدود معدل منفصلة، بحيث عندما يصل مسار https://youtu.be/<video-id> إلى حدّه، يوجد مسار آخر بحد منفصل على مسار https://youtube.com/embed/<video-id>.

والدليل على أن كلا المسارين محدودان يأتي من أداة كتبتها لتغيير تنسيق تضمينات يوتيوب في موضوع ضخم يحتوي على 10 آلاف منشور، حيث كانت 99% من الردود عبارة عن مقاطع فيديو من يوتيوب.

في هذه المرحلة، كان Onebox يفشل بالفعل في توسيع الروابط بتنسيق https://youtu.be/<video-id>.

أداتي، التي غيّرت عنوان فيديو يوتيوب إلى تنسيق https://youtube.com/embed/<video-id>، تم تشغيلها على أول 3000 منشور في الموضوع.

عملت بشكل جيد مع أول 1108 منشور، ثم، بينما غيّرت التنسيق للمنشورات الـ 1900 التالية تقريبًا، لم تقم Onebox بتوسيعها.

خلال هذا الوقت، تم إنشاء العديد من الوظائف (استخدمت كودي post.revise) وتمت معالجتها جميعًا دون أخطاء أو إعادة محاولات.

من الناحية الخبرية، لاحظت أن معالجة الوظائف تسارعت بشكل ملحوظ في مرحلة معينة. أفترض أن هذا قد يكون لأن كود Onebox كان يحصل بسرعة على نوع من الأخطاء من يوتيوب - لكنني لم أقيس الوقت وقد يكون هناك أسباب أخرى عديدة.

أود أن أكون مستعدًا لتقديم أدلة أكثر تفصيلاً هنا، لكنني لست متأكدًا مما يمكنني فعله دون توظيف أدوات تتبع في مكتبة Onebox gem.

أنا هاكر وليس خبيرًا في Ruby، لكنني سأكون سعيدًا جدًا بمحاولة اتباع بعض التعليمات عالية المستوى.

قد يساعدك تنفيذ بعض سكريبتات curl المتكررة القصيرة من سطر الأوامر في الخادم باستخدام وكيل مستخدم واحد في عزل مشكلة حد المعدل.

أوافق على أن الحل البديل يعمل على الأرجح فقط لأنه يُحتسب بشكل منفصل.

إليك بعض النتائج الإضافية. لاحظ أن هناك العديد من الافتراضات في المنشور أدناه - بناءً على نقص المعرفة الحقيقية.

سأتبع هذا المنشور برأيي حول ما يحدث وما يجب أن يحدث.

شكرًا لك على الرد، روبرت.

لاحظ أن عملية Oneboxing للفيديوهات باستخدام المسار /watch كانت (وما زالت!) تفشل عندما حاولت ذلك، لذا لم أكن بحاجة إلى حلقة تكرارية لإجبارها على الفشل.

لذلك، فإن الفرضية التي افترضتها هي أن user-agent الذي تستخدمه Onebox هو Discourse Forum Onebox v2.6.0.beta1 بناءً على هذا الكود…

اخترت فيديو عشوائي وحاولت استخدام curl لقراءة الرؤوس (headers).

لقد قمت بذلك من داخل حاوية Docker على موقعي المباشر، مما أنتج الاستجابة التالية.

نتيجة أول طلب curl باستخدام المسار /watch?

الأمر

curl --user-agent "Discourse Forum Onebox v2.6.0.beta1" -sD - -o /dev/null "https://m.youtube.com/watch?v=s0ONj4TG0UA"

الاستجابة:

curl --user-agent "Discourse Forum Onebox v2.6.0.beta1" -sD - -o /dev/null "https://m.youtube.com/watch?v=s0ONj4TG0UA"
HTTP/2 303 
content-length: 0
p3p: CP="This is not a P3P policy! See http://support.google.com/accounts/answer/151657?hl=en-GB for more info."
cache-control: no-cache
x-frame-options: SAMEORIGIN
content-type: text/html; charset=utf-8
location: https://www.youtube.com/watch?v=s0ONj4TG0UA&app=desktop
accept-ch-lifetime: 2592000
x-content-type-options: nosniff
accept-ch: DPR
expires: Tue, 27 Apr 1971 19:44:06 GMT
strict-transport-security: max-age=31536000
date: Fri, 07 Aug 2020 11:35:21 GMT
server: YouTube Frontend Proxy
x-xss-protection: 0
set-cookie: VISITOR_INFO1_LIVE=rcVTSJn81Ck; path=/; domain=.youtube.com; secure; expires=Wed, 03-Feb-2021 11:35:20 GMT; httponly; samesite=None
set-cookie: YSC=cFXIPerzT3Y; path=/; domain=.youtube.com; secure; httponly; samesite=None
set-cookie: GPS=1; path=/; domain=.youtube.com; expires=Fri, 07-Aug-2020 12:05:20 GMT
alt-svc: h3-29=":443"; ma=2592000,h3-27=":443"; ma=2592000,h3-T050=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"

لذا تم إعادة توجيهي باستخدام استجابة 303 إلى العنوان الموجود في رأس location وهو https://www.youtube.com/watch?v=s0ONj4TG0UA&app=desktop.

كان لهذا ببساطة تأثير إضافة &app=desktop إلى الرابط.

نتيجة طلب curl الثاني إلى الرابط المعاد توجيهه - لا يزال على المسار /watch?

الأمر
curl --user-agent "Discourse Forum Onebox v2.6.0.beta1" -sD - -o /dev/null "https://www.youtube.com/watch?v=s0ONj4TG0UA&app=desktop"

الاستجابة

HTTP/2 429 
x-content-type-options: nosniff
expires: Tue, 27 Apr 1971 19:44:06 GMT
x-frame-options: SAMEORIGIN
cache-control: no-cache
p3p: CP="This is not a P3P policy! See http://support.google.com/accounts/answer/151657?hl=en-GB for more info."
accept-ch-lifetime: 2592000
content-type: text/html; charset=utf-8
accept-ch: DPR
strict-transport-security: max-age=31536000
content-length: 48982
date: Fri, 07 Aug 2020 11:46:00 GMT
server: YouTube Frontend Proxy
x-xss-protection: 0
set-cookie: VISITOR_INFO1_LIVE=VQwNuouhq-s; path=/; domain=.youtube.com; secure; expires=Wed, 03-Feb-2021 11:46:00 GMT; httponly; samesite=None
set-cookie: YSC=8IRfPRFRY6c; path=/; domain=.youtube.com; secure; httponly; samesite=None
set-cookie: GPS=1; path=/; domain=.youtube.com; expires=Fri, 07-Aug-2020 12:16:00 GMT
set-cookie: VISITOR_INFO1_LIVE=VQwNuouhq-s; path=/; domain=.youtube.com; secure; expires=Wed, 03-Feb-2021 11:46:00 GMT; httponly; samesite=None
set-cookie: YSC=8IRfPRFRY6c; path=/; domain=.youtube.com; secure; httponly; samesite=None
set-cookie: GPS=1; path=/; domain=.youtube.com; expires=Fri, 07-Aug-2020 12:16:00 GMT
alt-svc: h3-29=":443"; ma=2592000,h3-27=":443"; ma=2592000,h3-T050=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"

لذا يتم إرسال كود استجابة 429 “طلبات كثيرة جدًا” لي، ولكن بدون إرسال رأس retry-after - توقف فورًا دون أي مفاوضات.

في كلتا الحالتين، إذا كان هذا ما تراه Onebox، فهي تتجاهل الاستجابة، أو على الأقل لا أعرف أين أبحث عنها إذا كانت تُسجل.

بينما قد يكون هذا إجراءً مشروعًا في حالة استجابة 429 واحدة، لا يمكن تجاهل رؤية العديد من استجابات 429 في فترة زمنية قصيرة جدًا.

نتيجة طلب curl الثالث - هذه المرة باستخدام المسار /embed/

للاكتمال، حاولت فورًا الحصول على نفس الفيديو ولكن هذه المرة باستخدام المسار /embed/.

الأمر

curl --user-agent "Discourse Forum Onebox v2.6.0.beta1" -sD - -o /dev/null "https://www.youtube.com/embed/s0ONj4TG0UA"

الاستجابة

HTTP/2 200 
accept-ch-lifetime: 2592000
content-type: text/html; charset=utf-8
expires: Tue, 27 Apr 1971 19:44:06 GMT
x-content-type-options: nosniff
cache-control: no-cache
p3p: CP="This is not a P3P policy! See http://support.google.com/accounts/answer/151657?hl=en-GB for more info."
strict-transport-security: max-age=31536000
accept-ch: DPR
date: Fri, 07 Aug 2020 11:55:29 GMT
server: YouTube Frontend Proxy
x-xss-protection: 0
set-cookie: VISITOR_INFO1_LIVE=PNE6x6djF00; path=/; domain=.youtube.com; secure; expires=Wed, 03-Feb-2021 11:55:29 GMT; httponly; samesite=None
set-cookie: VISITOR_INFO1_LIVE=PNE6x6djF00; path=/; domain=.youtube.com; secure; expires=Wed, 03-Feb-2021 11:55:29 GMT; httponly; samesite=None
set-cookie: GPS=1; path=/; domain=.youtube.com; expires=Fri, 07-Aug-2020 12:25:29 GMT
set-cookie: YSC=pDW-hdbauK8; path=/; domain=.youtube.com; secure; httponly; samesite=None
alt-svc: h3-29=":443"; ma=2592000,h3-27=":443"; ma=2592000,h3-T050=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
accept-ranges: none
vary: Accept-Encoding

200 - نجاح.

يبدو أن إضافة lazy-yt تعيد كتابة الروابط بتنسيق /watch

غير متأكد مما إذا كان هذا ذا أهمية على الإطلاق، ولكن… هل إضافة المضمنة lazy-yt مفعلة افتراضيًا؟ لاحظتها في تثبيت التطوير الخاص بي.

يبدو أنها تقوم بتعديل طريقة to_html الخاصة بـ YouTube Oneboxer بشكل غير رسمي (monkey patch).

لا أعرف ما إذا كان ذلك مهمًا، لكن طريقة to_html الأصلية لـ Onebox ترجع تنسيق عنوان URL /embed/

بينما تستخدم إضافة lazy-yt تنسيق عنوان URL /watch?v=.

هل هناك أي شيء آخر يمكنني فعله لإظهار وجود مشكلة تحتاج إلى نوع من الاهتمام؟ المنشور التالي سيشرح ما أعتقد أنه السبب الجذري.