के साझा .NET IWebProxy समवर्ती अनुरोधहरूमा सुरक्षित छ?

IWebProxy ले प्रोक्सी नीति वर्णन गर्दछ। यसले प्रत्येक कार्यान्वयनलाई समान समवर्तीता ग्यारेन्टी दिँदैन। कार्यकर्ता कार्यहरूबीच एउटा इन्स्ट्यान्स साझा गर्नु अघि यसको ठोस कार्यान्वयन र यो सम्बन्धित रनटाइम पहिचान गर्नुहोस्।

इन्टरफेसले गन्तव्य-निर्भर मार्ग प्रश्नहरू र प्रमाणहरू खुलासा गर्दछ। अनुकूलन कार्यान्वयनले स्थिर ठेगाना, परिवर्तनशील स्थिति वा स्वचालित कन्फिगरेसनलाई परामर्श गर्न सक्छ। ती छनोटहरूले सुरक्षा र कार्यक्षमता दुवैलाई असर गर्छन्।

कन्फिगरेसन परिवर्तनहरू अनुरोध प्रशोधनबाट बाहिर राख्नुहोस्

एउटा साझा प्रोक्सी वस्तुलाई मस्यौदाको रूपमा प्रयोग गर्नबाट बच्नुहोस्: कार्य B ले मार्ग छनोट गर्दै गर्दा कार्य A का लागि यसको ठेगाना वा प्रमाण परिवर्तन गर्दा स्वामित्व अस्पष्ट हुन्छ। ग्राहकलाई दिनु अघि नीति कन्फिगर गर्नुहोस्। फरक प्रोक्सी खाता वा अन्त्य बिन्दु भएका कार्यहरूका लागि अलग स्वामित्वका ग्राहक कन्फिगरेसनहरू प्रयोग गर्नुहोस्।

ऐतिहासिक WebProxy दस्तावेजले इन्स्ट्यान्स सदस्यहरूका लागि थ्रेड-सुरक्षा ग्यारेन्टी दिएको थिएन। त्यो सम्झौता सम्बन्धित कार्यान्वयनमा लागू गर्नुहोस्। यदि सिङ्क्रोनाइजेसन आवश्यक छ भने प्रत्येक पाठक र लेखकले सहभागी हुनुपर्छ; र्यापर लकले मूल वस्तु सिधै प्रयोग गर्ने कल गर्नेहरूलाई समन्वय गर्न सक्दैन।

GetProxy मा लामो रोकावट यसको सट्टा पत्ता लगाउने वा PAC मूल्याङ्कनसँग सम्बन्धित हुन सक्छ। Microsoft ले WinHTTP का लागि अवरोधक पत्ता लगाउने दस्तावेज गर्छ; ग्राहकले त्यो ब्याकइन्ड प्रयोग गर्दा त्यो व्याख्या लागू हुन्छ। मार्ग खोजीलाई जडान र प्रतिक्रिया समयबाट अलग नाप्नुहोस्। ढिलो खोजीलाई क्रमबद्ध गर्दा केवल लाम मात्र बन्न सक्छ।

स्थिर अन्त्य बिन्दुले स्थिर मार्ग अभिप्रेत हुँदा पत्ता लगाउने कार्य हटाउन सक्छ। परिवर्तनशील प्रणाली नीतिबाट एउटा URI कैद गर्नुले पनि यसका भविष्यका निर्णयहरू त्याग्छ। पुरानो कोड मर्मत गर्दा त्यो भिन्नता जोगाउनुहोस्; नयाँ HTTP कार्यका लागि HttpClient र यसको समर्थित ह्यान्डलर कन्फिगरेसन प्रयोग गर्नुहोस्।