We Keep Coding

Web worker importScripts DOMException script failed to load

I'm trying to use importScripts
self.addEventListener('fetch', event => {
...
self.importScripts('idb.js');
...
}
to load a library for a service worker for a PWA but keep getting
DOMException: Failed to execute 'importScripts' on 'WorkerGlobalScope':
The script at 'http://localhost:3000/idb.js' failed to load.
The script file is there, content type is correct, application/javascript, and I've tried it with text/javascript too. My developer tools network tab shows the request starting and then failing really quickly, not getting a chance to hit the server. The status code is (failed) net::ERR_CONNECTION_REFUSED when over http and (failed) net::ERR_FAILED over https. Any help appreciated

According to https://developers.google.com/web/updates/2018/10/tweaks-to-addAll-importScripts
Prior to Chrome 71, calling importScripts() asynchronously outside of the install handler would work. Starting with Chrome 71, those calls throw a runtime exception (unless the same URL was previously imported in an install handler), matching the behavior in other browsers.
I have to move importScripts to the top level of my file or my install handler and it works

Based upon the link you provided, you are not running under HTTPS. You need a site under HTTPS to use a service worker.
My original post wrong. #kmanzana pointed out that localhost is considered a "secure origin".

Also, if there is an import statement inside any of the scripts on which you are using importScripts(), you will get this error, and it will not immediately be clear why you are getting it. Caveat emptor.

Beacon API Cannot load <url> due to access control checks when navigating to new page

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.

Ajax chat program errors when retrieving messages [duplicate]

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.

Same Origin Policy For Classic ASP to ASP.NET 4.0

I am using a classic asp site to call an ASP.NET 4.0 Http handler. These are both deployed on the same server. I am attempting to make a jquery 1.6 AJAX call to the handler. In IE, I always get an error of "No Transport". In Firefox and Chrome, the request goes through without any problems. Some searches on the "No Transport" error lead me to believe that the problem is related to the same origin policy.
According to https://en.wikipedia.org/wiki/Same_origin_policy, it doesn't seem like I should be having any trouble with the same origin policy. Both have the same domain, protocol and use the same port number, so the origin should be considered the same between the two.
$.ajax(
{
url: "/filehandler/DeleteHandler.ashx",
data:
{
data: someData
},
success: OnSuccessFunction,
error: OnErrorFunction
});
Every time this AJAX call is made in IE, the OnErrorFunction callback function gets called with an error on "No Transport".
Any ideas?

See the link below for the solution. We had to add this line get it working, which implies that it was in fact a same origin policy issue:
jQuery.support.cors = true;
This still doesn't answer the question of "Why does it think there is a violation of the same origin policy?" but we are just happy to have it working.
Answer:
jQuery Call to WebService returns "No Transport" error

JSONP callback doesn't execute when running at localhost

This is bizarre, I was wondering if anyone could shed some light on why this happened.
Basically, I've been pulling my hair out trying to test JSONP out so I can implement a JSON web service that other sites can use. I'm doing development on localhost--specifically, Visual Studio 2008 and Visual Studio 2008's built-in web server.
So as a JSONP test run w/ jQuery, I implemented the following:
$().ready(function() {
debugger;
try {
$.getJSON("<%= new Uri(Request.Url, "/").ToString() %>XssTest?callback=?", function(data) {
alert(data.abc);
});
} catch (err) {
alert(err);
}
});
And on the server ..
<%= Request["callback"] %>({abc : 'def'})
So what ends up happening is I set a breakpoint on the server and I get the breakpoint both on the first "debugger;" statment in the client-side script as well as on the server. The JSONP URL is indeed being invoked after the page loads. That's working great.
The problem I was having was that the callback would never execute. I tested this in both IE8 as well as Firefox 3.5. Neither one would invoke the callback. The catch(err) was never reached, either. Nothing happened at all!
I'd been stuck on this for a week, and even tested with a manually keyed HTTP request in Telnet on the specified port to be sure that the server is returning the format...
callbackfn({abc : 'def'})
.. and it is.
Then it dawned on me, what if I change the hostname from localhost to localhost with a globalizer ('.'), i.e http://localhost.:41559/ instead of http://localhost:41559/ (yes, adding a dot to any hostname is legal, it is to DNS what global:: is to C# namespaces). And then it worked! Internet Explorer and Firefox 3.5 finally showed me an alert message when I just added a dot.
So this makes me wonder, what is going on here? Why would late script tag generation work with an Internet hostname and not with plain localhost? Or is that the right question?
Clearly this is implemented for security reasons, but what are they trying to secure?? And, by getting it to work with a dot, did I just expose a security hole in this security feature?
By the way, my hosts file, while altered for other hosts, has nothing special going on with localhost; the default 127.0.0.1 / ::1 are still in place with no overrides below.
FOLLOW-UP: I got past this for local development purposes by adding:
127.0.0.1 local.mysite.com
.. to my hosts file, then adding the following code to my global.asax:
protected void Application_BeginRequest(object sender, EventArgs e)
{
if (Request.Headers["Host"].Split(':')[0] == "localhost")
{
Response.Redirect(
Request.Url.Scheme
+ "://"
+ "local.mysite.com"
+ ":" + Request.Url.Port.ToString()
+ Request.Url.PathAndQuery
, true);
}
}

I'm going to throw an answer out there; after some thought I've reached my own conclusions.
It could be that this is a security feature that's implemented to try to thwart an Internet web site from invoking JSONP services running on the client machine.
A web site could just go through a list of ports and keep invoking localhost on different ports and paths. 'Localhost' is one of few DNS hostnames that are dynamic in meaning depending on when and where it's queried, making the potential targets vulnerable. And yes, the fact that appending a dot (.) to 'localhost' ('localhost.') produces a working workaround does expose a security vulnerability, but does offer a [tentative] workaround for development puposes.
A better approach is to map the loopback IP to a new hostname entry in the hosts file so that it works locally, isn't prone to be "fixed" by a browser update, and doesn't work anywhere else but on the development workstation.

I'm experiencing a similar problem. Most of the solutions I've tried work with IE (7), but I'm having difficulty getting Firefox (3.5.2) to play ball.
I've installed HttpFox in order to see how my server's responses are being interpreted on the client, and I'm getting NS_ERROR_DOM_BAD_URI. My situation is a little different to yours though, as I'm trying to invoke a JSONP call back to the same site the hosting page came from, and then this call is responding with a 302 redirect to another site. (I'm using the redirect as a convenient way to get cookies from both domains returned to the browser.)
I'm using jQuery, and I originally tried doing a standard AJAX call via $.ajax(). I figured that as the initial request was to the same site as the hosting page, Firefox would just follow the 302 response to another domain. But no, it appeared to fall foul of XSS defenses. (Note that contrary to what Returning redirect as response to XHR request implies, jQuery does follow the 302 redirect for a standard dataType="json" call: a redirect to the same domain works fine; a redirect to another domain generates NS_ERROR_DOM_BAD_URI in the browser.) As an aside, I don't see why same-domain 302 redirects to other domains can't just be followed - after all, it's the hosting page's domain that is issuing the redirect, so why can't it be trusted? If you're worried about scripting injection attacks, then the JSONP route is open for abuse anyway...
jQuery's $.getJSON() with a ?callback=? suffix also fails in Firefox with the same error. As does using $.getScript() to roll my own JSONP <script> tag.
What does appear to work, is having a pre-existing <script id="jsonp" type="text/javascript"></script> in the HTML and then using $("jsonp").attr("src", url + "?callback=myCallback") to invoke the JSONP call. If I do that, then the cross-domain 302 redirect is followed and I get my JSON response passed to myCallback (which I've defined at the same time as the <script/> tag).
And, yes, I'm developing all this using Cassini with localhost:port URLs. Cassini won't respond to non-localhost URLs, so I can't easily try local.mysite.com to see if that has any affect on the solutions I've tried above. However, sticking a dot at the end of localhost appears to have fixed all my problems!
Now I can go back to a standard $.ajax({ ... dataType:"jsonp" ... }) call with localhost__.__:port instead of localhost:port and all is well. I find it interesting that modifying the src attribute of a script tag that pre-exists in the page's HTML does allow ordinary localhost URLs to be invoked - I guess following your thought process, this could be another security vulnerability.