Er ein delt .NET IWebProxy trygg ved samstundes førespurnader?

IWebProxy skildrar ein proxyregel. Han gir ikkje kvar implementasjon dei same samstundesgarantiane. Før du deler ein instans mellom arbeidsoppgåver, identifiser den konkrete implementasjonen og køyretidsmiljøet han høyrer til.

Grensesnittet eksponerer målstyrte rutespørjingar og legitimasjon. Ein tilpassa implementasjon kan rådføre seg med ei fast adresse, mutabel tilstand eller automatisk konfigurasjon. Desse vala påverkar både tryggleik og yting.

Hald konfigurasjonsendringar utanfor handsaming av førespurnader

Unngå å bruke eitt delt proxyobjekt som kladd: å endre adressa eller legitimasjonen for oppgåve A medan oppgåve B vel ei rute gjer eigarskapet uklårt. Konfigurer ein regel før du overleverer han til klienten. For arbeidslastar med ulike proxykontoar eller endepunkt, bruk separat eigde klientkonfigurasjonar.

Historisk WebProxy-dokumentasjon gav ingen trådtryggleiksgaranti for instansmedlemmer. Bruk den kontrakten på den tilsvarande implementasjonen. Om synkronisering er naudsynt, må kvar lesar og skrivar delta; ein innpakningslås kan ikkje koordinere kallarar som brukar det opphavlege objektet direkte.

Ein lang pause i GetProxy kan i staden innebere oppdaging eller PAC-vurdering. Microsoft dokumenterer blokkerande oppdaging for WinHTTP; den forklaringa gjeld når klienten brukar den backend-en. Mål ruteoppslag separat frå tilkoplings- og svartid. Serialisering av eit tregt oppslag kan berre skape ein kø.

Eit fast endepunkt kan fjerne oppdaging når ei fast rute er tiltenkt. Å fange éin URI frå ein skiftande systemregel forkastar òg dei framtidige avgjerdene hans. Ta vare på denne skilnaden når du vedlikeheld eldre kode; bruk HttpClient og støtta handlerkonfigurasjon for nytt HTTP-arbeid.