Wyjątek „Ta operacja nie jest obsługiwana dla względnej URI.” Występuje w następującej sytuacji:Dziwny wyjątek podczas łączenia się z usługą WCF za pośrednictwem serwera proxy
Mam usług WCF:
[ServiceContract(ProtectionLevel=ProtectionLevel.None)]
public interface IMyService
{
[OperationContract]
[FaultContract(typeof(MyFault))]
List<MyDto> MyOperation(int param);
// other operations
}
public class MyService : IMyService
{
public List<MyDto> MyOperation(int param)
{
// Do the business stuff and return a list of MyDto
}
// other implementations
}
MyFault
i MyDto
są dwa bardzo proste zajęcia oznaczone atrybutem [DataContract]
i każdy mając tylko trzy [DataMember]
typu string, int and int?
.
Ta usługa jest hostowana w IIS 7.0 na serwerze Win 2008 wraz z aplikacją ASP.NET. Używam pliku SVC MyService.svc
, który znajduje się bezpośrednio w katalogu głównym witryny. Konfiguracja usługi w web.config jest następujący:
<system.serviceModel>
<services>
<service name="MyServiceLib.MyService">
<endpoint address="" binding="wsHttpBinding"
bindingConfiguration="wsHttpBindingConfig"
contract="MyServiceLib.IMyService" />
</service>
</services>
<bindings>
<wsHttpBinding>
<binding name="wsHttpBindingConfig">
<security mode="None">
<transport clientCredentialType="None" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior>
<serviceMetadata httpGetEnabled="false"/>
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
To wydaje się działać tak dalece, jak można wprowadzić adres http://www.domain.com/MyService.svc w przeglądarce i uzyskać „To jest Windows Communication Foundation Service” powitalnego strona.
Jeden z klientów zużywających usługi to aplikacja konsoli:
MyServiceClient aChannel = new MyServiceClient("WSHttpBinding_IMyService");
List<MyDto> aMyDtoList = aChannel.MyOperation(1);
ona następująca konfiguracja:
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding_IMyService" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
bypassProxyOnLocal="true" transactionFlow="false"
hostNameComparisonMode="StrongWildcard"
maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="false"
proxyAddress="10.20.30.40:8080" allowCookies="false">
<readerQuotas maxDepth="32" maxStringContentLength="8192"
maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<reliableSession ordered="true" inactivityTimeout="00:10:00"
enabled="false" />
<security mode="None">
<transport clientCredentialType="Windows" proxyCredentialType="None"
realm="" />
<message clientCredentialType="Windows"
negotiateServiceCredential="true" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<client>
<endpoint address="http://www.domain.com/MyService.svc" binding="wsHttpBinding"
bindingConfiguration="WSHttpBinding_IMyService"
contract="MyService.IMyService"
name="WSHttpBinding_IMyService" />
</client>
</system.serviceModel>
Kiedy uruchomić tę aplikację na serwerze produkcyjnym w siedzibie klienta nazywając aChannel.MyOperation(1)
generuje następujący wyjątek:
Ta operacja nie jest obsługiwana dla względnego identyfikatora URI.
Kiedy uruchomić tę aplikację kliencką na moim rozwoju PC z dokładnie takiej samej konfiguracji, z tą różnicą, że usunę proxyAddress="10.20.30.40:8080"
z wiązaniami operacja działa bez problemów.
Teraz naprawdę nie wiem, co określa adres serwera proxy może mieć związek z bezwzględnymi lub względnymi identyfikatorami URI. Korzystanie z serwera proxy lub nie jest jedyną różnicą, jaką widzę podczas uruchamiania klienta na produkcji lub na maszynie programistycznej.
Czy ktoś ma pojęcie, co może oznaczać ten wyjątek w tym kontekście i jak rozwiązać problem?
Z góry dziękujemy za pomoc!
Edit:
W przypadku powinny być ważne: obsługa klienta i są zbudowane z WCF w Framework 4.
Wow! Tysiąc stronicowe pytanie, jedna linia odpowiedzi i trafiłeś w gwóźdź. Po prostu przetestowany, działa, oznaczony jako odpowiedź. Ukrywam się ze wstydu. W każdym razie: dobrze, że zapytałem. Dziękuję Ci bardzo! (Edycja: Lol, "możesz zaakceptować odpowiedź w 2 minuty", byłeś zbyt szybki, czekasz teraz 2 minuty ...) – Slauma
Slauma, bardzo dobrze, że zapytałeś!)) Bo zostałem złapany w bardzo podobnej sytuacji. Powodem, dla którego adres URL proxy został użyty bez "http: //" w moim przypadku jest to, że został skopiowany z innego miejsca (parametr do wget.exe), gdzie był to prawidłowa składnia. – Ivan