I'm trying to call a Restful service from a Silverlight 4 Out of browser application using the ClientHttp Stack.
var request = (HttpWebRequest)HttpWebRequest.Create(uri);
request.BeginGetResponse(new AsyncCallback(ExecuteResponseCallback), state);
The service i'm calling takes upto 20 seconds to respond after receiving the request, but it seems that the callback method is fired after around 10 seconds. I can see in Fiddler that the service does finally complete the request after a total of 30 seconds with a 200 Response code, but the HttpWebRequest callback has already received a 404 Not Found response.
I can't see any reason why this should happen, there is no Timeout property on the HttpWebRequest in Silverlight, so I cannot understand why the request does not wait indefinitely for the response.
Is there something I'm doing wrong?
After a little more testing it turns out the callback is fired at exactly 10 seconds. It turned out to be caused by the registry key
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ReceiveTimeout
Installing IE9 64bit seems to be the culprit, as well as some other applications that modify this value. The solution was simply to delete this registry key and all is well.
The problem is also described here Silverlight ClientHttp WebRequest timeout
Related
I have a very simple Azure Logic App that makes a REST call to an SAP web server and translates the response JSON before sending a response back to the caller of the Logic App. What is baffling me is that when the SAP call takes just over 1 minute, the Response action throws this error:
ActionResponseTimedOut. The execution of template action 'Response' is
failed: the client application timed out waiting for a response from
service. This means that workflow took longer to respond than the
alloted timeout value. The connection maintained between the client
application and service will be closed and client application will get
an HTTP status code 504 Gateway Timeout.
According to Microsoft documentation, the time-out HTTP calls is supposed to be 120 seconds (2 minutes). Unless the Logic App history display is completely wrong, the entire Logic App never takes any where near 120 seconds to complete, it keeps failing at just over 60 seconds.
The SAP GET CustomerCredit action shown in the sample below is a Logic Apps Customer Connector, not the built-in SAP action. The Logic App is the current production version, not a preview version.
Am I doing something wrong? I'd be fine if the Logic App actually timed-out after 2 minutes, but a 1 minute time-out is a bit extreme.
I don't know why your logic app shows ActionResponseTimedOut error even if it doesn't execute more than 120 seconds. I test it in my side and it works fine it the execution time less than 120 seconds. Here I can provide a workaround which may help with your problem.
1. Click "..." --> "Setting" of your "Response" action.
2. Enable "Asynchronous Response"
3. Then when you request the url of logic app, it will response with 202 accepted immediately. And in header of the response, we can find a "Location".
4. Request the url in "Location", it will response you with the result of the logic app(if the workflow is completed). If the workflow hasn't been completed, it will still response 202.
We have a web application (UI wrapped in CEF + WPF) where we make a JavaScript POST request to the server. The POST request only has query string parameters and no request body. The server takes up to 5 minutes to process and send a small response back. Even when the server sends the response back (lets say 4 minutes), the request is still shown as pending in the Inspector (and success callback is not executed). Only after 8-10 minutes the response is shown as complete (and success callback is executed).
When we check the time distribution of the finished request call, it says that everything finished in 4 minutes which is very strange. This behavior is not happening in Google chrome browser. Any advise on what could be going wrong.
I am encountering a problem with Angular 1.5 and I could not find a similar question via Google. For a welcome change, the problem does not exist in IE, it only happens in the latest version of Chrome.
When I approach a JSON API and I send the same GET request twice in a row, the first request returns a 200 OK and the second returns a 304 NOT MODIFIED. I am doing the request with 'Cache-Control': 'no-cache' to simulate how our (generated) API client performs requests. With cache control enabled, both requests are executed correctly (see F12) and the program terminates. With cache control disabled, both requests are executed correctly (F12) but the program does not terminate.
Is this a bug in Chrome, or a bug in Angular's $http, or am I missing some crucial detail?
Minimal example on JsFiddle
Output:
Hi
Sending request 1 to http://jsonplaceholder.typicode.com/posts/1...
Success 1!
Resolved 1!
Sending request 2 to http://jsonplaceholder.typicode.com/posts/1...
Fixed after a Google Chrome update.
Using the following two calls for identical resource:
var p1 = Restangular.one('accounts', 123).one('buildings', 456).get();
var p2 = Restangular.one('accounts', 123).one('buildings', 456).get();
Will Restangular send a single GET to the server or two? Is Restangular smart enough to know that there is already a request out to this resource when the second get() is issued?
Edit:
Chrome shows only one request go out, but I'm still not sure if this is implemented in Restangular or in the browser?
If you add a Cache, it'll also work on IE10 as that URL and its response would be cached.
After further investigation is seems that Restangular does not implement a feature to limit requests for same resource. The number of requests that go out to the server is dependent on the browser: Chrome only sends out only one GET request, IE 10 sends out two.
We have a problem with HTTP Response caching when using WCF RIA Services with Silverlight.
Server side, we have a simple DomainService GET method with no caching specified, like this:
[OutputCache(OutputCacheLocation.None)]
public IQueryable<SearchResults> GetSearchResults(string searchText);
The throws a DomainException when the user is not authenticated (i.e. when the FormsAuthenticationCookie expires). This is as designed.
But when the user is re-authenticated, and the Query is called again with the same 'searchText' parameter, then the Query never gets to the server (no breakpoint hit; Fiddler shows no http request sent).
I think this is because when the exception is thrown on the server, the HTTP Response has the 'Cache-Control' property set to 'private', and when the client wants to perform the same query later (once the user is logged in), then the browser does not even send the request to the server.
If we enter a different search parameter, then the query is re-executed no problem.
Is there any way of ensuring the http response always has 'no-caching' - even when it does not return normally?
UPDATE1
The problem only occurs when deployed to IIS - when testing from Visual Studio with either Casini or IIS Express it works fine.
UPDATE2
I updated the question to reflect new knowledge.
You shouldn't be throwing a DomainException for authorization errors. Due to the way Silverlight handles faults, these responses can still be cached by your browser. Instead, throw an UnauthorizedAccessException from your DomainService and that should fix the caching error on the client.