آیا IWebProxy مشترک .NET در درخواست‌های هم‌زمان ایمن است؟

IWebProxy یک سیاست پروکسی را توصیف می‌کند. این رابط به همه پیاده‌سازی‌ها تضمین‌های هم‌زمانی یکسانی نمی‌دهد. پیش از اشتراک یک نمونه میان وظایف کارگر، پیاده‌سازی مشخص آن و محیط اجرایی که به آن تعلق دارد را شناسایی کنید.

این رابط پرس‌وجوهای مسیر وابسته به مقصد و اعتبارنامه‌ها را در معرض می‌گذارد. یک پیاده‌سازی سفارشی ممکن است به نشانی ثابت، وضعیت قابل تغییر یا پیکربندی خودکار رجوع کند. این انتخاب‌ها هم بر ایمنی و هم بر کارایی اثر می‌گذارند.

تغییرات پیکربندی را از پردازش درخواست بیرون نگه دارید

از استفاده از یک شیء پروکسی مشترک به‌عنوان پیش‌نویس بپرهیزید: تغییر نشانی یا اعتبارنامه آن برای کار A در حالی که کار B مسیری را انتخاب می‌کند، مالکیت را مبهم می‌کند. پیش از تحویل به کلاینت، سیاست را پیکربندی کنید. برای بارهای کاری با حساب‌ها یا نقاط پایانی پروکسی متفاوت، از پیکربندی‌های کلاینت با مالکیت جداگانه استفاده کنید.

مستندات تاریخی WebProxy تضمینی برای ایمنی رشته‌ای اعضای نمونه ارائه نمی‌کرد. آن قرارداد را به پیاده‌سازی مربوط اعمال کنید. اگر همگام‌سازی لازم است، هر خواننده و نویسنده باید مشارکت کند؛ قفل پوششی نمی‌تواند فراخوان‌هایی را که مستقیماً از شیء اصلی استفاده می‌کنند هماهنگ کند.

مکث طولانی در GetProxy ممکن است به‌جای آن شامل کشف یا ارزیابی PAC باشد. مایکروسافت کشف مسدودکننده را برای WinHTTP مستند کرده است؛ این توضیح زمانی صدق می‌کند که کلاینت از آن بک‌اند استفاده کند. جست‌وجوی مسیر را جدا از زمان اتصال و پاسخ اندازه بگیرید. سریال‌سازی یک جست‌وجوی کند تنها می‌تواند یک صف ایجاد کند.

یک نقطه پایانی ثابت می‌تواند وقتی مسیر ثابت مقصود است، کشف را حذف کند. ثبت یک URI از سیاست سیستمی متغیر نیز تصمیم‌های آینده آن را دور می‌ریزد. این تمایز را هنگام نگهداری کد قدیمی حفظ کنید؛ برای کارهای جدید HTTP از HttpClient و پیکربندی هندلر پشتیبانی‌شده آن استفاده کنید.