Google Chrome Frame and Amazon Cloud Front CDN Timeout? - javascript

Our company is currently experiencing an issue with Google Chrome Frame enabled browsers and a third party site that utilizes an Amazon CloudFront CDN. For all CSS and JS files on the CDN, chrome sits on a request for 2 minutes exactly, and then returns with a 304 and loads the page.
We need chrome frame active, and it doesn't look like we can disable it for specific sites if the site is sending down the chrome frame headers.
Has anyone experienced this before? Is there any way to force the timeout to occur quicker. Why would that be happening in the first place?
Duplicate dead question here.

Related

How to recover the IP of a site with a Firefox extension?

my problem is for a Firefox extension. I can't find a way to retrieve the IP address of the website loaded on a page in Firefox. However, the data exists:
Network Monitor ⇾ Header ⇾ Get
I have seen solutions with dns.resolve or through external websites, but it is not reliable in case of CDN as with Google for example.
I hope you can help me.
Edit:
Up, solution to get the header of the request in JavaScript ?

Android - document.write() blocks Google Ads - Doubleclick

I've found numerous questions about document.write() but none that responds to my specific problem.
Short explanation
The request to receive an ad from DoubleClick finishes successfully but the ad doesn't load (blank space instead of seeing an ad), these are the warnings provided by logcat in Android Studio :
A parser-blocking, cross site (i.e. different eTLD+1) script, SCRIPT_PATH, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.
The SSL certificate used to load resources from WEBSITE_PATH will be distrusted in the future. Once distrusted, users will be prevented from loading these resources. See https://g.co/chrome/symantecpkicerts for more information. SCRIPT_PATH
Longer Version
I have an Android app in which we include Google Ads with the DoubleClick library. Those ads can`t load on some newer devices (ex Android 7.0). I suspect that newer versions of Android have newer versions of Chromium (55+) in which the handling of document.write() has changed.
https://developers.google.com/web/updates/2016/08/removing-document-write
Thus, when loading some ads (in my case all of them) I always receive the warning about document.write() and the ad doesn't load.
I don't have any error from double click (request is successful).
I don't have any message saying that no ads are available to be served(ad is received correctly in the request).
The only problem is the ad doesn't load because of the JavaScript it's trying to execute.
Changing the JavaScript directly doesn't sound like a good idea as it is loading in a WebView provided by an external library which would require some ugly reflection.
Classes used :
com.google.android.gms.ads.doubleclick.PublisherAdView
com.google.android.gms.ads.doubleclick.PublisherAdRequest
com.google.android.gms.ads.doubleclick.PublisherAdRequest.Builder
I repeat that it works with older devices (Android 4.4 I think)

Why do I have a message about "mxpnl.net" always in my Google Chrome console?

VM2335:34152 POST https://cr-input.mxpnl.net/data?_channel_id=&_partner_id=39571&_sub_id=0000&_app_version=1.0.23&_app=cs-dca net::ERR_INTERNET_DISCONNECTED
From what I can find, it appears to be a behaviour and analytic tracking script most likely related to mixpanel.com. I've recently run into the same thing, and followed it back to the content.js file inside the Tampermonkey chrome extension. I'm sure there are other chrome extensions that do the same thing, but uninstalling this chrome extension made the https://cr-input.mxpnl.net request stop.
I've also heard others have solved this problem by uninstalling Hide my adBlocker, but I can't confirm this myself.
This could mean you have a malicious Chrome extension installed. I googled "cr-input mxpnl" and came across this Google Forums post. If your internet is disconnected, the extension is probably failing to connect to the website where it wants to send your data.
To be clear, this is a guess. It may be a totally legit extension. However it would definitely be worth checking what extensions are installed, removing any that you don't recognise and doing a virus scan.
Since you are using some Adblocker extension that's the reason for getting
ERR_INTERNET_DISCONNECTED from the console. In the preferences of your Adblocker, you have blocked the access to Site Analytics Tracker
Turning off or Disabling the Web Statistic Tracker options from the preferences of the installed extension came from the Tampermonkey chrome extension. That alone stops accessing analytic tracking script most likely related to mixpanel.com.
There are other options from the preferences from the extension that might not be needed
Cheap Flights Advisor
PromoBar
Aliradar
So try to disable these options and always try to block all unencrypted requests by using HTTPS Everywhere extensions so that your information might not be stolen to any third party agents.

safari loads css/js very slow on client certificate SSL website

I have a website where I use client certificates for accessing the site and it runs with SSL required. It runs on IIS 8.5 on a windows server 2012 R2.
All my css and javascript is minified into 4 seperate files
app.js -> Our own javascript
app.css -> Our own css
vendor.js -> External javascript libraries
vendor.css -> External css libraries
All of these files are minified and placed locally on the server.
The site works very well when using chrome or IE from a computer, but when using safari (only tried safari 5 on PC and latest safari on iphone 6/7) the page can stuck in a "loading" mode. The does not happend every time, and when it does it often helps with clearing the cache in safari and try again.
The website also uses local storage to save some userdata, and a cookie that stores a token for authentication. Not sure if this is useful information, just throwing it out there.
It can connect to the webserver, since we can see the EV+ certificate.
When debugging the phone on a mac, or safari on a PC and looking at the network tab in the developer window I can see that sometimes it takes really long time for the browser to load some of the css and/or javascript files.
Sometimes it appears to be vendor.js, and sometimes app.css, and sometimes the other ones. There seems to be no logic to me, that its always the same files etc.
The site is .NET 4.6 site, running with angularjs, signalr 2.2.1 and html5 in the front.
We have tried
Monotoring IIS Logs and network traffic
Remove sourcemap on css/js to reduce file size
Tried reference signalr/hubs (the generated js file). And also tried copying the content into vendor.js so there is a local version instead
Without any success ATM. I would really appreciate help, feeling stuck on this one.
Many Thanks!
It may be dynamic compression. Are you using Brotli compression on the server?
I suggest a detailed analysis of HTTP Request and Response headers. There may be a discrepancy resulting in this unexpected behaviour. I would follow this up with scouring the Safari bug tracker.
The SSL certificate itself may be the issue, or rather Safari's interpretation of policies.
Hope it helps.

Chrome blocking iframe requests as cross-origin request even when origins are the same

This one has me stumped.
I have a web app that has a file upload/download area. Files are downloaded in the background via a temporary iFrame element. This is a single-paged AJAX application and the UI is written in Javascript, jQuery and uses the jQuery.FileDownloader.js to manage the iFrame. The application runs over HTTPS and the site and download URL are on the same exact domain. The back-end is a RESTful application. This has worked great for months. Until today.
All of a sudden, when attempting to download a file in Chrome, the browser reports an error of "Blocked a frame with origin https://example.com from accessing a cross-origin frame."
The problem is that the origin of the main site and that of the iframe are the exact same domain. I have ensured that the domains are the same as well as the protocol. Chrome is the only browser that throws up the cross-origin error. IE, Firefox, Opera, Safari... all work as expected. It's only in Chrome and it's only as of today. To make things worse, no updates were made to the browser. It truly is spontaneous. I've also ruled out plugins as the cause by running in Incognito mode, where none are allowed to run by my settings, as well as disabling my anti-virus software. This problem is being exhibited on other computers, in other locations (not on our LAN or subnet), all running Chrome.
And, again, both domains of the parent frame and the embedded iframe are identical. This only happens against the production server which runs over HTTPS. Other non-HTTPS sites (e.g. our dev environment, localhost) don't have the problem. Our SSL is valid. Since this is a single-paged AJAX application, we're trying to avoid popping up another window for the download.
Hopefully, someone can offer some advice. Thanks in advance.
Update: After additional research, I have found the solution to this problem is to enclose the filename in the response header in double-quotes.
I have found the cause of the problem. It turns out that Google Chrome has problems with files that have commas in their filename. When downloading the file via a direct link, Chrome will report that duplicate headers were reported from the server. This has been a long-standing problem with Chrome that has gone un-addressed. Other browsers are not susceptible to this problem. Still, it's a fairly easy problem to troubleshoot and, indeed, when I searched on this error, the first search result had the solution: remove commas from filenames when handling a request from Google Chrome.
However, this wasn't a direct link, it was an AJAX-request, which results in a different exception. In this case, the error provided by Chrome is the cross-origin request exception and this is what made it so difficult to troubleshoot.
So, the tl;dr of it all is to strip out commas in the names of uploaded files.
Another instance I found where this issue occurred is after executing code similar to:
document.domain = '[the exact same domain that the iframe originally had]'
Removing this line of code got rid of this error for me.

Categories