WCF BasicHttpBinding: ProxyAddress og UseDefaultWebProxy

Ein generert tenesteklient kan ha både eit tenestesluttpunkt og bindinginnstillingar knytte til proxy. Start med å avgjere kva adresse som høyrer til kva rolle. SOAP-tenesta er framleis destinasjonen; ProxyAddress namngjev eit mellomledd.

For BasicHttpBinding vel UseDefaultWebProxy den automatisk konfigurerte proxyåtferda og er som standard true. Kontrakten til Microsoft støttar ikkje å kombinere den true-verdien med ein eksplisitt ProxyAddress som ikkje er null. Gjer valet samanhengande i staden for å setje begge og gå ut frå at éin lydlaust vinn. For ei offentleg tilgjengeleg SOAP-teneste på ein tillaten uautentisert offentleg proxy-rute leverer HTTP-proxylista kandidatadresser for ProxyAddress; ta ikkje vare på proxyinnloggingsopplysningar frå eit anna sluttpunkt.

Kontroller bindinga som sluttpunktet faktisk brukar

Ein hjelpefunksjon kan byggje den rette bindinga medan den genererte klienten framleis brukar eit anna konfigurert sluttpunkt. Undersøk bindinga som er tildelt det mislukka kallet. Å endre ein konfigurasjonsoppføring som klienten aldri valde, kan ikkje påverke ruta.

Skil deretter typen proxyinnloggingsopplysningar frå typen tenesteinnloggingsopplysningar. Eit passord som SOAP-tenesta krev, er ikkje automatisk ein konto for det valde nettverksmellomleddet.

Transporttryggleiksmodusen er eit anna val. Å byte til ein modus med berre innloggingsopplysningar berre fordi eit gammalt svar føreslår det, endrar transportføresetnadene; det provar ikkje at ruta eller kontoen er rett. Ta vare på den tiltenkte TLS-en til destinasjonen og bruk autentiseringsoppsettet som den utrulla WCF-klienten og proxyen støttar.

Ein nyttig diagnostikk namngjev tenestesluttpunktet, den valde proxykjelda, bindingførekomsten og det første svarstadiet. Det avgrensar ein 407 utan å gjere ein generert tenesteklient om til ei samling urelaterte konfigurasjonsgjettingar.