When I try to access WCF client, I get the following error. I was able to access my service using IE and able to reference in VS 2010. My development environment is Windows server 2008. I hosted service in Sharepoint Project server. I am stuck with this error. Please advice.
"The content type text/html; charset=UTF-8 of the response message does not match the content type of the binding (text/xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly. "
Here is some data Headers from Fiddler.
GET /_vti_bin/psi/helloservice.svc HTTP/1.1
Content-Type: text/xml; charset=utf-8
MicrosoftSharePointTeamServices: 14.0.0.4762
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-SharePointHealthScore: 4
WCF HTTP Activation must be enabled on the server. If the script maps for WCF are not installed you may receive the error.
Related
I've build a web api service with basic authentication and using a global DelegatingHandler implementation which I hook up to the web API GlobalConfiguration, in order to extract the username:password credentials from the request and hook an IPrincipal to the HttpContext if the credentials map to a valid user.
I've tested my api thoroughly on localhost and it's working fine, but not quite when hosted on IIS on a VPS.
I've hooked up remote debugging on the VPS in order to inspect whats going on and it turns out that whenever I include the authorization header to my request, the breakpoints I have set on the message handler are not getting hit, meaning that the request does not reach the handler. If I remove the Authorization header from the request, the breakpoint is getting hit and the handler is able to process it.
Since the message handlers are the first that will process the request in the pipeline (from what I know of, correct me if I'm wrong) I guess there must be an IIS or setup issue that I'm not aware of that messes the authentication process.
Fiddler Request Headers
GET http://myip/api/v1/route/parameter HTTP/1.1
Content-Type: application/json; charset=utf-8
Authorization: Basic ZHJpdmVyOjEwMTAyMDAz
Host: myip
Fiddler Response Headers
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
WWW-Authenticate: Basic realm="myip"
X-Powered-By: ASP.NET
Date: Mon, 22 Aug 2016 15:04:15 GMT
Content-Length: 61
{"Message":"Authorization has been denied for this request."}
What could be possibly be wrong, where should I look at for a solution?
EDIT
Had to disable Basic Authentication from the Authentication menu on the right pane setting for the IIS application.
I configured my WCF service to https. I can browse WSDL using my https:// url address. However, when I test the service using SOAP UI, the URL deafults to http. I do receive expected response when I test it. If I change the URL in SOAP UI to https, I get the following.
HTTP/1.1 404 Not Found
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Tue, 04 Dec 2012 16:46:32 GMT
Content-Length: 0
This question is related to my other question:
Why my WSDL still shows basic http binding with the location value of http?
Any ideas?? Is this a problem with IIS configuration?
I'm not sure if this is your (only) problem since you haven't posted your configuration, but you need HttpsGetEnabled set to true and also need to use an https base address.
http://msdn.microsoft.com/en-us/library/ms751498.aspx
Finally, I was able to fix it by changing wsHttpBinding to basicHttpBinding. Everything works now.
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.
Context:
BizTalk 2010 trying to call a one way(fire and forget) PeopleSoft service that does not return a response. I have verified that BizTalk 2010 does not support one way services by design. Unable to call one way Peoplesoft service with WCF-Adapter from BizTalk 2010
PeopleSoft team showed me that their asynchronous service returns the following Http status and headers.
HTTP/1.1 200 OK
Date: Thu, 20 Jan 2011 15:31:37 GMT
Content-Length: 0
Content-Type: text/xml; charset=UTF-8
TransactionID: <some GUID>
X-Powered-By: Servlet/2.5 JSP/2.1
However, when I look at the xml returned from a One Way WCF service published by BizTalk 2010 I see this
HTTP/1.1 200 OK
Content-Length: 86
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Thu, 20 Jan 2011 15:34:32 GMT
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body/></s:Envelope>
Note the empty SOAP message.
Therefore, BizTalk 2010 needs to have a NON-NULL response to be able to call a service.
PeopleSoft service sending back the HTTP status code above IS NOT considered an acknowledgement by BizTalk.
Is that correct?
Thanks.
If a web service does not return a response, it needs to return an HTTP 204 - No Content. I've not tried this in WCF yet, but HTTP honors the no content return code. As for the BizTalk WCF service... not sure why it's not using 204. But since it is using 200, it needs to send something.
It looks like BizTalk 2010 does need to have a NON-NULL response to be able to call a service.
Thanks to Ben for confirmation.
See details here.
What is the nature of the message you send out? You could in theory send a one way HTTP message and correlate on a separate HTTP response port.
I have a WCF service that has webHttpBinding and has enableWebScript turned on in it's endpoint behavior configuration.
The response from the service looks something like this
HTTP/1.1 200 OK
Date: Fri, 23 Oct 2009 20:09:02 GMT
Server: Microsoft-IIS/6.0
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: application/json; charset=utf-8
Content-Length: 25
{"d":{"__type":"SOMETYPE", ... }}
Its using HTTP 1.1 and so there are the standard headers. The contentType is set to be applciation/json which also makes sense. In the message body (the JSON part), everything is enclosed in an envelope titled "d".
What is that? Who defines that protocol? Is it something specific to WCF?
I couldn't find that defined in any of the protocols involved or the definition of the "application/json" contentType.
Thanks
That is ASP.NET AJAX specific and is caused by applying the WebScriptEnablingBehavior (enableWebScript in config) to your endpoint. The wrapper is required on both input and output and there are also special behaviors added around exception handling.
If you want "pure" JSON, you should remove the WebScriptEnablingBehavior and just use WebHttpBehavior (webHttp in config). Then just make sure you explicitly set the Request/ResponseFormat properties on your WebGet/InvokeAttributes.