Un IWebProxy .NET condiviso è sicuro con richieste simultanee?
Distinguere il contratto di concorrenza di un'implementazione di IWebProxy dai ritardi causati dall'individuazione automatica del proxy.
IWebProxy descrive un criterio proxy. Non concede a ogni implementazione le stesse garanzie di concorrenza. Prima di condividere un'istanza tra attività di lavoro, individuarne l'implementazione concreta e l'ambiente di esecuzione a cui appartiene.
L'interfaccia espone query di route dipendenti dalla destinazione e credenziali. Un'implementazione personalizzata può consultare un indirizzo fisso, uno stato modificabile o una configurazione automatica. Tali scelte incidono sia sulla sicurezza sia sulle prestazioni.
Tenere le modifiche di configurazione fuori dall'elaborazione delle richieste
Evitare di usare un oggetto proxy condiviso come foglio di lavoro: cambiare il suo indirizzo o le sue credenziali per il lavoro A mentre il lavoro B seleziona una route rende la proprietà ambigua. Configurare un criterio prima di consegnarlo al client. Per carichi di lavoro con account o endpoint proxy diversi, usare configurazioni client possedute separatamente.
La documentazione storica di WebProxy non forniva alcuna garanzia di sicurezza dei thread per i membri di istanza. Applicare tale contratto all'implementazione corrispondente. Se è necessaria la sincronizzazione, ogni lettore e scrittore deve partecipare; un lock di wrapper non può coordinare i chiamanti che usano direttamente l'oggetto originale.
Una lunga pausa in GetProxy può invece riguardare l'individuazione o la valutazione PAC. Microsoft documenta l'individuazione bloccante per WinHTTP; tale spiegazione vale quando il client usa quel backend. Misurare la ricerca del percorso separatamente dal tempo di connessione e risposta. Serializzare una ricerca lenta può solo creare una coda.
Un endpoint fisso può eliminare l'individuazione quando si intende un percorso fisso. Catturare un singolo URI da un criterio di sistema variabile inoltre scarta le sue decisioni future. Conservare tale distinzione nella manutenzione del codice legacy; usare HttpClient e la sua configurazione del gestore supportata per il nuovo lavoro HTTP.