There is some very strange behavior of the same request on Chrome and Firefox.
I have one button that triggers POST request to a Spring-boot backend, it's kind of long-running, takes ~5-6min.
On Chrome, there are no issues and every time I get the expected response for the above-mentioned time(5-6min), and only 1 request is received by the backend.
On Firefox on the other hand I make the same POST request through that button and the strange thing is that the request stays blocked for 6mins and after that is somehow retriggered. This happens 9 out of 10 times.
This results in 2 requests made to the backend from a single request in the frontend.. at least this is what it looks like from the logs that I put in the backend.
The second request starts exactly after the block time.
There aren`t any other XHR requests being executed at the same time.
Below is a screenshot of how it looks:
Does anyone have any idea what might cause this behaviour on Firefox?
I have a navigation.sendBeacon request being sent during a pagehide event on Safari with some analytics data to an endpoint on the same domain as the current page. This works fine when the tab is being closed, but when navigating to a new url, Safari throws Beacon API Cannot load <url> due to access control checks while trying to make the request.
This issue does not occur on Chrome, and there are no other logs shown. I don't think this is a CORS request, all domains and subdomains are the same.
Has anyone else seen this or know how to fix?
Using any sort of Asynchronous HTTP request, whether it is sendBeacon, fetch, or XMLHttpRequest seems to have problems in both desktop and iOS Safari at the moment when inside a pagehide event. I have received versions of the same error such as Fetch API cannot load ... due to access control checks when I use different types of HTTP requesters within the pagehide event. I am sure that it is not a CORS error, since the exact same request does not have a problem outside of a pagehide event.
While not recommended due the its blocking of the main thread, I am using synchronous requests until the bug is patched in Safari. For my use case, it is more critical that the analytics data from pagehide is successfully sent even even though it causes a small delay to the end user. Synchronous HTTP requests are a meh workaround until the bug is remediated, which hopefully is soon since the link from #Phillip Walton suggests that a patch has been accepted but obviously has not been released yet.
if (isSafari && pageHideBroken) {
$.ajax({
type: "POST",
async: false, //The most important line
url: `https://`,
data: 'Goodbye',
timeout: 5000
});
}
else {
navigator.sendBeacon(`https://`, 'Goodbye');
}
I have confirmed that on both Desktop Safari and iOS Safari that my backend successfully receives the data using this approach. JQuery is not required to make a sync HTTP request, but I just used $.ajax as the example due to its conciseness compared to XMLHttpRequest. If you make this workaround conditional like I have, then it is easy to swap back to navigator.sendBeacon once the bug is fixed! This type of browser-dependent behavior is never fun to code around.
I keep receiving this error when I do some Ajax calls...
It may even be something to do with Geocoding but I really have no idea how to capture the error to display something useful to users... or even how to solve the problem as it seems to just be referencing some kind of pointer or something :S 0x2ef3
SCRIPT7002: XMLHttpRequest: Network Error 0x2ef3, Could not complete the operation due to error 00002ef3.
An image might be more helpful than the error message:
Any ideas at all?
My code fires off 10 ajax calls in 1 second to be processed by geocoding server side.
The error comes up intermittently. Sometimes I get geocoded results and sometimes I get that error. I would say I get it 10% of the time. It completely stops the ajax call from firing my error handler in jQuery.
This is the fix that worked for me. There is invalid mime or bad characterset being sent with your json data causing that errror. Add the charset like this to help it from getting confused:
$.ajax({
url:url,
type:"POST",
data:data,
contentType:"application/json; charset=utf-8",
dataType:"json",
success: function(){
...
}
});
Reference:
Jquery - How to make $.post() use contentType=application/json?
Could not complete the operation due to error c00ce56e
We also encountered similar problems. However, setting the charset as noted in the previous comment did not help. Our application was making an AJAX request every 60 seconds and our webserver, nginx, was sending Keep-Alive timeout at 60 seconds.
We fixed the problem by setting the keep-alive timeout value to 75 seconds.
This is what we believe was happening:
IE makes an AJAX request every 60 seconds, setting Keep-Alive in the request.
At the same time, nginx knows that the Keep-Alive timeout value is ignored by IE, so it starts the TCP connection close process (in the case of FF/Chrome this is started by the client)
IE receives the close connection request for the previously sent request. Since this is not expected by IE, it throws an error and aborts.
nginx still seems to be responding to the request even though the connection is closed.
A Wireshark TCP dump would provide more clarity, our problem is fixed and we do not wish to spend more time on it.
I received the same error (SCRIPT7002: XMLHttpRequest: Network Error 0x80004004, Operation aborted), in our case it was because of JavaScript's same origin policy.
Our web app was making a JQuery AJAX call to our server on Port 8080. The call was getting intercepted and re-routed over SSL (due to server rules mandating that incoming traffic use SSL).
Once we made our web app load through the SSL port the issue was fixed.
I had this problem, a an AJAX Post request that returned some JSON would fail, eventually returning abort, with the:
SCRIPT7002: XMLHttpRequest: Network Error 0x2ef3
error in the console. On other browsers (Chrome, Firefox, Safari) the exact same AJAX request was fine.
Tracked my issue down - investigation revealed that the response was missing the status code. In this case it should have been 500 internal error. This was being generated as part of a C# web application using service stack that requires an error code to be explicitly set.
IE seemed to leave the connection open to the server, eventually it timed out and it 'aborted' the request; despite receiving the content and other headers.
Perhaps there is an issue with how IE is handling the headers in posts.
Updating the web application to correctly return the status code fixed the issue.
Hope this helps someone!
This issue happened in my project because of an ajax GET call with a long xml string as a parameter value. Solved by the following approach:
Making it as ajax post call to Java Spring MVC controller class method like this.
$.ajax({
url: "controller_Method_Name.html?variable_name="+variable_value,
type: "POST",
data:{
"xmlMetaData": xmlMetaData // This variable contains a long xml string
},
success: function(response)
{
console.log(response);
}
});
Inside Spring MVC Controller class method:
#RequestMapping(value="/controller_Method_Name")
public void controller_Method_Name(#RequestParam("xmlMetaData") String metaDataXML, HttpServletRequest request)
{
System.out.println(metaDataXML);
}
I had this error for some time and found a fix. This fix is for Asp.net application, Strange it failed only in IE non compatibility mode, but works in Firefox and Crome. Giving access to the webservice service folder for all/specific users solved the issue.
Add the following code in web.config file:
<location path="YourWebserviceFolder">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
I have stumbled across this questions and answers after receiving the aforementioned error in IE11 when trying to upload files using XMLHttpRequest:
var reqObj = new XMLHttpRequest();
//event Handler
reqObj.upload.addEventListener("progress", uploadProgress, false);
reqObj.addEventListener("load", uploadComplete, false);
reqObj.addEventListener("error", uploadFailed, false);
reqObj.addEventListener("abort", uploadCanceled, false);
//open the object and set method of call (post), url to call, isAsynchronous(true)
reqObj.open("POST", $rootUrlService.rootUrl + "Controller/UploadFiles", true);
//set Content-Type at request header.for file upload it's value must be multipart/form-data
reqObj.setRequestHeader("Content-Type", "multipart/form-data");
//Set header properties : file name and project milestone id
reqObj.setRequestHeader('X-File-Name', name);
// send the file
// this is the line where the error occurs
reqObj.send(fileToUpload);
Removing the line reqObj.setRequestHeader("Content-Type", "multipart/form-data"); fixed the problem.
Note: this error is shown very differently in other browsers. I.e. Chrome shows something similar to a connection reset which is similar to what Fiddler reports (an empty response due to sudden connection close).
Also, this error appeared only when upload was done from a machine different from WebServer (no problems on localhost).
I just want to add what solved this problem for me, as it is different to all of the above answers.
The ajax calls that were causing the problem were trying to pass an empty data object. It seems IE does not like this, but other browsers don't mind.
To fix it I simply removed data: {}, from the ajax call.
With the Apache 2 change KeepAliveTimeout set it to 60 or above
Upping the directive in the virtualhost for KeepAliveTimeout to 60 solved this for me.
Have encountered the same issue in my asp.net project, in the end i found the issue is with the target function not static, the issue fixed after I put the keyword static.
[WebMethod]
public static List<string> getRawData()
Incase none of these solutions were "clear" enough, essentially IE/Edge is failing to parse your "data" field of your AJAX call properly. More than likely you're sending an "encoded" JSON object.
What Failed:
"data": "{\"Key\":\"Value\"}",
What Works:
"data":'{"Key":"Value"}'
[SOLVED]
I only observed this error today, for me the Error code was different though.
SCRIPT7002: XMLHttpRequest: Network Error 0x2efd, Could not complete
the operation due to error 00002efd.
It was occurring randomly and not all the time. but what it noticed is, if it comes for subsequent ajax calls. so i put some delay of 5 seconds between the ajax calls and it resolved.
I am working with cross-domain remote resources that require locking. CORs headers are set appropriately.
I am trying to solve the case where the resource is not released by the client (remains locked until the lock expires) when the browser window is closed.
I had hoped to send a synchronous DELETE request on window unload. I am using jquery (answer can be plain javascript if necessary... mentioning jquery for context) and noticed their docs say "Cross-domain requests ... do not support synchronous operation" and I became very sad.
Is it possible to make a synchronous cross-domain ajax request? Is the jquery limitation due to older browsers? Everything I've read indicates the unload event listener will not be around long enough for the ajax call to complete if it is async and suggests using a synchronous request for this type of cleanup. Unfortunately the call is cross-domain... what can I do?
EDIT
So I am curious if I am getting lucky during local development (i.e. client on 127.0.0.1:8080 and api on 127.0.0.1:8081) or the jquery docs are just misleading. Will the following end up causing me problems down the road?
This appears to be working in Chrome45:
var unload_event = "unload." + lock.id
function release_lock(sync) {
$.ajax({
method: "DELETE",
async: !sync,
data: lock,
url: lock.url,
error: function(){
console.log("failed to release lock " + JSON.stringify(lock));
},
success: function(){
console.log("lock " + lock.id + " released");
lock = null;
$(window).off(unload_event);
}
});
}
$(window).on(unload_event, function(){
release_lock(true);
});
It does generate the following warning in the console:
Synchronous XMLHttpRequest on the main thread is deprecated because of
its detrimental effects to the end user's experience.
For more help, check http://xhr.spec.whatwg.org/.
I would avoid doing this in the unload event due to the fact that synchronous ajax is the only way that will work, and synchronous ajax requests are deprecated in some modern browsers.
Alternatives include:
keepalive requests
This would involve periodically sending a request to the server indicating that the user is still editing the resource. The downside to this technique is that the resource will remain locked until the timeout happens, so if you're keepalive is set to an interval of 1 minute with a 3 minute lock timeout, it will remain locked for up to 3 minutes after the user has left the page. Additionally, if the user loses network connection for 3 minutes or longer, it will also become unlocked.
websockets
This would create an open connection between the client and the server, and while this connection is open, you can keep the resource locked. As soon as the client disconnects, you can assume that the client has closed the page and unlock it. The downside here is if the client loses network connection, it will also become unlocked.
On my web page it is possible to send ajax requests and then jump to another page meaning that the AJAX requests are irrelevant and are aborted by the browser. The return from one of these jquery AJAX requests to an error handling might be:
readyState = 0
responseText: ""
status=0
But, note the error handler may not be even invoked. It depends when the browser aborts the request and when the user selects to go onto another page. If it is invoked it is invoked with the above parameters.
Here is where it gets juicy. A similar response happens when a 302 redirect is returned from an AJAX request when the location is set to another domain. The browser (both IE And FF) mangle the 302 and invoke the error handler with the same info:
readyState = 0
responseText: ""
status=0
I know it is a 302 with location set to another domain from using fiddler. But take fiddler away and all you see is above.
I need to be able to differentiate between
ajax requests that are aborted because user goes to another page
ajax requests that are aborted because they are redirects to another
domain
But I can't if I get the exact same info for both.
Any tips? Could I check a window object or something else in the DOM? Note: I can't predict when a request will return a 302. I also can't see the location header server side.