Have just deployed a WCF project to IIS.
However when I try to add the service reference to a test project, Visual Studio gives the following:
The document was understood, but it could not be processed.
- The WSDL document contains links that could not be resolved.
- There was an error downloading 'http://server1.local/WCFServices/serv1/serv1.svc?xsd=xsd0'.
- The underlying connection was closed: An unexpected error occurred on a receive.
- Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
- An existing connection was forcibly closed by the remote host
Metadata contains a reference that cannot be resolved: 'http://server1.local/WCFServices/serv1/serv1.svc?wsdl'.
Content Type application/soap+xml; charset=utf-8 was not supported by service http://server1.local/WCFServices/serv1/serv1.svc?wsdl. The client and service bindings may be mismatched.
The remote server returned an error: (415) Cannot process the message because the content type 'application/soap+xml; charset=utf-8' was not the expected type 'text/xml; charset=utf-8'..
If the service is defined in the current solution, try building the solution and adding the service reference again.
So there's a problem, which I sorta get. The content type of the service is mismatched from what the client is expecting.
So, how do I fix it?
Check the App.Config or Web.Config of your client and check the ServiceModel. Most probably there is a customBinding which is different from what the WCF service is sending.
As this is the first post google shows up for this error, I want to participate with my solution:
I got a similar error while changing code in a system that was working well, but updating the reference on my development system failed. The reference is located inside a silverlight project and is related to a WCF integrated in the surrounding website (standard confiduration I guess). My error message included "WCF Metadata contains a reference that cannot be resolved: 'Some funny path'. The content type text/html; charset=utf-8 of the response message does not match the content type of the binding (application/soap+xml; charset=utf-8)." My website uses authorization roles, thats where the problem/solution was based. For updating the service reference I had to allow all users:
<?xml version="1.0"?>
<configuration>
<system.web>
<!--<authorization>
<allow users="*"/>
</authorization>-->
<authorization>
<deny users="?"/>
<allow roles="role-1,role-2"/>
<deny users="*"/>
</authorization>
</system.web>
</configuration>
Related
I'm building a WCF web service that requires interop with non-WCF clients (in fact, there will be no WCF clients).
I've already written a WSDL using SOAP 1.2 (as per this example). I've validated the WSDL and have used this file (not the WSDL generated by WCF, which is superficially different) to create a soapUI test project.
I have a requirement that the web service will support SOAP 1.2, so I can't just fall back to SOAP 1.1 (which worked just fine in an early prototype).
I've used WSCF.blue to generate my WCF service, interface, and data contract classes. Everything compiles nicely and the endpoint is exposed if I hit the WCF service in my browser. All seems well with the world.
When I try to call a method from soapUi I get the following response from the server (as visible from soapUI):
HTTP/1.1 415 Cannot process the message because the content type
'application/soap+xml;charset=UTF-8;action="http://tempuri.org/FetchMyThing"'
was not the expected type 'text/xml; charset=utf-8'.
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 30 Apr 2012 08:15:29 GMT
Content-Length: 0
(Actual method names and namespaces have been manually changed for the purposes of this question. Any typos in namespace are not errors in my code - just an oversight in typing up this question)
I know that SOAP 1.1 specifies that the content type must be text/xml. SOAP 1.2 requires application/soap+xml.
My raw request (as per soapUI):
POST http://localhost/MyWs.svc HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/soap+xml;charset=UTF-8;action="http://tempuri.org/FetchMyThing"
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:ns="http://tempuri.org">
<soap:Header/>
<soap:Body>
<ns:fetchMyThingRequest attribute1="1" attribute2="10">
</ns:fetchMyThingRequest>
</soap:Body>
</soap:Envelope>
From this response, it tells me that my request is properly formed - it's a SOAP 1.2 request with the correct content type. My WCF service, however, does not expect this content type, which I assume means I have not configured it correctly and it still thinks it's a SOAP 1.1 web service.
Minimal Web.config, as per this blog post:
<system.serviceModel>
<services>
<service name="MyNamespace.MyPort">
<endpoint address="" binding="customBinding" bindingConfiguration="httpSoap12" contract="IWsPort12" />
</service>
</services>
<bindings>
<customBinding>
<binding name="httpSoap12">
<textMessageEncoding messageVersion="Soap12" />
<httpTransport />
</binding>
</customBinding>
</bindings>
</system.serviceModel>
A snippet of the service contract:
[ServiceContract(Namespace = "http://tempuri.org")]
public interface IWsPort
{
[OperationContract(Action = "http://tempuri.org/FetchMyThing")]
[FaultContract(typeof(WsFault), Action = "http://tempuri.org/FetchMyThing", Name = "fetchMyThingFault")]
[XmlSerializerFormat(SupportFaults = true)]
FetchMyThingResponse FetchMyThing(FetchMyThingRequest request);
}
I enabled service tracing for my WCF service and see the following exception that seems to confirm my hypothesis:
Activity: Listen at 'http://mycomputer/MyWs.svc
<Exception>
<ExceptionType>System.ServiceModel.ProtocolException, System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</ExceptionType>
<Message>Content Type application/soap+xml;charset=UTF-8;action="http://tempuri.org/FetchMyThing" was sent to a service expecting text/xml; charset=utf-8. The client and service bindings may be mismatched.
</Message>
(erroneous detail snipped)
</Exception>
So, my contract and service bindings are probably mismatched, if this message is to believed, but from what I understand of WCF my configuration (or at least the intent behind it) is correct.
Does anyone have any ideas as to what's wrong with my configuration?
The only thing I can think with it is that because you've not specified a binding in a lot of detail, and its using HTTP (as per this: "Listen at 'http://mycomputer/MyWs.svc'") then is it using the default (i.e. basicHttpBinding) for this, which is creating the mismatch?
I had the same issue when I had multiple bindings on my service. When I removed all bindings and only left one unnamed binding in place, the error message disappeared.
Please check this link How to: Configure WCF Service to Interoperate with ASP.NET Web Service Clients
.
To configure a Windows Communication Foundation (WCF) service endpoint
to be interoperable with ASP.NET Web service clients, use the
System.ServiceModel.BasicHttpBinding type as the binding type for your
service endpoint.
Also, defining two endpoints you can use HTTP and HTTPS versions of the same service
I am getting an error while accessing the core service on SDL Tridion 2011 SP1. When I am trying to browse /webservices/CoreService2011.svc from IIS server, it shows the following error:
This collection already contains an address with scheme http.
There can be at most one address per scheme in this collection. If your service is being hosted in IIS you can fix the problem by setting 'system.serviceModel/serviceHostingEnvironment/multipleSiteBindingsEnabled' to true or specifying 'system.serviceModel/serviceHostingEnvironment/baseAddressPrefixFilters'.
Parameter name: item
Can any one help, how it can be rectified.
I believe you have multiple hostnames setup for your Tridion CME. Or at least you are trying to connect to your Content Manager (in this case with Core Service) using multiple hostnames.
Can you try the following:
connect using localhost (obviously when you are local on the server) E.g. http://localhost/webservices/CoreService2011.svc
If above doesn't work, try looking up what host name is registered in IIS for your SDL Tridion 2011 website (in IIS 7, Right click the website, then choose Edit Bindings...). Try connect to the Core Service using the hostname defined in the website bindings
If above still doesn't solve it, try editing your web.config under "Tridion_Home\webservices" and add the following node under configuration / system.ServiceModel
Node:
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true">
<!-- The attribute "multipleSiteBindingsEnabled" was introduced in .net 4 and removes the need of http module: Tridion.Web.ServiceModel.HttpSvcPortFunneler -->
<!-- For https protocol and/or multiport configuration, uncomment this.
There should be a <add /> entry for each unique combination of protocol and hostname that is configured in IIS Bindings.
<baseAddressPrefixFilters>
<add prefix="http://hostname:portnumber"/>
<add prefix="https://hostname"/>
</baseAddressPrefixFilters>
-->
</serviceHostingEnvironment>
I've got a WCF service that's running on IIS 6, with integrated authentication and impersonation using NTLM.
Relevant portions of Web.Config
<system.web>
<identity impersonate="true"/>
<customErrors mode="Off"></customErrors>
</system.web>
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
...
</system.web>
...
<wsHttpBinding>
<binding name="wsHttpEndpointBinding">
<security mode="Transport">
<transport clientCredentialType="Ntlm" />
</security>
</binding>
</wsHttpBinding>
I just added the aspNetCompatibility because I want to know who the user is that's logged in (at least as far as IIS is concerned). From the few searches I've done that's how you get the user.
Well, after adding that line and publishing my server I get what's possibly the stupidest error I've seen:
The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'NTLM'.
I thought, "Well obviously they're doing a very case-sensitive comparison." So I searched my entire client solution for Ntlm and replaced all non-variable occurrences with NTLM. No luck.
My primary goal, of course is to get whatever user was authenticated through IIS+NTLM. If I'm going about it the wrong way, I'd be happy to know of an easier/better way. Otherwise, how do I tell my client (or my server) that it's OK to go ahead and authenticate?
One other possibility if you are running across this error is that you are experiencing an issue with the loopback check with NTLM. I have a service which runs self-contained on a non-domain (workgroup) server. WCF is configured using BasicHttpBinding with Transport security mode and Ntlm client credentials. When trying to access the service using https://servername it works great. If I try to access it using the FQDN (https://servername.domain.com) it fails with the same error:
The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'NTLM'.
If you look inside the Windows security log you will see an Audit Failure with event ID 4625. In this you will see the following failure information:
Failure Information:
Failure Reason: An Error occured during Logon.
Status: 0xc000006d
Sub Status: 0x0
To resolve this you need to either add the back connect host names (preferred) or disable the loopback check. This was a security enhancement added for NTLM in Windows Server 2003 SP1 and later to close out an attack vector against the protocol. The fix, however, causes a lot of unclear error messages like this one from WCF and continues to haunt me in many obscure ways to this day.
Start Here . This should resolve your issue
I currently use a custom gzip encoder for my WCF service. I want to replace it with the built-in IIS 7 compression if that is possible. I can't find info online on how to that.
Is there any way to enable IIS 7 compression for WCF services?
Do you know if this will be supported out-of-the-box with .Net 4?
Edit June 15th: I'm still looking for a way to replace our custom gzip encoder with a mainstream approach so if you know how to do that with .Net 4 and IIS 7, please answer this question.
Thanks
Sidebar : My attempt at doing this manually
Since I can't find how to do it by simply turning a few knobs I decided to try and enable it manually.
So far I have:
Installed and enabled the IIS 7 Dynamic Compression Module
Changed the section of the applicationHost.config file to enable compression for mimeType="application/soap+xml" and mimeType="application/xop+xml".
I used an HTTP sniffer to sniff traffic sent from my app (Windows Forms). I see that requests do not have the Accept-Encoding:gzip,deflate http header.
So I
Added it manually to all outgoing calls using the OperationContextScope class and its OutgoingMessageProperties. (I will post the details later if I find the solution).
With the http sniffer, I can see that the client header now has the correct header:
POST /### path to my service ####/MyService.svc HTTP/1.1
MIME-Version: 1.0
Content-Type: multipart/related; type="application/xop+xml";
start="<http://tempuri.org/0>";
boundary="uuid:####### some uuid #############";
start-info="application/soap+xml"
Accept-Encoding: gzip,deflate
Host: ####### my server name #############
Content-Length: 1753
Expect: 100-continue
But the server response is still not compressed.
Why is the server response not compressed? Have I used the correct mime types? Once I get the server to return a compressed answer, will the client automatically decompress it or will have to write code on the client side to decompress?
Thanks for your help
I had the same problem; .aspx pages were compressed but WCF content wasn't. It has to do with the content type returned by the WCF service, which got appended to the mime-type.
I got it to work with the following section in the ApplicationHost.config:
<dynamicTypes>
<add mimeType="text/*" enabled="true" />
<add mimeType="message/*" enabled="true" />
<add mimeType="application/*" enabled="true" />
<add mimeType="*/*" enabled="false" />
</dynamicTypes>
Here's what I did (most of the same steps as mentioned already):
Install the Dynamic Compression Role Service for IIS role
Enable Dynamic Content Compression for the website that you use to host the WCF service
Open %SystemRoot%\system32\inetsrv\config\applicationhost.config and add the relevant content type to the section of the
After this it still didn't work.
I checked the data with Firefox' Tamper Data and noticed the content type returned was actually "application/xml; charset=utf-8".
After adding the complete content type, including the "; charset=utf-8" to the section, it worked:
<add mimeType="application/xml; charset=utf-8" enabled="true" />
As I felt that the character set encoding should not be determining if the compression works or not, I ended up letting IIS compress all application/* content types.
This is useful for IIS 6
http://ramon.bloggingabout.net/2008/11/06/wcf-and-http-gzipdeflate-compression-and-silverlight/
(updated URL)
Perhaps it depends on the specific WCF service setup you are using, but for the applications I have used it in (all were mixed access for both .NET applications and Silverlight pages), the generated WCF client class contained an EnableDecompression property that can be set to true. After that my Winforms apps send the correct headers and the webservice communication is correctly compressed.
It seems you can enable Dynamic Compression in IIS via the GUI or CLI.
This article shows you both ways:
http://www.hanselman.com/blog/EnablingDynamicCompressionGzipDeflateForWCFDataFeedsODataAndOtherCustomServicesInIIS7.aspx
I found the GUI way easy. The article shows you how to confirm it is working with Fiddler.
Cheers!
I have a WCF service which i deployed on my test server. Trying to use it on my test project and I added a reference and I get this error
The document was understood, but it could not be processed.
- The WSDL document contains links that could not be resolved.
- There was an error downloading 'http://localhost:8731/somewhere.nowhere.com/service1/?xsd=xsd2'.
- Unable to connect to remote server
- No connection could be made because the target machine actively refused it
Metadata contains a reference that cannot be resolved: 'http://192.1.1.1/TestService/somewhere.nowhere.com.svc?wsdl'.
Content Type application/soap+xml; charset=utf-8 was not supported by service . The client and service bindings may be mismatched.
The remote server returned an error: (415) Cannot process the message because the content type 'application/soap+xml; charset=utf-8' was not the expected type 'text/xml; charset=utf-8'..
If the service is defined in the current solution, try building the solution and adding the service reference again.
I had my test app working before I added wsdlextras to my service project to include wsdl documentation.
This is the schema from my wsdl:
<wsdl:types>
<xsd:schema targetNamespace="http://tempuri.org/Imports">
<xsd:import schemaLocation="http://localhost:8731/somewhere.nowhere.com/?xsd=xsd2" namespace="http://tempuri.org/"/>
<xsd:import schemaLocation="http://localhost:8731/somewhere.nowhere.com/?xsd=xsd1" namespace="http://schemas.datacontract.org/2004/07/TestService"/>
<xsd:import schemaLocation="http://localhost:8731/somewhere.nowhere.com/?xsd=xsd0" namespace="http://schemas.microsoft.com/2003/10/Serialization/"/>
<xsd:import schemaLocation="http://localhost:8731/somewhere.nowhere.com/?xsd=xsd3" namespace="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
</xsd:schema>
</wsdl:types>
Attempt to Fix 1:
I changed my
<host>
<baseAddresses>
<add baseAddress />
</baseAddresses>
</host>
so my addresses in my schema all mmatch up. I can update my service reference on my test project, however I cannot view any of my methods exposed by my wcf service.
My service is deployed on windows 2003 and my test app is on XP as well
Answer is here:
WCF IIS server configuration
in short...
The problem was with WCF identity permissions. The identity that is used for the application pool that hosts the WCF service must have full NTFS permissions on the %WINDIR%\temp folder. After changing that permission to my identity (LOCAL SERVICE) on C:\Windows\Temp I was able to add service reference to WCF service.
From the error message it looks as if it cannot find the imported xsd file xsd2.
The call to the service looks like it is on port 80, but the include files are referenced from point 8731.