I have an application in WPF which is using Java web service. Users can search some documents via application. Two days ago they(who have created the web service) told me that I must change url of the service. So, I did it. But after that the application began to get datas slower than previous. To tell the truth, i am making about 12 request to the web service in one searching. But it was getting all datas in approximately 0.52 second with the previuos web service which was using HTTPS. But the current web service is using HTTP and it takes about 8 seconds to get all datas. And in my opinion the problem might be protocol. But actually, processing time in HTTP must be greater than HTTPS.
So, what could be a problem?
Also, i am connecting to web service with that code:
HQRTXServiceWSService service = new HQRTXServiceWSService();
service.Url = " a url of the web service";
service.Credentials = new System.Net.NetworkCredential("user", "password");
service.PreAuthenticate = true;
Maybe the webservice implementation has been updated and they messed up with their performance?
It could also be their infrastructure, or if there are more people using their webservice... Could be many things but your code ;)
I don't think that HTTP should be slower than HTTPS, usually, it's the contrary, because there's a small overhead for encryption on HTTPS.
Related
I have an application that generates a web request to Facebook Graph API to get a share count from an external page. I have been using this code for over a year without issue, and suddenly, the share count is not working when the request is made from .NET. However, if I make the request from a web browser, it works just fine. My code is as follows:
string fbLink = "https://graph.facebook.com/?id=" + externalLink + "&fields=og_object%7Bengagement%7D&access_token=<token_removed>";
WebClient client = new WebClient();
string fbString = client.DownloadString(fbLink);
This code still appears to be working fine, in that the request is made, and FB responds with no errors. In fact, it responds back with correct page id, and details. However, the share count is zero.
Here is where it gets a little bit weird. On my localhost development machine, the code works fine and returns the proper share count. However, if I run the code on my actual server (an AWS EC2 instance), the share count shows zero.
If I open Chrome and run the request from the browser, the share count displays as expected.
If I open Internet Explorer 11, and run the request from the browser, the counter shows zero. HOWEVER, if I log in to Facebook from IE11, and then run the request to FB Graph API, the response shows the correct page count.
This is very confusing to me, as it appears the reason the counter has stopped working, has to do with cookies, or maybe the browser being logged into FB. This should not be the case as I am using an APP token ID, and I wouldn't expect to need to be logged into FB in order to make a request to Graph API.
Does anybody have any ideas why my request/code in .NET worked just fine for a year and a half, and just stopped working? Or why the requests work fine on my localhost and not my live server?
After spending considerable time on this issue, I have fixed the issue. There is a FB authentication cookie that was being transmitted through a web browser query. The cookie name was "XS" and the value was a long string that is used as a sessionId for my specific login. If I created this cookie in my web request in C# code, I get the proper response with correct # of shares.
WebClient client = new WebClient();
client.Headers.Add("Cookie", "xs=<removed>;");
I have no idea why I have to do this, only on my EC2 server. Nowhere in FB's documentation does it say you have to spoof a valid logged in authentication string cookie in order to obtain correct Share Count results from a request to it's Graph API, but there you have it. A workaround at least.
I am using azure app service and DB for my C# ODATA API and DB as the backend of of my phone app.
I only have one app service that hosts 10s of endpoints. There are times when I need to publish new versions and I don't want any incoming requests during that time of deployment.
I don't mind that users are not able to finish their requests during the maintenance.
Is there anything in Azure or API that can let me:
1. turn off the api/app service manually?
2. Be able to inform the user that a maintenance is in progress?
This is my trial:
the only thing I can come up with is this. While users always use the "odata" in their url requests: https://myserverl/odata/Users
which is setup in the webapi.config like this:
config.MapODataServiceRoute("odata", "odata", builder.GetEdmModel());
I put the routePrefix (2nd odata) in a web.config.
When I need to turn off access, I change my web.config (which I can access manually even after the publish of code into Azure) to be like this:
<add key="odata" value="noaccess" />
and in my webapi.config:
string odata = ConfigurationManager.AppSettings["odata"].ToString();
config.MapODataServiceRoute("odata", odata, builder.GetEdmModel());
and then save the web.config which will reset the server and all incoming requests that has "odata" will result into error. I can always set it back later.
This method will stop the users from sending requests during maintenance but will not let them know what is going on.
I figured it out.
when I call the server from my client, I verify that the response is between 200 & 299 before parsing results or any other further processing.
So now, I check also for the possible response from the server that it could be either 403 (access is denied) or 503 (server is unavailable). That's where I can add code to notify the user.
In Azure, simply stopping the app service, will generate one of those 2 error codes.
Note: You must check for both: 403 & 503.
I am developing a WP application for which the webservices are implemented in .NET using SOAP client. I have implemented the SOAP client in my WP app using "Add service reference" option.
Now the problem is, there are two different client classes one for the Login functionality and the other for all other queries. Login is working fine and returning me true or false and nothing else. And the other client class is used to make different queries which are all working fine and getting some data from server. After testing I observed that the response is independent of the logged in user( ie server sending same data irrelevant of the logged in user). And hence it is clear that the session is not maintained and the server is sending some anonymous data.
Some one help me on how to maintain the session in the SOAP client.
Note: I cannot ask the web service providers on this. :(
Finally I figured out how to maintain cookie based session in Windows phone apps
Thanks to Mike for his guidance.
For all those who are wondering about the different ways of maintaining session in WP app,
there is a class called CookieContainer which helps to maintain cookie data for us.
Usage:
First create a global instance of CookieContainer class ( I created in App.xaml.cs)
//In App.xaml.cs
CookieContainer cookieContainer = new CookieContainer();
And then assign it to every request we make to the server from our app.
MySoapClient client = new MySoapClient();
client.CookieContainer = (App.Current as App).cookieContainer;
client.LoginAsync("username", "password");
Again for any other request in the app
MyOtherSoapClient anotherClient = new MyOtherSoapClient();
anotherClient.CookieContainer = (App.Current as App).cookieContainer;
anotherClient.PostDataAsync("somedata");
The same rule also applies for normal WebClient and HttpWebRequest classes also.
Happy Coding :)
I'm working on a small SilverLight application, which uses the WebClient to request a REST service. According to this:
http://msdn.microsoft.com/en-us/library/dd920295(v=vs.95).aspx
no caching should be in place when using the 'Client HTTP' handling....
The REST service I'm calling use ETag, so with no Caching in place, I would not expect, that a second call to my service, would contain the If-None-Match header ??
Also when the REST service returns '304' (NotModified) I still get some data, indicating that the data is returned from the cache....
The REST service also sets the 'Vary' header to 'Accept' (so that the Accept header, should be taken into account when generating the Cache key), but is doesn't seem like this is working....
So I'm a bit confised, whether the caching is there or not.... seems like it's half-ways there...
Can someone clearify??
TIA
Søren
I would suggest not using ETags on a WCF service. In IIS, the service or the directory containing the service needs to include an HTTP response header setting the content to expire immediately so that there is no possibility of caching on the client. This way a call to the service will not result in an HTTP 304 response from the server.
I am using a WCF service client generated by slsvcutil form Silverlight toolkit version 4. I've also tried version 3 with the same problems. When I use a client instance running on http with no user credentials it runs without problems. But I need to switch to https for productive servers and send user credentials that are hardcoded for my application. I use the following code for that:
var binding = new BasicHttpBinding (BasicHttpSecurityMode.TransportCredentialOnly);
var endpoint = new EndpointAddress (AppSettings.FlareEndPoint);
_service = new TopicAnalystAPIClient(binding, endpoint);
_service.ClientCredentials.UserName.UserName = "xxx";
_service.ClientCredentials.UserName.Password = "xxx";
When I call a method on that service pointing to http with no authentication it works. When I use the this code against http/https with the credential I get "There was an error on processing web request: Status code 401(Unauthorized): Unauthorized" exception. I've checked that the credentials are correct, I am able to open the service reference in my browser. I've also tried several combinations of http/https and SecurityMode value. I've also tried it on four different servers always with the same result.
What can be the problem?
A lot of permutations are possible. BasicHttpSecurityMode.TransportCredentialOnly should be usable without SSL [1] using HTTP itself. This means the server will send one (or more) authentication method(s) to the client (e.g. basic, digest, ntlm) and Mono (including MonoTouch) should be providing support for the most of them.
It is possible that the linker (if used) removes one of them. In that case you could try building and testing without linking (or skip linking of System.Net.dll).
It's also possible that the authentication method that the serve insist on is not supported. You could find which one is used by running a network trace (e.g. wireshark) or, maybe, it will show up in more details in the server log (along with the 401 error).
[1] http://msdn.microsoft.com/en-us/library/system.servicemodel.basichttpsecuritymode%28v=vs.95%29.aspx