خطأ استدعاء Curl عند الاتصال بموقع Discourse ومحطات WordPress المحلية

مطور
1

لطالما كنت أواجه الخطأ التالي عند محاولة ربط مواقع Discourse و WordPress المحلية الخاصة بي:

cURL error 61: Unrecognized content encoding type. libcurl understands deflate, gzip, br content encodings.

يبدو أن المشكلة تكمن في أن Discourse، في بيئة التطوير المحلية، يقوم بتعيين الرأس التالي:

content-encoding: null

خادم Apache المحلي الخاص بي غير قادر على التعامل مع رأس content-encoding: null. من خلال واجهة سطر الأوامر الخاصة بـ WordPress (wp shell)، يفشل طلب إلى wp_remote_get("http://localhost:4200/site.json") بالخطأ الذي ذكرته أعلاه، بينما يعمل طلب إلى موقع Discourse الإنتاجي، على سبيل المثال wp_remote_get("https://meta.discourse.org/site.json") دون أي مشاكل.

الحل المؤقت الذي أستخدمه للمشكلة هو التعليق على هذا السطر في تثبيت Discourse المحلي الخاص بي: https://github.com/discourse/discourse/blob/main/app/assets/javascripts/bootstrap-json/index.js#L330. ومع ذلك، هذا ليس حلاً جيدًا. هل واجه أي شخص مشاكل مماثلة في الاتصال بموقع Discourse يعمل على localhost؟ هل لدى أي شخص اقتراحات حول كيفية تكوين خادم Apache محلي لقبول الاستجابات التي تحتوي على رأس content-encoding: null؟

أتمنى لو كنت أعرف بالضبط متى بدأت المشكلة. ربما كانت تحدث منذ أن بدأ Discourse في تعيين رأس content-encoding: null.

تعديل: تحدث المشكلة على Ubuntu 22.04.1. إصدار Curl: curl 7.81.0. إصدار PHP: 8.1.2. هذه المشكلة ليست عاجلة على الإطلاق، ولكني فضولي لمعرفة ما يحدث.

4 إعجابات
Self-hosted local/staging setup options or recommendations?
2

مثير للاهتمام! هذا يذكرني بشيء خافت لا أستطيع تحديده في الوقت الحالي. لكن أعتقد أن سؤالي الأول هو أين ولماذا يقوم Discourse بتعيين رأس content-encoding إلى null؟

يبدو هذا بالفعل وكأنه مشكلة “خاصة بالتطوير فقط”. هذا يبدو متعلقًا بـ

إعجاب واحد (1)
3

تتغير أرقام الأسطر مع تحديث الكود. كمرجع مستقبلي، السطر في كود Discourse الذي اضطررت للتعليق عليه للتطوير المحلي باستخدام إضافة WP Discourse هو:

res.set("content-encoding", null);

بدون تتبع كامل لما يحدث في كود Discourse، يبدو أن التعليق على هذا السطر يتسبب في قيام Discourse بـ gzip الاستجابة:

["content-encoding"]=>
  array(1) {
    [0]=>
    string(4) "gzip"
  }

هذا لا يبدو أنه يسبب أي مشاكل في بيئة التطوير الخاصة بي.

إعجابَين (2)
4

أضطر للعودة إلى هذا الموضوع في كل مرة أرغب في ربط مواقع WordPress و Discourse المحلية الخاصة بي.

للرجوع إليها، السطر res.set("content-encoding", null); موجود الآن في:

التعليق على السطر يحل المشكلة.

إذا لم تكن المشكلة تؤثر على الآخرين، فربما هناك خطأ في التكوين في بيئة التطوير المحلية الخاصة بي. ومع ذلك، لا يزال تعيين “content-encoding” إلى null يبدو خاطئًا. إنها ليست قيمة صالحة للرأس.

5

في الواقع، واجهت هذا مؤخرًا في سياق المكون الإضافي ActivityPub أثناء اختبار التكامل ActivityPub بين المكون الإضافي Wordpress ActivityPub و Discourse محليًا.

لقد غيرت الفئة إلى Dev هنا لأنني أعتقد أنها مشكلة تطوير فقط مع discourse/discourse وتظهر فقط مع PHP عن بُعد (بسبب كيفية تعامل وظائف طلبات PHP مع الأشياء أو شيء من هذا القبيل).

لا أتذكر بالضبط الآن، لكن أعتقد أنني توصلت إلى استنتاج أن هذا يتم تعيينه في مكان آخر في الإنتاج؟ سأحاول أن أتذكر غدًا.

إعجاب واحد (1)