I have a Net Core application that started to present a few problems lately. It was working just fine, but recently my Ajax calls will throw a 401 error.
That just happens in the production server, running on localhost everything works just fine. Also, this appears to be happening randomly, so the same ajax call will sometimes throw this error and sometimes it won't.
After digging a lot I noticed a few differences between the headers of those calls when they run local and when they run on the production server, but I don't know exaclty how to interpret and solve them.
Could you help me? None of those calls are to an external API/resource, they all call the page the user is currently on in the app itself.
I'll add the screenshot of the console showing the difference between headers. On the left is the one running local and I've used exactly the same data on both tests.
The production server is running IIS 10, if that's relevant.
Related
As can be seen in the title, when I run the example of physiJS (from github repo) it show only background, fps counter, but no physiJS functionality at all (pure three.js works fine). When I run on the: http://chandlerprall.github.io/Physijs/examples/vehicle.html everything runs ok. I have no idea right now where to start looking and where the problem is. Any ideas of what the cause could be?
PhysiJS uses a web worker to run the updating functionality, and web workers are not allowed on local systems as they require the loading of additional resources through JavaScript (and this is not allowed by cross-origin policies on some browsers). It's related to your browser, on my mac Safari allows it, but Chrome throws an error:
Uncaught SecurityError: Failed to construct 'Worker': Script at 'file://physijs_worker.js' cannot be accessed from origin 'null'.
The worker is required to run PhysiJS, so you should use a local server like MAMP to test it on your local machine.
I am currently using SignalR 2.0 and MVC 5.0 for my project. All the signalR update works fine except when I have updated the web.config file which causes the application pool to recycle. This is the starting point I notice SignalR behaving inconsistently. Sometimes I need to perform an action multiple times before the SignalR update can be propagated to the client. I have enabled the SignalR logging and I can't see anything displayed in the log whenever it failed to propagate to the client.
Do we need to do something in the hub, like reconnect or anything when the app pool got recycled?
At the moment, i didnt do anything in terms of coding and simply refresh the page. But it gives me that problems with SignalR. And the only way to fix that intermittent problem completely is to reboot the server.
Have anyone experienced this kind of behavior in SignalR?
Thanks in advance.
I've got my Web API interface working fine but after a fairly short period, like around 5 minutes, it gives a 500 Internal Server Error on the first call and then works fine again until it times out. I'm not getting any additional information on the error message and there's nothing going to the logs. I don't have the issue on my development machine, just on the live server. Any ideas what might be causing this? How can I get additional error information on a live server?
The simple answer to this was set Custom Errors Off within the Web.config file. That gave a very useful error that made it easy to track down the problem.
Sometimes, perhaps once every few hundred AJAX requests and/or where AJAX requests are executing in quick succession, I've seen a request hang for up to several minutes before it completes. The weird thing is that the request completes successfully AND neither my machine or the server are really doing anything either (e.g. CPU and other resources are not spiking during the "hang").
I've noticed this issue with various web services too, so it isn't just my own website. It also isn't database related as it has happened on non-database sites. It also only seems to show up in non-localhost environments.
When I personally use AJAX, I am also using jQuery, so this might also be a jQuery issue. I also mostly use Firefox, so I don't know if this is just a Firefox issue or if it is an issue any browser could have. I've run into the issue on multiple computers in multiple locations.
If you have run into this issue before and "fixed" it, I would appreciate the solution you came up with.
Use a HTTP debugger like Firebug or Fiddler to track the AJAX requests to see how much time it takes (possible timeout issue due to server setting?) & what HTTP response status code it returns when it fails. Use the HTTP response status code to troubleshoot the issue.
Does anyone know why a synchronous ajax call would fail and give the following error on Safari on an iPad, but the same code works fine on all other platforms and browsers I've tested so far?
NETWORK_ERR: XMLHttpRequest Exception 101: A network error occurred in synchronous requests.
That error suggests that I'm attempting a cross-domain request, but I'm not; the requested URL is on the same host, and in fact it's a relative URL. Even in trivial tests, this fails on the iPad (and works on all other platforms and browsers, including Safari), so I'm confident I've ruled out any possibility of a time out.
Also, the same request, if made asynchronously, works perfectly on the iPad; it's only synchronous requests that give the 101 exception. It's driving me crazy!
One more bit of detail: this only happens on my production server. The synchronous ajax call actually works fine on my development server. Both servers require the same client certificate... so I don't think there's any difference there. I can't think of any difference between the two servers that could have an effect here.
Any insight into this problem would be greatly appreciated. Thanks!
It turns out the key difference between our development and production systems is the certificate requirement.
The issue turns out to be a problem with the way XMLHttpRequest.send() on the iPad version of Safari processes a synchronous request on a domain that is certificate-protected. I can't explain the internals of the method, but somehow it has a problem and throws the 101 exception, believing it--apparently--to be a cross-domain request. Again, the same request made asynchronously on the same certificate-protected server works just fine. Frustrating case, and one with no solution!