I have a problem with a Web Service Consumer written in ASP.NET. The error message is:
System.InvalidOperationException: Client found response content type of 'application/xml; charset=utf-8', but expected 'text/xml'.
The client is based on System.Web.Services.Protocols.SoapHttpClientProtocol. We can't change the Content-Type given by the provider, this has to be 'application/xml; charset=utf-8'. Is there any way to change what Content-Type the SoapHttpClientProtocol expects? Unfortunately, we are probably limited to .NET 1.1.
Thanks!
Update: We found a way to change the Content-Type sent by the provider, and this solved the problem. I'd still be curious to know how to change the expectations of the consumer though.
Add a
Service Reference
for such Web Service not the
Web Reference
in your .net client Application
Related
I have a scenario where I need to send some headers to the client before receiving the request body.
It would be like using the 100-continue, but I could not figure out how to do this with ASP.NET WebAPI.
Is there a way using the native tools and IIS hosting?
Please use http method “HEAD”.
Please see https://www.rfc-editor.org/rfc/rfc2616#section-9.4
A JavaScript client that I have no control over is sending the incorrect HTTP request headers to my Web API services. More specifically, it's using a library that is sending an incorrect OData header.
Is there any way that I can intercept the HTTP request before it hits my services? Can I add/remove/update headers or query string info?
For instance, if I receive the following HTTP header:
GET /Some/API HTTP/1.1
Host: myhost.com:80
MaxDataServiceVersion: 2.0
I'd like to know how to modify it to the following before the OData libraries take over:
GET /Some/API HTTP/1.1
Host: myhost.com:80
MaxDataServiceVersion: 4.0
The header isn't incorrect. Your client expects an OData v2 service and even if you did manipulate the headers, it probably won't be able to understand the response from your server.
But you could use a simple HTTP proxy to rewrite the headers if you really want to try that route.
If you do that, make sure your OData server supports the Atom format because the OData JSON format changed completely between versions 2 and 4, so there's no way that JavaScript client will understand it. The Atom format changed as well, but if the client's parser is extremely lenient, it might work.
I have got url for svc file. For example https://Myservicelocation/UserService.svc.
Now i tried to create asp.net web application in visual studio and added this url using "Add service reference". When i put this url and then click go i get error
The request failed with HTTP status 400: Bad Request.
Metadata contains a reference that cannot be resolved: 'https://Myservicelocation/UserService.svc'.
Content Type application/soap+xml; charset=utf-8 was not supported by service https://Myservicelocation/UserService.svc. 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.
How can i resolve this?
Google says..
Probably a mismatch in the client/server bindings, where the message version in the service uses SOAP 1.1 (which expects application/soap+xml) and the version in the client uses SOAP 1.2 (which sends text/xml). WSHttpBinding uses SOAP 1.2, BasicHttpBinding uses SOAP 1.1.
Align your bindings accordingly...
I had the same problem.
Try https://Myservicelocation/UserService.svc?wsdl link.
I've implemented a RESTful API using ASP.NET Web API (included in ASP.NET MVC 4).
When a client requests my services with an unsupported Content-Type (like "text/plain"), I get the following exception:
System.InvalidOperationException: No MediaTypeFormatter is available
to read an object of type [...] from content with media type
'text/plain'.
and my service returns a HTTP status code 500 and an error is logged/reported (I'm using ELMAH).
Unfortunately, I do not find an easy way to "catch" this type of unsupported client request. IMHO, the service should return a status code like 404 (not found) or 400 (bad request), because the error is not a server error (but a client side error).
In another SO question I found this answer How do I configure the status code returned by my ASP.NET Web API service when the request has an unsupported Content-Type? which shows a possible solution by implementing a custom DelegatingHandler.
So my question is: Do I miss something? Is there any ASP.NET Web API built-in functionality that targets this problem...
I finally "fixed" the problem with a custom DelegatingHandler similar to this implementation
How do I configure the status code returned by my ASP.NET Web API service when the request has an unsupported Content-Type?.
You can find my implementation here: http://blog.janjonas.net/2012-09-05/asp_net-mvc_4_rc-web-api-return-http-status-code-4xx-invalidoperationexception-no-mediatypeformatter-available-read-object-type-content-media-type
You can certainly use your own custom DelegatingHandler or you can make your custom HttpModule
which will implement the IHttpModule and check the current http request and validate the request.
I have to use a 3rd party web service implemented in .NET 2.0 (on IIS, of course).
I have to make a java client. I am using wsdl2java to generate the SOAP stub.
As the original Apache Axis project now appears unmaintained, and I was having some problems parsing some responses from the service, I converted the client to use the latest (1.5) version of Axis2. Now, the .NET service won't even recognize my requests.
I managed to get the "chunking" turned off (where "stub" is a variable of type MumbleStub generated by wsdl2java, and I am showing what are several lines of code as one horrific line here):
stub._getServiceClient().getOptions().setProperty( HTTPConstants.CHUNKED, Boolean.FALSE);
.. so at least the service recognizes my request AS a request, albeit a bad one: "HTTP/1.1 400 Bad Request" is the response now (as opposed to an "intro / summary" page offering me a link to the WSDL).
I noticed that the Axis ("1") request had a different Content-TYpe header (text/xml, vs application/soap-xml), and I am wondering how to change this request header, if that is in fact the problem.
Alternately, has anybody else had this problem? Is the problem really the (undisplayable here, as it looks like "element injection" to the blog engine) ... xml version-"1.0" ... "XML meta intro tag" that Axis2 added to the beginning of the request?
WS-Deathstar, indeed.
As you mention the different content-type header I guess your client tries to send SOAP 1.2 requests and the 3rd party app only understands SOAP 1.1
Try changing the used soap version as AFAIK AXIS2 uses SOAP 1.2 by default
stub._getServiceClient().getOptions().setSoapVersionURI(org.apache.axiom.soap.SOAP11Constants.SOAP_ENVELOPE_NAMESPACE_URI);