האם IWebProxy משותף של .NET בטוח בבקשות מקבילות?

IWebProxy מתאר מדיניות פרוקסי. הוא אינו מעניק לכל מימוש את אותן הבטחות הקביליות. לפני שתשתפו מופע אחד בין משימות עובדים, זהו את המימוש הקונקרטי שלו ואת סביבת הריצה שאליה הוא שייך.

הממשק חושף שאילתות מסלול התלויות ביעד ופרטי התחברות. מימוש מותאם עשוי להיוועץ בכתובת קבועה, במצב משתנה או בתצורה אוטומטית. בחירות אלו משפיעות גם על הביטחון וגם על הביצועים.

הרחיקו שינויי תצורה מעיבוד בקשות

הימנעו משימוש באובייקט פרוקסי משותף כטיוטה: שינוי הכתובת או פרטי ההתחברות שלו עבור משימה A בזמן שמשימה B בוחרת מסלול הופך את הבעלות לעמומה. הגדירו מדיניות לפני מסירתה ללקוח. עבור עומסי עבודה עם חשבונות או נקודות קצה שונים של פרוקסי, השתמשו בתצורות לקוח בבעלות נפרדת.

תיעוד WebProxy ההיסטורי לא העניק הבטחת בטיחות תהליכונים לחברי מופע. החילו את החוזה הזה על המימוש המתאים. אם נדרשת סנכרון, כל קורא וכותב חייבים להשתתף; מנעל עוטף אינו יכול לתאם קוראים שמשתמשים באובייקט המקורי ישירות.

השהיה ארוכה ב-GetProxy עשויה לערב במקום זאת גילוי או הערכת PAC. מיקרוסופט מתעדת גילוי חוסם עבור WinHTTP; הסבר זה חל כאשר הלקוח משתמש במנוע זה. מדדו את חיפוש המסלול בנפרד מזמן החיבור והתגובה. סידור חיפוש איטי ברצף עלול רק ליצור תור.

נקודת קצה קבועה יכולה להסיר את הגילוי כאשר מכוונים למסלול קבוע. לכידת URI אחד ממדיניות מערכת משתנה גם משליכה את החלטותיה העתידיות. שמרו על ההבחנה הזו בתחזוקת קוד ישן; השתמשו ב-HttpClient ובתצורת המטפל הנתמכת שלו לעבודת HTTP חדשה.