Är en delad .NET IWebProxy säker vid samtidiga begäranden?
Skilj samtidighetskontraktet för en IWebProxy-implementering från fördröjningar som orsakas av automatisk proxyidentifiering.
IWebProxy beskriver en proxyprincip. Den ger inte varje implementering samma samtidighetsgarantier. Innan du delar en instans mellan arbetaruppgifter, identifiera dess konkreta implementering och den körtidsmiljö som den tillhör.
Gränssnittet exponerar destinationsberoende ruttfrågor och autentiseringsuppgifter. En anpassad implementering kan konsultera en fast adress, föränderligt tillstånd eller automatisk konfiguration. Dessa val påverkar både säkerhet och prestanda.
Håll konfigurationsändringar utanför begäranbehandlingen
Undvik att använda ett delat proxyobjekt som kladd: att ändra dess adress eller autentiseringsuppgifter för uppgift A medan uppgift B väljer en rutt gör ägandet oklart. Konfigurera en princip innan du lämnar den till klienten. För arbetsbelastningar med olika proxykonton eller slutpunkter, använd separat ägda klientkonfigurationer.
Historisk WebProxy-dokumentation gav ingen trådsäkerhetsgaranti för instansmedlemmar. Tillämpa det kontraktet på motsvarande implementering. Om synkronisering krävs måste varje läsare och skrivare delta; ett omslagslås kan inte samordna anropare som använder det ursprungliga objektet direkt.
En lång paus i GetProxy kan i stället innebära identifiering eller PAC-utvärdering. Microsoft dokumenterar blockerande identifiering för WinHTTP; den förklaringen gäller när klienten använder den backend. Mät ruttuppslag separat från anslutnings- och svarstid. Serialisering av ett långsamt uppslag kan bara skapa en kö.
En fast slutpunkt kan ta bort identifieringen när en fast rutt avses. Att fånga en enda URI från en föränderlig systemprincip kastar också bort dess framtida beslut. Bevara den distinktionen när du underhåller äldre kod; använd HttpClient och dess stödda hanterarkonfiguration för nytt HTTP-arbete.