Biztonságos-e a megosztott .NET IWebProxy párhuzamos kérések esetén?

IWebProxy proxyházirendet ír le. Nem minden implementációnak adja ugyanazokat a párhuzamossági garanciákat. Mielőtt egy példányt megosztana munkafeladatok között, azonosítsa annak konkrét implementációját és azt a futtatókörnyezetet, amelyhez tartozik.

A felület célfüggő útvonal-lekérdezéseket és hitelesítő adatokat tesz elérhetővé. Egy egyéni implementáció rögzített címet, változó állapotot vagy automatikus konfigurációt is figyelembe vehet. Ezek a választások a biztonságra és a teljesítményre egyaránt hatnak.

Tartsa a konfigurációs változtatásokat a kérésfeldolgozáson kívül

Kerülje egyetlen megosztott proxyobjektum piszkozatként való használatát: ha az A feladat számára módosítja a címét vagy hitelesítő adatait, miközben a B feladat útvonalat választ, a tulajdonjog bizonytalanná válik. A házirendet a kliensnek való átadás előtt konfigurálja. Eltérő proxyfiókokkal vagy végpontokkal járó munkaterhelésekhez külön tulajdonolt klientkonfigurációkat használjon.

A történelmi WebProxy-dokumentáció nem adott szálbiztonsági garanciát a példánytagokra. Alkalmazza ezt a szerződést a megfelelő implementációra. Ha szinkronizálás szükséges, minden olvasónak és írónak részt kell vennie; egy burkolózár nem tudja összehangolni az eredeti objektumot közvetlenül használó hívókat.

A GetProxy hosszú szünetét inkább felderítés vagy PAC-értékelés okozhatja. A Microsoft dokumentálja a blokkoló felderítést a WinHTTP esetében; ez a magyarázat akkor érvényes, ha a kliens ezt a hátteret használja. Az útvonalkeresést külön mérje a kapcsolódási és válaszidőtől. Egy lassú keresés sorba rendezése csupán sor kialakulását eredményezheti.

Egy rögzített végpont megszüntetheti a felderítést, ha rögzített útvonalat szánnak. Egyetlen URI rögzítése egy változó rendszerházirendből szintén elhajítja annak jövőbeli döntéseit. Őrizze meg ezt a különbséget az örökölt kód karbantartásakor; új HTTP-munkához használja a HttpClientet és annak támogatott kezelőkonfigurációját.