We Keep Coding

JQuery $.get in IE and Edge not firing

In our web application we want to trigger a locally run widget using xhttp request, in Chrome and firefox, this is working fine and the requests are being received but in MS browsers (Edge and IE11) it wort fire and I get an error returned to the variable,
The request line is;
var screenRecorder = $.get('http://127.0.0.1:9645/widget?command=connect&agent=amtest&password=amtest');
where agentName and password are taken from JS variables
[object,object] {readystate:1}
I am relying on the correct response being received to flag if the widget is running to allow further communication requests to it.
I am hosting the app on IIS6.1 and have enabled CORS but this still isn't helping with IE and Edge. Can anyone advise how I can resolve this?
The IE console shows the following error:
XMLHttpRequest: Network Error 0x2efd, Could not complete the operation
due to error 00002efd.

The fix for this issue is to initiate a connection before sending the request using the following code before sending the initial and subsequent $.get requests;
var screenRec = new XMLHttpRequest('http://127.0.0.1:9645/widget');
This forces IE and Egde to open the connection as without it the $.get request will not be sent.

Intermittent jQuery failure in Chrome extension

I'm seeing a strange issue (only in production of course) where some $.post requests are failing intermittently with the error:
{"readyState":0,"status":0,"statusText":"error"}
I've looked into this and in most cases there seem to be two possible issues:
1) Cross domain errors. This shouldn't be an issue since the chrome extension is set up to be able to access the domain, additionally since it only fails sometimes this seems like it shouldn't be the issue
2) not calling e.preventDefault(). The request is being made from the background process so i don't think this is the issue. Again the fact that it is intermittent makes this unlikely.
Additionally it seems UNLIKELY that its purely network related since the only way we know about these issues are posting to an endpoint on our server to retrieve the errors...i.e. if the computer was offline, the request sent in the failblock should fail as well.
Are there any other known issues that could cause the query to fail with that error?
UPDATE
Here's some pseudo code for the way the request is made:
$.post(this._baseUrl + "/my_endpoint", JSON.stringify(data))
.done(function(res){
//SUCCESS!
})
.fail(function(error, textStatus, errorThrown) {
//{"readyState":0,"status":0,"statusText":"error"}
}.bind(this));

Cross domain XHR works strange

I've been stacked with issue which I can't solve
for about month. You can look at the example page here: http://www.7ya.ru/travel/tours/
So, the problem is that little green form is our widget which uses cross-domain XHR and
some people have problem with it. XHR request fails. There is no request exactly. Inspector
just says "canceled". This problem occures in FF, Opera and Chrome on OSX and Win.
BUT! If you'll try to clean cache (for example in Chrome):
you will see that the widget is starts to work like a charm.
Also if you'll try to clean only a cache it wont work.
So, is anybody has ideas about which data may affect XHR requests in most browsers on two different platforms?
P.S. I've been trying to use "vanilla" XHR and jQuery version but it works same.
P.S.S. Bit of code (CoffeeScript):
lt_jq – local jQuery version ($.noConflict())
#inspect - JSON.stringify() with some additional params for formatting
request = lt_jq.ajax({
url : method,
dataType : "json",
data : params,
xhrFields : withCredentials:true
})
request.done (data)->
#request_id = (data.request_id || null)
callback?(data)
request.fail =>
console.log "Request failed [#{method}], #{#inspect(params)}"
QUESTION CLOSED, DETAILS IN COMMENTS

Does the network you're in use a caching proxy, or from the sound of it, do you have an antivirus or some sort of filter on the network which filters the requests through?
It sounds like the files are being cached without the correct headers, so the CORS headers are being cut off...
The easiest way I suggest you check this:
USING CHROME:
Clear your cache, open the dev tools, and watch the request when it
does work. Make sure you have the CORS headers in the request and response headers.
Now that you have the file in your cache, reload your page. Check that it's not working.
Now that it doesn't work, go to chrome://view-http-cache/ to view the individual cache
entries, and look for that file's request. Open it.
Check if the cached file has the CORS headers on it.
If it doesn't... make sure the proxy/antivirus doesn't cut off the CORS headers in your network, or try a different solution

AngularJS and Apiary.IO - can't read any response headers?

I mocking my API using Apiary.io. But somehow I cannot read any headers from response object using angularJS. And I am sure i have at least Content-Type: application/json correctly set-up by checking in firebug. Code in Angular should read headers correctly too as i can print them when sending request to somewhere else than apiary.io...
$http.get('http://ies.apiary.io/some').then(function(response) {
console.log("ok",response.headers('Content-Type'));
},function(response){console.log("err",response);});
http://plnkr.co/edit/zMO0pXGsIdJkV0fZdBdw

It all boils down to a bug in firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=608735
For CORS request, firefox is not returning anything for req.getAllRequestHeaders(), although req.getRequestHeader('Content-Type') returns properly.
Either FF bug has to be fixed or Angular must work around it (as jQuery does) or you must go deeper and use XmlHttpRequest instance directly.
This was maybe also related, but probably not the core issue:
However, few days ago, Apiary.io was not setting Max-Age in CORS headers. Thus, if you had a minimal blueprint, you might have CORS pre-flight response cached and thus subsequent requests may be disallowed even if you added additional resources to your blueprint.
Max-Age is now set to 10 seconds, so it should work properly. However, depending on your browser, pre-flight cache might still affect you. Try purging it or test this app in another browser.

Firefox redirect response on xhr request

Suppose we have the xhr 'POST' request that returns 'redirect' status code.
In that case browser is sending additional xhr 'GET' by the given URL.
I am not sure who is doing that call chain: browser itself or js library(using MooTools).
The problem is that the second 'GET' request is not recognized as xhr by the server:
It doesn't have "X-Requested-With" header contains "XMLHttpRequest"
The problem appears only on Firefox, but not on Webkit. So, believe it is not related to js library bug.
Does anyone have ideas how to fix it?

The XHR/browser follows redirects internally.
Apparently firefox is not forwarding non-standard headers?
Sound like you should report a bug to BugZilla