I'm trying consume my wcf application with Postman (or simple ajax request), but for some reason, the request always return me:
STATUS 400 Bad Request
But, from the VS test client, my service works.
Interface
[OperationContract]
[WebGet(ResponseFormat = WebMessageFormat.Xml, BodyStyle = WebMessageBodyStyle.Bare, UriTemplate = "general/")]
MyModel getCourse(int idCourse);
My Class
public MyModel getCourse(int idCourse)
{
return null;
}
Some one has an idea? Thanks.
I was having a similar issue trying to test my WCF service in Postman and I used Chrome's developer tools to figure out the right parameters to pass into the Postman request.
Right-click your page in Chrome and select "Inspect Element"
Select the "Network" tab and reload a page that executes your WCF request
Select the request from the left margin of the "Network" tab, and view the "Request Headers" associated with that request
In Postman, add headers that match those that are shown on the "Request Headers" and make sure that the data you pass into the call on Postman matches that of the "Request Payload" listed in Chrome.
Your VS test client may has an app.config with settings used by runtime to inject into the CLR proxy classes in order to generate a proper SOAP request or Web API request. You may use some Web traffic diagnostic tool like Fiddler to inspect the content of a valid request from your VS client and the bad request from Postman, and compare the difference, and consult what available in VsClient.exe.config, and make appropriate change in Postman.
Related
Hey all I am trying to find some code that will allow me to know what domain the POST request to the web service is coming from.
As an example:
If the web service is on domain:
bob.com/webService/Postsomething
And the client loads a page up on domain:
bill.com/postpage.html
Once the web service is clicked off using AJAX on the html page I want to be able to get the following information from the post function its calling:
bill.com
So far I have only been able to get the IP and host name of where the web service is on and not the client domain they are asking for information from the web service from.
You could use the referrer HTTP header:
public HttpResponseMessage Get()
{
var domain = Request.Headers.Referrer?.GetLeftPart(UriPartial.Authority);
...
}
Of course this header is not guaranteed to be present and you absolutely cannot rely on it because the client making the HTTP request could simply decide not to send it. You should always check if it is null before using it.
My AngularJS $http post requests to my C# WebAPI restful service fail on Windows 8.1 in Internet Explorer 11. Firefox and Chrome both work.
Some more details:
The IT department says our network has no proxy
All 'automatically detect' and 'use proxy' settings are unchecked in all browsers
The requests fail to IIS both on my localhost and running the site and service on a local server
Enhanced protection mode of IE11 is off
The request's connection header is 'keep-alive' (I tried 'close' too and it still failed)
Sometimes one request will succeed and only from the second request will everything fail
No error is shown - the request in IE's network tab just says 'Pending' and all headers and body are blank
I'm using HTTP, not HTTPS
I've tried the meta tag 'X-UA-Compatible' IE9 and Edge
The requests fail for colleagues using IE11 on their machines too
All calls in all browsers work perfectly when Fiddler is running
Visual Studio 2013 browser link is turned off (so the SignalRArtery JS file isn't constantly making calls to the server and interfering with testing)
My AngularJS request call looks like this:
var url = UrlService.GetUrlOfApi() + 'Account/SignIn';
var postData = { 'username' : username, 'password' : password };
$http(
{
'url': url,
'data': postData,
'method': 'POST'
})
.success(function (data)
{
...
My C# service looks like this:
[RoutePrefix("Account")]
[AllowAnonymous]
public class AccountController : BaseController
{
[ResponseType(typeof(SecureResponseModel))]
[Route("SignIn")]
[HttpPost]
public IHttpActionResult SignIn(HttpRequestMessage request)
{
try
{
var userSignInDetails = GetPostData<AuthenticationRequestMessage>(request);
var token = _hisManager.AuthenticateUser(userSignInDetails.Username, userSignInDetails.Password);
return new SignInResponseMessage(token, ApiErrorCode.success, Request);
}
catch(APIException e)
{
throw;
}
}
This is what a failing call looks like in IE11, totally blank:
This is what a successful calls looks like when Fiddler is running:
Can anyone recommend any other settings to check or things to try please?
I have fixed this. My colleague advised the traditional debugging strategy of getting the simplest case to work - so I made a test post controller web service that worked every call:
I then saw the only difference between this method and the one that failed is the BaseController, which contained these methods:
I then changed the code to this to remove the suspicious looking async and await commands:
Everything now works perfectly. But can anyone explain why? In my googling this problem for the past day I've read about IE sending two packets instead of one like other browsers, and about resources being left open interfering with connections. But I don't understand how this await command broke the connection in just one browser.
I am consuming a web service from a url. When I test using SoapUI, I get the response immediately (See image below) and that the request data I sent out made it through to the other end.
So in my C# application I did the same thing, I consumed the web service wsdl and auto generated the proxy class. I create a request based on that proxy class with the exact same request data I used in SoapUI and sent out. I confirmed that at the other end they received my data successfully and no error is shown.
However, I never receive any ID back and after a while I would get this exception:
Error The HTTP request to 'http://someURLWebservice.com/WSoperation' has exceeded the allotted timeout of 00:00:59.9470000. The time allotted to this operation may have been a portion of a longer timeout.
Am I missing something here? I downloaded the WSDL and generated the mock service with SoapUI and if I make a call to that mock web service locally, I would get it right away.the ID back right away.
Here is my code:
string serverURL = Settings.Default.ExtensionServiceURL;
//Get Proxy class client
ext.ExtWSPortTypeClient client = new ext.ExtWSPortTypeClient();
EndpointAddress addr = new EndpointAddress(serverURL);
try
{
client.Endpoint.Address = addr;
Uri site = new Uri(serverURL);
client.Endpoint.ListenUri = site;
ExtensionData eData = new ExtensionData();
client.ChannelFactory.CreateChannel();
Console.WriteLine("Sending Locator Event Request to Web Service");
ext.locatorEventResponse1 resp = await client.locatorEventAsync(eData.GenerateLocatorEventRequest(ev));
}
catch (Exception ex)
{
Console.WriteLine("Error " + ex.Message);
}
finally
{
if (client != null)
{
((ICommunicationObject)client).Close();
}
}
In a similar situation, I would start with the following:
Test with the WCF Client and capture the trace file:
Configure WCF Tracing for the client
(http://msdn.microsoft.com/en-us/library/ms733025(v=vs.110).aspx)
Send the message via your WCF Client Application
Let the call timeout and save the trace log data
Test with the soapUI client and capture the Http Log
Clear the soapUI http log (one of the tabs along the bottom)
Send the message via the soapUI test request
Save the Http Log
Once you have the trace information for both clients, you should be able to compare the transactions and hopefully determine the source of the issue. In particular, I would suggest confirming the service addresses on both sides and then comparing the SOAP envelope to make sure the WCF bindings are set consistently with the soapUI settings.
In addition, you could also use Fiddler to view the web service communications. The following SO post provides good reference links. Fiddler and Monitoring Web Service Traffic
Hope this helps.
Regards,
So I ended up configure Fiddler2 to sniff my SoapUI request and compare it against my application request. In the the Application request header I saw the following:
Content-Type: text/xml; charset=utf-8
SOAPAction: ""
Host: engage.ext-inc.com
Content-Length: 1036
**Expect: 100-continue**
That Expect:100-continue is not in the SoapUI request which successfully sent out and got the response. With this in mind I took the SoapUI request in Fiddler and compose a new one base on it...except I put in Expect:100-continue and guess what, I received no response.
Upon reading about it I came across this link
And voila, upon putting ServicePointManager.Expect100Continue = false; into my code prior making the web service call I get the response back right away.
Check the message quota settings, it might be that your service is sending more than what is configured
My client hosts a few web services and has ASP.NET Web pages that will demo the web service and acts as a quick check to verify that the web service is up by the client. The problem is that the WSDL might be missing or invalid, but the Web Service will still work.
What I'd like to add to the ASP.NET web service client is a way to verify that the WSDL is there and valid, but have no idea where to start. Any suggestions would be greatly appreciated! Code behind is C#
I'm not entiery sure what you mean with verify that the WSDL is valid. Only thing I can suggest is, use an HttpWebRequest on the specific URI and see what response you get then either throw an exception based on specific status codes like 404 for example or handle it in a different way.
You can fetch the status code value
var request = (HttpWebRequest) WebRequest.Create("http://example.com/service.wsdl");
using (var r = (HttpWebResponse) request.GetResponse())
{
var result = r.StatusCode.ToString() == 200.ToString() ? "Success" : "Service not found";
Debug.WriteLine(result);
}
Hope this helps, goodluck.
Edit: if you know what services you're going to be testing you can simply add them as service reference in your client project and try to do an RPC on the service methods to see if it's available. Pictures below show to add a service reference.
Your scenario doesn't completely make sense. You could make a request to the service WSDL endpoint, http://something/service.asmx?wsdl and you could confirm that what comes back is a WSDL file. You could even validate it against the WSDL and XSD schemas.
This wouldn't tell you whether it was a WSDL that represented the service. It could conceivably be a WSDL for some totally different service.
Maybe more importantly, have you had problems where the service was available but the WSDL was not? In that case, rather than create diagnostics, I recommend that you fix the problem.
I am trying to make the upload of files in a asyncronous way. I am currently using jquery.form plugin and using the ajaxSubmit method. Backend consists of getting this uploaded document and insert it into a document library. No problems in that part. Now when I try to do an upload, I get a 404 bad request error. The webservice expects JSON from a request. I noticed that this isn't the case, as in the request payload I get something like the following.
Content-Disposition: form-data; name="file"; filename="Json45r11 (1).zip"
Whic isn't a JSON, so I think this is why I get a bad request.
Webservice definition of backend method is like this:
[OperationContract]
[WebInvoke(Method = "POST", BodyStyle = WebMessageBodyStyle.WrappedRequest , ResponseFormat = WebMessageFormat.Json)]
SuccessUpload uploadDoc(string id);
Front end submit looks like this:
$('#form').ajaxSubmit({url: 'backend Method', type: 'post',data: JSON.stringify({id:1})});
Is there a workaround all this? Any help is appreciated, sorry if bad english not native language.
The jQuery.form plugin uses multipart/form-data encoded request when uploading a file which a classic ASMX web service cannot understand. You could replace your web service with a generic ASHX handler (IHttpHandler) which would allow you to handle any request format. Or even better if you don't want to get as low-level as handlers you could use some of the new frameworks such as ASP.NET MVC, ASP.NET WEB API, WCF, ServiceStack, ... which all will happily handle multipart/form-data encoded requests.
Since the webservice expects a JSON, in the declaration of your method just put that it receives an object of type STREAM.
this should work:
[OperationContract]
SuccessUpload uploadDoc2(Stream data);