Is een gedeelde .NET IWebProxy veilig bij gelijktijdige aanvragen?

IWebProxy beschrijft een proxybeleid. Het geeft niet elke implementatie dezelfde gelijktijdigheidsgaranties. Voordat u één instantie tussen werkertaken deelt, identificeert u de concrete implementatie en de runtime waartoe deze behoort.

De interface stelt bestemmingsafhankelijke routequery's en referenties beschikbaar. Een aangepaste implementatie kan een vast adres, veranderlijke status of automatische configuratie raadplegen. Die keuzes beïnvloeden zowel veiligheid als prestaties.

Houd configuratiewijzigingen buiten de aanvraagverwerking

Vermijd het gebruik van één gedeeld proxyobject als kladblok: het wijzigen van het adres of de referenties voor taak A terwijl taak B een route selecteert, maakt eigenaarschap onduidelijk. Configureer een beleid voordat u het aan de client geeft. Voor workloads met verschillende proxyaccounts of eindpunten gebruikt u afzonderlijk eigendom van clientconfiguraties.

Historische WebProxy-documentatie gaf geen threadveiligheidsgarantie voor instantieleden. Pas dat contract toe op de betreffende implementatie. Als synchronisatie nodig is, moet elke lezer en schrijver deelnemen; een wrapper-vergrendeling kan bellers die het oorspronkelijke object rechtstreeks gebruiken niet coördineren.

Een lange pauze in GetProxy kan in plaats daarvan detectie of PAC-evaluatie betreffen. Microsoft documenteert blokkerende detectie voor WinHTTP; die uitleg geldt wanneer de client die backend gebruikt. Meet routeopzoeking apart van verbindings- en reactietijd. Het serialiseren van een trage opzoeking kan slechts een wachtrij creëren.

Een vast eindpunt kan detectie verwijderen wanneer een vaste route is bedoeld. Het vastleggen van één URI uit een veranderend systeembeleid verwerpt ook de toekomstige beslissingen ervan. Behoud dat onderscheid bij het onderhouden van oude code; gebruik HttpClient en de ondersteunde handlerconfiguratie voor nieuw HTTP-werk.