The exception "This operation is not supported for a relative URI." occurs in the following situation:
I have a WCF service:
[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
and MyDto
are two very simple classes marked with [DataContract]
attribute and each only having three [DataMember]
of type string, int and int?
.
This service is hosted in IIS 7.0 on a Win 2008 Server along with an ASP.NET application. I am using an SVC file MyService.svc
which is located directly in the root of the web site. The service configuration in web.config is the following:
<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>
This seems to work so far as I can enter the address http://www.domain.com/MyService.svc in a browser and get the "This is a Windows Communication Foundation Service"-Welcome page.
One of the clients consuming the service is a console application:
MyServiceClient aChannel = new MyServiceClient("WSHttpBinding_IMyService");
List<MyDto> aMyDtoList = aChannel.MyOperation(1);
It has the following configuration:
<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>
When I run this application at a production server at a customer site calling aChannel.MyOperation(1)
throws the following exception:
This operation is not supported for a relative URI.
When I run this client application on my development PC with exactly the same config, with the exception that I remove proxyAddress="10.20.30.40:8080"
from the bindings the operation works without problems.
Now I really don't know what specifying a proxy server address might have to do with absolute or relative URIs. The use of the proxy server or not is the only difference I can see when running the client on the production or on the development machine.
Does someone have an idea what this exception might mean in this context and how possibly to solve the problem?
Thank you in advance for help!
Edit:
In case it should be important: Service and Client are built with WCF in .NET Framework 4.
10.20.30.40:8080
is not a valid URL. You want http://10.20.30.40:8080
.
Here's my diagnostic thought process, in case it helps anyone:
There, in front of me, was a relative URI. When he removed it, the "operation" worked, so I deduced that this was the relative URI that was supplied to the "operation" that doesn't support them.
You don't exactly have to be Sherlock Holmes to solve this one. The key was being able to instantly see that there was no scheme://
in front of the URI, making it relative.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With