Czy współdzielony .NET IWebProxy jest bezpieczny przy równoczesnych żądaniach?

IWebProxy opisuje zasady serwera proxy. Nie daje każdej implementacji tych samych gwarancji współbieżności. Przed udostępnieniem jednego wystąpienia między zadaniami procesu roboczego ustal jego konkretną implementację i środowisko uruchomieniowe, do którego należy.

Interfejs udostępnia zapytania o trasę zależne od miejsca docelowego oraz poświadczenia. Niestandardowa implementacja może korzystać ze stałego adresu, zmiennego stanu lub konfiguracji automatycznej. Te wybory wpływają zarówno na bezpieczeństwo, jak i na wydajność.

Trzymaj zmiany konfiguracji poza przetwarzaniem żądań

Unikaj używania jednego współdzielonego obiektu proxy jako brudnopisu: zmiana jego adresu lub poświadczeń dla zadania A, gdy zadanie B wybiera trasę, czyni własność niejasną. Skonfiguruj zasady przed przekazaniem ich klientowi. W przypadku obciążeń z różnymi kontami lub punktami końcowymi proxy używaj oddzielnie posiadanych konfiguracji klienta.

Historyczna dokumentacja WebProxy nie dawała gwarancji bezpieczeństwa wątków dla składowych wystąpienia. Zastosuj ten kontrakt do odpowiedniej implementacji. Jeśli wymagana jest synchronizacja, musi w niej uczestniczyć każdy czytelnik i pisarz; blokada otoki nie może koordynować wywołujących, którzy używają oryginalnego obiektu bezpośrednio.

Długa pauza w GetProxy może zamiast tego dotyczyć wykrywania lub oceny PAC. Firma Microsoft dokumentuje blokujące wykrywanie dla WinHTTP; to wyjaśnienie ma zastosowanie, gdy klient używa tego zaplecza. Mierz wyszukiwanie trasy oddzielnie od czasu połączenia i odpowiedzi. Serializacja powolnego wyszukiwania może jedynie utworzyć kolejkę.

Stały punkt końcowy może wyeliminować wykrywanie, gdy zamierzona jest stała trasa. Przechwycenie jednego URI ze zmieniającej się zasady systemowej również odrzuca jej przyszłe decyzje. Zachowaj to rozróżnienie podczas utrzymywania starszego kodu; używaj HttpClient i jego obsługiwanej konfiguracji programu obsługi do nowej pracy HTTP.