عند إجراء بحث في موقع discourse الخاص بنا، إذا قمت بإرسال طلب GET عادي إلى /search?q=بحثي، فسيتم ذلك بنجاح. لكن إذا استخدمت مربع البحث وقمت بإرسال طلب البحث عبر طلب GET من نوع XHR، أحصل على استجابة بحالة 406.
بعد إجراء مزيد من الاختبارات باستخدام Postman، اكتشفت أن مجرد إضافة رأس X-Requested-With: XMLHttpRequest إلى الطلب يؤدي إلى تعطله. إزالة هذا الرأس فقط تجعل الأمر يعمل بشكل طبيعي. الخادم خلف Azure Front Door، وعند تجاوز هذا البوابة والوصول مباشرة إلى الخادم، لا تظهر هذه المشكلة. هل يقوم nginx أو خدمة البحث بشيء خاص بناءً على هذا الرأس؟ هل يمكن أن يتسبب وجود خادم وكيل عكسي في حدوث هذا التداخل؟ هل لديك أي فكرة عن كيفية إصلاح هذه المشكلة؟
يجب أن لا يقوم وكيل العكس الخاص بك بتجاهل أي رؤوس (headers) يحددها تطبيق العميل لدينا. فقد يؤدي ذلك إلى بعض الأخطاء الواضحة، ولكنه قد يتسبب أيضًا في أخطاء صامتة لن تكتشفها إلا بعد فوات الأوان.
لا، لأنك لست خلف الباب الأمامي. المشكلة ناتجة عن مرور الطلب عبر الوكيل، وأنا لا أعرف السبب بالتحديد نظرًا لأن طلبات XHR الأخرى تعمل بشكل صحيح. وهذا يشير إلى أن الطلبات المرسلة إلى البحث تُعالج بطريقة مختلفة من قبل Discourse مقارنة بطلبات XHR الأخرى.
أنا لا أستخدم وظيفة جدار حماية التطبيق (WAF). سأحاول معرفة ما إذا كان هناك أي شيء آخر قد يتسبب في إسقاط الرؤوس أو ما شابه. يبدو غريبًا أن الأمر يؤثر فقط على طلبات البحث.
كانت هناك مشكلة في منتج WAF آخر قمت بإجراء تصحيح الأخطاء عليه الشهر الماضي، حيث كان يتسبب أيضًا في تعطيل الردود الجاهزة وحفظ المسودات. وعندما يكسر ميزات تُستخدم بشكل أقل تواترًا، قد يستغرق الأمر بعض الوقت لاكتشاف جميع أوجه عدم التوافق.
أجريت المزيد من الاختبارات ويبدو أن FD تمرر بشكل خاطئ على الأقل رأس HTTP هذا. لقد قدمت طلبًا إليهم لإصلاحه. ما زلت غير متأكد من سبب اهتمام البحث بهذا الرأس، لكن يبدو أنه من الأفضل إصلاح خلل FD.
ننصح الناس عمومًا بتجنب التكوينات المعقدة ما لم تكن لديهم (لسبب ما) متطلبات ثابتة لا مفر منها. وفي تلك الحالات النادرة، نأمل أيضًا أن يكونوا خصصوا الميزانية اللازمة لدفع أجور خبراء للمساعدة في إدارة هذا التعقيد المطلوب.