Er en delt .NET IWebProxy trygg ved samtidige forespørsler?

IWebProxy beskriver en proxyregel. Den gir ikke hver implementasjon de samme samtidighetsgarantiene. Før du deler én instans mellom arbeidsoppgaver, identifiser dens konkrete implementasjon og kjøretidsmiljøet den tilhører.

Grensesnittet eksponerer destinasjonsavhengige rutespørringer og påloggingsinformasjon. En tilpasset implementasjon kan konsultere en fast adresse, mutabel tilstand eller automatisk konfigurasjon. Disse valgene påvirker både sikkerhet og ytelse.

Hold konfigurasjonsendringer utenfor behandlingen av forespørsler

Unngå å bruke ett delt proxyobjekt som kladd: å endre adressen eller påloggingsinformasjonen for oppgave A mens oppgave B velger en rute gjør eierskapet uklart. Konfigurer en regel før du overleverer den til klienten. For arbeidsbelastninger med ulike proxykontoer eller endepunkter, bruk separat eide klientkonfigurasjoner.

Historisk WebProxy-dokumentasjon ga ingen trådsikkerhetsgaranti for instansmedlemmer. Bruk den kontrakten på den tilsvarende implementasjonen. Hvis synkronisering kreves, må hver leser og skriver delta; en innpakningslås kan ikke koordinere kallere som bruker det opprinnelige objektet direkte.

En lang pause i GetProxy kan i stedet innebære oppdaging eller PAC-evaluering. Microsoft dokumenterer blokkerende oppdaging for WinHTTP; den forklaringen gjelder når klienten bruker den backend-en. Mål ruteoppslag separat fra tilkoblings- og svartid. Serialisering av et tregt oppslag kan bare skape en kø.

Et fast endepunkt kan fjerne oppdaging når en fast rute er tiltenkt. Å fange én URI fra en skiftende systemregel forkaster også dens fremtidige beslutninger. Bevar denne forskjellen når du vedlikeholder eldre kode; bruk HttpClient og støttet behandlerkonfigurasjon for nytt HTTP-arbeid.