We are having problems with requirejs as it randomly fails to load files--see here. In Chrome the network tab says that it failed to load, but it does not provide a proper http response code--see here. On refresh everything could be working fine again.
This resource (ckeditor) is shimed by "lib/ckeditor/ckeditor": {
exports: "CKEDITOR"
} and we are using requirejs v2.1.6.
Anyone else having problems like this?
Related
I am trying to collect crash logs for my WebAssembly application. It's built with emscripten, everything is served from the same domain, testing in Chrome. In the developer console I see a proper error with stack trace when a crash occurs, I'd like to capture this and send it to a server.
Instead I am only getting "Script error." passed to window.onerror() and the fifth parameter is null. This is supposed to happen when violating the same-origin policy (linked question is only about javascript, does not talk about this WebAssembly-specific problem.) Errors occurring in the .js file don't have this problem, only webassembly runtime errors.
I added the crossorigin attribute to the .js file generated by emscripten. The site is running in secure context, the Response object passed to WebAssembly.instantiateStreaming() (in the emscripten-generated .js file) has "basic" as its .type, so as I understand it has no restrictions on what can be done with it. "Access-Control-Allow-Origin" header is set to "*".
For some weird reason I managed to get the full error with stack trace exactly once, so it is apparently possible, but seemingly doing everything the same way I can't get it to work again.
How can this be solved?
instantiateStreaming is promised based so maybe try window.addEventListener('unhandledrejection')?
Today we updated the last version of google chrome browser (Version 102.0.5005.61). We have an aplication that runs into a vpn. And since then we start getting this errors on the console:
As you can see we get a timed out error on the preflight and then the xhr request fails.
We noticed that on this version of chorme they add the new header: Access-Control-Request-Private-Network. An that is what I see on the preflight headers:
Serching on what could be wrong, since this is happening only when we update the chrome version and in other browsers the site works perfectly; Ive found this:
https://developer.chrome.com/blog/private-network-access-preflight/
On the article is explained what to do and how to handle this.
And show kind of what is happening to me:
If your request would have triggered a regular CORS preflight without
Private Network Access rules, then two preflights may appear in the
network panel, with the first one always appearing to have failed.
This is a known bug, and you can safely ignore it.
Based on that I added the new header support on my API that is made on JAVA with spring boot.
response.setHeader("Access-Control-Allow-Methods", "GET, POST, DELETE, PUT, OPTIONS");
response.setHeader("Access-Control-Allow-Headers", "content-type");
response.setHeader("Access-Control-Allow-Credentials", "true");
response.setHeader("Access-Control-Max-Age", "180");
response.setHeader("Access-Control-Allow-Private-Network", "true");
response.setHeader("Access-Control-Expose-Headers", "Content-Disposition");
As you can see just added the header and return 200 for the option request
if ("OPTIONS".equals(request.getMethod())) {
response.setStatus(HttpServletResponse.SC_OK);
return;
}
The site is running, meaning it get served and is loaded on chrome browser but all the API calls from the site get that error. (See screen shoots avobe).
But still after that have the same issues. Any one had the same issue and was able to solve?
Any help will be appreciated!
Thanks!
EDIT:
We just add the headers on the preflight response:
Access-Control-Request-Private-Network: true
Access-Control-Allow-Private-Network: true
Then we go to the google flags configuration and disable this:
Now Im not sure why google thinks that my requests are insecure.
This issue is coming for Private and Public combination, like our web is deployed as CloudFront Public URL and backend is Private api hosting, so we are also facing this issue, currently only disabling "Send Private Network Access preflights" property of chrome is working (its only enough).
We have tried setting "preflight request will carry a new header, Access-Control-Request-Private-Network: true, and the response to it must carry a corresponding header, Access-Control-Allow-Private-Network: true" but no luck till now.
Our another web application on which FE/BE both are private hosting is working fine.
I have a PWA built with Angular 6 and the #angular/pwa npm package and authenticating using adal-angular4 npm package (but could just rebuild that from scratch if needed -- the issue isn't a bug in the package I think)
When attempting to authenticate, although it does work, users are very often greeted with this message of not found (screenshot of console but its the same).
This especially seems to be the case if you are already authenticated to another (or itself) Azure AD product. Where it normally should only load for a while and then let the user in.
Service worker error transcript:
Failed to load 'link.com/#LONGTOKEN' A serviceWorker passed a promise
to FetchEvent.respondWith() that rejected with 'Error: Response not Ok
(fetchAndCacheOnce): request for LINK.com/index.html returned response 404 Not Found'.
It seems that writing a function to check for new version of the PWA has cleaned up everything. Because it's a PWA, when replacing files with a new version -- the cache will still be there and shift+reloading won't necessarily clear it, causing a lot of unwanted behaviour.
The code for the cleanup looks like this:
First, inject in the constructor the following: updates: SwUpdate
import { SwUpdate } from "#angular/service-worker"
Then, inside ngOnInit, I have the following:
updates.available.subscribe(event => {
updates.activateUpdate().then(() => document.location.reload());
})
It will force a complete refresh 2-3 seconds in if there's a new version available but all works well afterwards.
I am facing an issue related to loading JSON data.
When I monitor JSON call on Developer Tools of Chrome, I get the following message in the network tab of Chrome Developer Tools.
Caution: request is not finished yet
Attaching a snip for reference:
It is caused by two-step response loading. If you are using some low-level API, make sure that you fetch not only headers, which arrive first, but also body content that comes later as a stream.
I had the same issue when using the fetch function in JavaScript. To solve it, make sure you call a method that reads the body of the response like json() or text():
// Sends request and loads only headers
fetch('/foo');
// Sends request, loads headers and then fetches the body as JSON
fetch('/foo').then(response => response.json());
In my case response headers were also loaded properly and I had a successful HTTP status code, but I was missing the body content and I had Caution: request is not finished yet inside Chrome Developer Tools.
consider removing all extensions and closing all the browser tabs
for me it helped - upon restart, all is well.
So strange
In my case, I needed to use response.text() instead of just using response. The usage of just response yields in "Caution: request is not finished yet"
fetch("API_URL_GOES_HERE", requestOptions)
.then(response => response.text())
.then(result => console.log(result))
A tip here would be: Open Postman's Code snippet and view the actual JS Fetch that is happening.
I ran into this issue due to a programming error that caused an infinite loop in my JavaScript code.
Some time ago Chrome would point out that a script is stuck, but for some reason such a message did not show up in my Chrome. Instead, I found this error in the network tab.
Trying Firefox, it showed the error message "This page is slowing down Firefox. To speed up your browser, stop this page".
This helped me figure out that in my case the issue was not related to the request, but was actually caused by a script running forever.
Apparently, the infinite loop in JavaScript causes Chrome to not finalize the request or at least it does not update this display. I am not sure why Chrome would not show a more meaningful error message that a script is stuck.
I have an application uses Spring Security 3(has a Jackson Marshaller) runs on a Tomcat 7. I designed my application with Jquery and it runs well. I designed a login page with Ext JS and after successful login it redirects to index.html. However it gives an error and can't redirect because when server sends HTML file it comes into that function at Ext JS:
Ext.util.JSON = new (function(){
...
doDecode = function(json){
return eval("(" + json + ")");
},
...
I wants to render it as a JSON response and gives an error as usual. How to solve it?
PS: It gives that on Firebug:
syntax error
[Break On This Error] (<!DOCTYPE html>
The server is not returning valid JSON. Its look as if it is returning a HTML page (perhaps a friendly error page). If you follow the stack trace up its probably Ext.decode response.responseText (inspect this you'll see whats returned although not the best way)
First step would be to investigate the request in the Net panel in Firebug or Chrome, look at the request and response headers and content this will point you in the right direction. Please please please do not resolve this problem without first learning to use a client side browser debugger (Firebug or Chrome Dev Tools or even Safari) such as walking the stack on break on error, break on XHR, inspect the XHR headers and response etc.. not just watching the console window.
You might be able to fix this continuing blind but you'll pay heavily again next time.