.NET IWebProxy: הימנעו מהמרת פרוקסי מערכת ל-WebProxy
טפלו בפרוקסי מערכת המוחזר כ-IWebProxy בלי להניח שהמחלקה הקונקרטית שלו היא WebProxy.
IWebProxy policy = WebRequest.GetSystemWebProxy();
request.Proxy = policy;
השאירו את האובייקט המוחזר כ-IWebProxy. הקטע הזה נוגע לקוד קיים המבוסס על WebRequest, ולא להמלצה לאמץ את ה-API המיושן הזה באפליקציה חדשה.
WebProxy מממש את הממשק, אבל לא כל אובייקט שמממש את הממשק יורש מ-WebProxy. לכן עטיפת מערכת עשויה לדחות את ההמרה לפני שמתרחשת בקשת רשת כלשהי. שם מחלקה פרטי של .NET Framework כמו WebProxyWrapperOpaque הוא פרט מימוש, לא בעיה בנקודת הקצה של הפרוקסי או בחשבון.
להחלטת מסלול, קראו ל-IsBypassed(destination) ול-GetProxy(destination) עם URI היעד בפועל. עקיפה עשויה להחזיר את היעד עצמו, ומדיניות מבוססת PAC עשויה לבחור מסלול אחר למארח אחר.
לאימות, IWebProxy כבר חושף את Credentials. השתמשו בחשבון ובשיטה הנתמכים בלי המרה כדי להגיע למאפיין.
חילוץ URI בודד כדי לבנות WebProxy חלופי זורק את ההתנהגות של המדיניות המקורית לפי יעד. עשו זאת רק כשנקודת קצה קבועה היא תצורת האפליקציה המיועדת, ולא כפתרון עקיף לשגיאת טיפוס.