النطاقات الأصلية والنطاقات الفرعية في NO_PROXY لـ .NET

في قواعد وكيل البيئة الموثقة في .NET، يطابق .example.com النطاقات الفرعية. ولا يطابق example.com نفسه. هذا التمييز الصغير قد يقسم خدمة واحدة بين مسارين.

افترض أن صفحة الهبوط تستخدم الاسم الأصلي وأن واجهة برمجة التطبيقات تستخدم api.example.com. قائمة تحتوي على الصيغة المنقوطة فقط يمكن أن تمرر صفحة الهبوط عبر الوكيل بينما تذهب واجهة البرمجة مباشرة. والخطأ المعاكس هو إدراج النطاق الأصلي فقط وتوقع مطابقة كل نطاق فرعي. افحص HttpClient.DefaultProxy.IsBypassed للنطاق الأصلي ولنطاق فرعي للتحقق من القرار المضبوط.

ينطبق هذا على سياسة البيئة التي يستخدمها عميل HTTP في .NET المشارك. أما IWebProxy المعيَّن صراحةً، أو تطبيق معالج آخر، أو جيل آخر من وقت التشغيل فيحتاج إلى فحص قواعده الخاصة. لا تفترض أن قائمة التجاوز في المتصفح أصبحت قائمة البيئة هذه.

قاوم أيضًا عادة ترجمة الإعداد إلى *.example.com. فصيغة بيئة .NET الموثقة لا تعامل النجمة كحرف بدل عام.

عند مقارنة أمر curl عامل بالتطبيق، احتفظ بعنوان URL الحرفي في التقرير. فـ “نفس الخادم” يخفي ما إذا كنت قد طلبت النطاق الأصلي أو نطاقًا فرعيًا أو عنوان IP. تتم مطابقة النطاق مقابل مُدخل الطلب ذلك، لا مقابل اسمك غير الرسمي للخدمة.