Este un IWebProxy .NET partajat sigur la cererile simultane?

IWebProxy descrie o politică de proxy. Nu oferă fiecărei implementări aceleași garanții de concurență. Înainte de a partaja o instanță între sarcini de lucru, identificați implementarea ei concretă și mediul de execuție căruia îi aparține.

Interfața expune interogări de rută dependente de destinație și acreditări. O implementare personalizată poate consulta o adresă fixă, o stare mutabilă sau o configurație automată. Aceste alegeri afectează atât siguranța, cât și performanța.

Țineți modificările de configurare în afara procesării cererilor

Evitați folosirea unui obiect proxy partajat ca ciornă: schimbarea adresei sau a acreditărilor pentru sarcina A în timp ce sarcina B selectează o rută face proprietatea neclară. Configurați o politică înainte de a o preda clientului. Pentru sarcini cu conturi sau puncte finale de proxy diferite, folosiți configurații de client deținute separat.

Documentația istorică WebProxy nu oferea o garanție de siguranță a firelor pentru membrii instanței. Aplicați acel contract implementării corespunzătoare. Dacă este necesară sincronizarea, fiecare cititor și scriitor trebuie să participe; un blocaj de împachetare nu poate coordona apelanții care folosesc direct obiectul original.

O pauză lungă în GetProxy poate implica în schimb descoperirea sau evaluarea PAC. Microsoft documentează descoperirea blocantă pentru WinHTTP; acea explicație se aplică atunci când clientul folosește acel backend. Măsurați căutarea rutei separat de timpul de conectare și răspuns. Serializarea unei căutări lente poate doar crea o coadă.

Un punct final fix poate elimina descoperirea atunci când se intenționează o rută fixă. Capturarea unui singur URI dintr-o politică de sistem în schimbare, de asemenea, aruncă deciziile ei viitoare. Păstrați această distincție la întreținerea codului vechi; folosiți HttpClient și configurația sa de handler acceptată pentru lucrări HTTP noi.