هل مشاركة IWebProxy في .NET آمنة عبر الطلبات المتزامنة؟

يصف IWebProxy سياسة وكيل. وهو لا يمنح كل تنفيذ نفس ضمانات التزامن. قبل مشاركة نسخة واحدة بين مهام العمال، حدّد تنفيذه المحدد وبيئة التشغيل التي ينتمي إليها.

تكشف الواجهة استعلامات مسار تعتمد على الوجهة وبيانات اعتماد. قد يعتمد تنفيذ مخصص على عنوان ثابت أو حالة قابلة للتغيير أو تكوين تلقائي. تؤثر تلك الخيارات في الأمان والأداء معًا.

أبقِ تغييرات التكوين خارج معالجة الطلبات

تجنّب استخدام كائن وكيل مشترك كلوحة مسودة: تغيير عنوانه أو بيانات اعتماده للمهمة A بينما تختار المهمة B مسارًا يجعل الملكية غير واضحة. اضبط السياسة قبل تسليمها إلى العميل. لأحمال العمل ذات حسابات أو نقاط نهاية وكيل مختلفة، استخدم تكوينات عملاء مملوكة بشكل منفصل.

امتنعت وثائق WebProxy التاريخية عن ضمان سلامة الخيوط للأعضاء المثيلية. طبّق ذلك العقد على التنفيذ المقابل. إذا لزم التزامن، فيجب أن يشارك كل قارئ وكاتب؛ لا يمكن لقفل غلاف أن ينسّق المتصلين الذين يستخدمون الكائن الأصلي مباشرة.

قد يتضمن التوقف الطويل في GetProxy بدلًا من ذلك الاكتشاف أو تقييم PAC. توثّق Microsoft الاكتشاف الحاجز لـ WinHTTP؛ ينطبق هذا التفسير عندما يستخدم العميل تلك الواجهة الخلفية. قِس البحث عن المسار بشكل منفصل عن وقت الاتصال والاستجابة. إن تسلسل بحث بطيء قد يخلق طابورًا فحسب.

يمكن لنقطة نهاية ثابتة أن تزيل الاكتشاف عندما يكون المسار الثابت مقصودًا. كما أن التقاط URI واحد من سياسة نظام متغيرة يتخلى عن قراراته المستقبلية. حافظ على هذا التمييز عند صيانة الشيفرة القديمة؛ استخدم HttpClient وتكوين المعالج المدعوم لديه لأعمال HTTP الجديدة.