WCF BasicHttpBinding: ProxyAddress i UseDefaultWebProxy

Wygenerowany klient usługi może mieć zarówno punkt końcowy usługi, jak i ustawienia powiązania związane z proxy. Zacznij od ustalenia, który adres należy do której roli. Usługa SOAP pozostaje miejscem docelowym; ProxyAddress nazywa pośrednika.

W przypadku BasicHttpBinding opcja UseDefaultWebProxy wybiera automatycznie skonfigurowane zachowanie proxy i domyślnie ma wartość true. Kontrakt Microsoftu nie obsługuje łączenia tej wartości true z jawnym ProxyAddress różnym od null. Dokonaj wyboru spójnie, zamiast przypisywać oba i zakładać, że jeden po cichu wygrywa. Dla publicznie osiągalnej usługi SOAP na dozwolonej nieuwierzytelnionej publicznej trasie proxy lista proxy HTTP udostępnia adresy kandydujące dla ProxyAddress; nie zachowuj żadnych poświadczeń proxy z innego punktu końcowego.

Sprawdź powiązanie, którego faktycznie używa punkt końcowy

Funkcja pomocnicza może zbudować właściwe powiązanie, podczas gdy wygenerowany klient nadal używa innego skonfigurowanego punktu końcowego. Sprawdź powiązanie przypisane do nieudanego wywołania. Zmiana wpisu konfiguracji, którego klient nigdy nie wybrał, nie może wpłynąć na jego trasę.

Następnie odróżnij typ poświadczeń proxy od typu poświadczeń usługi. Hasło wymagane przez usługę SOAP nie jest automatycznie kontem dla wybranego pośrednika sieciowego.

Tryb zabezpieczeń transportu to kolejna decyzja. Przejście na tryb tylko poświadczeń wyłącznie dlatego, że sugeruje to stara odpowiedź, zmienia założenia transportu; nie dowodzi, że trasa lub konto są poprawne. Zachowaj zamierzone TLS miejsca docelowego i użyj układu uwierzytelniania obsługiwanego przez wdrożonego klienta WCF i proxy.

Przydatna diagnostyka wskazuje punkt końcowy usługi, wybrane źródło proxy, wystąpienie powiązania i pierwszy etap odpowiedzi. To zawęża błąd 407, nie zamieniając wygenerowanego klienta usługi w zbiór niepowiązanych domysłów konfiguracyjnych.