I am out of ideas here, so I'm hoping someone can help. Here is what I've got:
A WCF service that only has a basicHttpBinding endpoint.
There is only a service interface, all other [DataMember], [FaultContract] are concrete types.
When I run it straight from Visual Studio (using WCF Test Client or my custom app) everything works (I send a request and get a response). This usually takes a second or two.
I published it to an IIS 6 server.
I can successfully open http://server/WebService/WebService.svc?WSDL
I can successfully open http://server/WebService/WebService.svc/mex (same output as above)
The WCF Test Client and my custom app can successfully add the service reference
Whenever I try to call a service method it waits for about 15 seconds and I get the dreaded "no meaningful reply" error.
I ran Fiddler and I got a 202 result, which would seem like a success.
It's not returning more than 65536 bytes
It's returning an array, but it is small
I tried remote debugging, but can't get that to work, probably due to a firewall (but port 80 is open, I can get the WSDL)
I enabled system.diagnostics, nothing.
I have an IErrorHandler which normally logs things, nothing.
Here's the endpoint config:
<endpoint address="" binding="basicHttpBinding" contract="Enterprise.IMyService" bindingNamespace="http://ourdomain.com/MyService/">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
Anything else I can try? It's probably a simple setting somewhere, but I can't figure it out.
Edit:
The raw fiddler response:
HTTP/1.1 202 Accepted
Date: Thu, 15 Apr 2010 19:02:45 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Length: 0
I figured it out! It had nothing to do with WCF. When I moved it to the server the database connection string was no longer valid. The error logging (to e-mail) configuration also was no longer valid and was eating the exception. It took 15 seconds to respond because that's how long the SQL server connection took to time out.
Related
The server is in workgroup (not domain). The self-hosted WCF service is configured with Windows security. Binding is netTcpBinding.
<security mode="Transport">
<transport clientCredentialType="Windows" protectionLevel="EncryptAndSign" />
</security>
The WCF client runs on the same server.
A server certificate is used to encrypt traffic (probably it does not matter)
I implemented a simple test program. Everything works fine.
But when I implement it in our product, client cannot login. In event log I see an Audit Failure:
Failure Information:
Failure Reason: An Error occured during Logon
Status: 0xc000006d
Sub Status: 0x0
By googling I located this page for workaround: http://support.microsoft.com/kb/896861
After disable loopback check in registry, the logon succeed.
But I don't want to disable loopback check security in production environment. I need to find out the cause of this problem.
My question is: why my test program works fine but the product, which exposes multiple endpoints, hits the problem with loopback check security? Is there some WCF component/configuration that causes this problem?
More info: For testing I created a simple wcf client against my product. The test client call is authenticated successfully with loopback check enabled. Seems to me the problem is at wcf client side... Any idea?
Found my issue: I used a self-signed certificate with CN="WCF Security". The endpoints on both server and client have "identity" defined as:
<identity>
<dns value="WCF Security" />
</identity>
After changing to
<dns value="localhost" />
or even completely removing "identity", logon now succeeds without disabling Loopback Check Security.
I don't fully understand the relationship between the endpoint identity and certificate CN though.
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
TL;DR version is at the bottom.
I have constructed three WCF web services -- one that's using .NET 4 and two that's using .NET 3.5 -- that is consumed by an Android client. The Android client performs the calls using ksoap2-android. When the services were complete and the client could make all the calls and get all the data from the services, we decided to activate HTTPS communication for the web services. They are hosted on a server running IIS.
I'm not alone on this task. I work full-time with it, mainly the Android client. I have two coworkers, both of which have a lot of other responsibilities. The first is mostly involved in the services and the second is mostly involved in the server.
I've read a lot of guides, blogs and articles on the Internet on how to enable HTTPS for a WCF web service, but still I haven't been able to completely resolve this. For the Android client to be able to consume the client, we are limited to using the basicHttpBinding, since the wsHttpBinding contains some security details that are not supported by Android, or something. I'm not sure, but I read it some forum somewhere. If I'm wrong, I'd happily be corrected!
Okay, so I'll give a short account of what I've done so far:
I've enabled transport security, this is how the binding(s) looks:
<bindings>
<basicHttpBinding>
<binding name="basicHttp" closeTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00">
<security mode="Transport">
<transport clientCredentialType="None" />
</security>
</binding>
</basicHttpBinding>
</bindings>
I've enabled meta data publishing over HTTPS using this line of code:
<serviceMetadata httpsGetEnabled="true" />
and this:
<endpoint address="" binding="mexHttpsBinding" contract="IMetadataExchange" />
Also, my second coworker has installed a trusted certificate (a real certificate from a CA) on the IIS server and added a https binding on the server.
Okay, so far, so good. Now we could connect to the services in the browser.
When we had done this it was possible to visit the service in the browser in a secure, encrypted, manner.
The problem is that it isn't possible to make a call to the service, neither in Android nor WCF Test Client. If I call the service on the https address, I get a 404 in response. WCF Test Client returns this:
There was no endpoint listening at https://[my service address] that could accept the message. This is often caused by an incorrect address or SOAP action.
To be able to debug this, I'm using Wireshark to intercept the messages and see what really happens. I've found out that after the set up procedures (handshake, establishing trust etc.) the client sends the header and get a 101 Continue in response, after which it POSTs the body. This should be normal behavior. But then the service returns 404 Not Found. Wireshark says that the full request URI is the http address. I've configured the server to use the https address, so why does it make a call to the http address?
I've tried setting the address and listenUri attribute of the endpoint to https and http respectively and the other way around. If I do that, the server answers the request with 405 Method Not Allowed.
Is there any way to solve this? What am I missing?
What am I missing?
TL;DR version below
I'm hosting three WCF SOAP web services with IIS, one using .NET 4 and the others using .NET 3.5. I'm trying to make a call from the WCF Test Client over HTTPS. I've enabled transport security, meta data publishing over HTTPS, installed a trusted certificate and added a https binding on the server.
When I try to make a call from WCF Test Client it says that there was no endpoint listening at the address. Wireshark tells me it makes the call to the http version of the service (i.e. "http://[my address]" instead of "https://[my address]"), although it is configured to call the https address. The service returns 404 Not Found. If I set the address of the service to https and listenUri to http, I get 405 Method Not Allowed. If I do it the other way around it says that it cannot be activated. What am I missing?
I solved this by removing the endpoint and using the <protocolMapping> tag, like this:
<protocolMapping>
<add scheme="https" binding="basicHttpBinding" bindingConfiguration="basicHttps" />
</protocolMapping>
I am trying to post data from InfoPath using the WebServiceConnection, to a WFC service inside of AppFabric.
The messgae never arrives in AppFabric, and I think I know why.
My WCF service is configured like this
<endpoint address="Workflow1.xamlx" binding="basicHttpBinding" contract="WorkflowOperation" />
And when it is called by WCF Test Client, it generates the header
<s:Header>
<a:Action s:mustUnderstand="1">http://tempuri.org/WorkflowOperation/ReceiveFormPayload</a:Action>
</s:Header>
However, InfoPath does not generate this Soap header, it only generates the HTTP header
POST /Workflow1.xamlx HTTP/1.1
SOAPAction: "http://tempuri.org/WorkflowOperation/ReceiveFormPayload"
Content-Type: text/xml; charset="UTF-8"
User-Agent: SOAP Toolkit 3.0
Host: localhost:51842
Content-Length: 1893
Connection: Keep-Alive
Cache-Control: no-cache
How do I configure my WCF endpoint to only need the HTTP-header action, and not the Soap Action?
Well, I'm back again, with the answer for anyone who is interested in getting InfoPath to submit data to an AppFabric service.
The .NET BasicHttpBinding uses a combination of Soap1.2+WSAddressing1.0 - while the InfoPath client will ONLY submit to web services using Soap1.1 (with NO WSAddressing support) - rending the two completely incompatible.
I actually ended up having to write an intermediary broker which would adapt the invocations.
Many thanks to "codemeit" for a very descriptive page of the composition of the various WCF binding types.
I've got a small WCF webservice working with the built-in WCF Service Host and with hosting by the Visual Studio 2008 built-in development webserver.
I these hosting enviroments I have relied on the WCF Test Client for invoking the service methods.
Now I am running into problems with my next phase of testing:
I have it hosted in IIS 5.1 on my WinXP dev machine and I think maybe the problem is I cannot continue to use WCF Test Client anymore. Here is what's happening:
Case 1: "Anonymous Access" is CHECKED (ENABLED)
WCF Test Client UI comes up properly, exposing the WebMethods and the INVOKE button.
Yet when I click INVOKE it fails to connect with a backend data store (a 3rd party product) that requires Windows authentication. I could post the error I get back from the product.DLL but I don't think it is relevant.
Case 2: "Anonymous Access" is un-CHECKED (DISABLED)
WCF Test Client UI fails to even initialize properly. My researching of this tells me that MEX (WS-Metadata Exchange) requires "Anonymous Access" and (apparently) WCF Test Client requires MEX. Here are key snippets of the error being returned:
Error: Cannot obtain Metadata from http://localhost/wcfiishost
The remote server returned an error: (401) Unauthorized.HTTP GET Error
URI: http://localhost/wcfiishost
There was an error downloading 'http://localhost/wcfiishost'.
The request failed with the error message:
Security settings for this service require 'Anonymous' Authentication but it is not enabled for the IIS application that hosts this service
The are lots of explanations of binding options, message security, etc. and stuff I honestly do not understand. Here is my take on where I am but I would love your opinions:
(a) Because I know my WCF webservice MUST be configured to use Windows Authentication, I conclude I cannot continue to use the WCF Test Client when hosting my service in IIS. That it has effectively outlived it's usefulness to me. I will just have to take the time to write a web client because WCFTestClient won't work without Anonymous.
(or)
(b) It is possible to use WCF Test Client if it and the hosted service are configured propertly (I just don't know what the special configuration techniques are for this).
Which is correct? Time to stop using WCFTestClient or is there a way to have it both ways? Thanks in advance for your advice.
EDIT: 11 June 09
Is there anything else I can provide to help someone else help me on this question?
I just tried to have the same setup - but in my case, everything seems to work just fine.
ASP.NET web site
WCF service, using basicHttpBinding without any special settings at all
IIS Application with anonymous = enabled and Windows authentication = enabled (both turned on)
I can easily connect to it with the WcfTestClient and retrieve the metadata, and I can then call it, no problem.
Inside my service function, I check to see whether the current user is a known user or not, it is correctly identified as a Windows authenticated user:
ServiceSecurityContext ssc = ServiceSecurityContext.Current;
if (ssc.IsAnonymous)
{
return "anonymous user";
}
else
{
if(ssc.WindowsIdentity != null)
{
return ssc.WindowsIdentity.Name;
}
if (ssc.PrimaryIdentity != null)
{
return ssc.PrimaryIdentity.Name;
}
}
return "(no known user)";
I don't really know, what more to check for (except I'm on Vista with IIS7). Any chance you could include this code to check for the user in your service code? Just to see....
Marc
Marc, your setup is not even close to Johns.
John uses WSHttpBinding that uses Windows Credentials for Message mode transport. The Windows Authentication isn't being used with BasicHttpBinding. Furthermore, John had AnonymousAuthentication disabled, which is why the Metadata Exchange (mex) is failing.
The call won't even reach inside the service side function, because we get a Error 401 (Unauthorized) when we try to call.
Just know John, I have the same issue, and I'm trying to somehow set up separate bindings per endpoint. Hopefully that will work.
When I set the title/subject of this question and reached a dead end here, I opened up the same issue in the MSDN forum with a different emphasis on the title (content of question essentially the same).
For me, the real issue was how to use WCFTestClient in IIS without Anonymous Authentication being set (because my service needed Integrated Windows Authentication only).
Mex apparently requires Anonymous and by default WCFTestClient seems to need Mex. The key seems to be accomodating both my doctoring up the web.config file carefully.
Anyway, I got it working with this web.config below (the MSDN link is here:
<?xml version="1.0"?>
<configuration>
<endpoint address=""
binding="wsHttpBinding"
bindingConfiguration="wsBindingConfig"
contract="sdkTrimFileServiceWCF.IFileService">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
<endpoint address="basic"
binding="basicHttpBinding"
bindingConfiguration="bindingConfig"
contract="sdkTrimFileServiceWCF.IFileService" />
</service>
</services>
<bindings>
<basicHttpBinding>
<binding name="bindingConfig">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows"/>
</security>
</binding>
</basicHttpBinding>
<wsHttpBinding>
<binding name="wsBindingConfig">
<security mode="Transport">
<transport clientCredentialType="Windows"/>
</security>
</binding>
</wsHttpBinding>
</bindings>
</serviceBehaviors>
</behaviors>