Google Translate self blocking on some hosts? - google-translate

I've got some blocked attempts to load Google Translate on my website on some hosts.
Refused to execute script from 'https://translate.googleapis.com/translate_a/l?client=te&alpha=true&hl=fr&cb=_callbacks____0jtr2z0a8' because its MIME type ('application/json') is not executable, and strict MIME type checking is enabled.
HTTP response is :
_callbacks____0jtr2z0a8({"sl":{"auto":"Détecter la langue","af":"Afrikaans","sq":"Albanais","de":"Allemand","am":"Amharique","en":"Anglais","ar":"Arabe","hy":"Arménien","az":"Azéri","eu":"Basque","bn":"Bengali","be":"Biélorusse","my":"Birman","bs":"Bosniaque","bg":"Bulgare","ca":"Catalan","ceb":"Cebuano","ny":"Chichewa","zh-CN":"Chinois","si":"Cingalais","ko":"Coréen","co":"Corse","ht":"Créole haïtien","hr":"Croate","da":"Danois","es":"Espagnol","eo":"Espéranto","et":"Estonien","fi":"Finnois","fr":"Français","fy":"Frison","gd":"Gaélique (Écosse)","gl":"Galicien","cy":"Gallois","ka":"Géorgien","el":"Grec","gu":"Gujarati","ha":"Haoussa","haw":"Hawaïen","iw":"Hébreu","hi":"Hindi","hmn":"Hmong","hu":"Hongrois","ig":"Igbo","id":"Indonésien","ga":"Irlandais","is":"Islandais","it":"Italien","ja":"Japonais","jw":"Javanais","kn":"Kannada","kk":"Kazakh","km":"Khmer","ky":"Kirghiz","ku":"Kurde","lo":"Laotien","la":"Latin","lv":"Letton","lt":"Lituanien","lb":"Luxembourgeois","mk":"Macédonien","ms":"Malaisien","ml":"Malayalam","mg":"Malgache","mt":"Maltais","mi":"Maori","mr":"Marathi","mn":"Mongol","nl":"Néerlandais","ne":"Népalais","no":"Norvégien","uz":"Ouzbek","ps":"Pachtô","pa":"Panjabi","fa":"Persan","pl":"Polonais","pt":"Portugais","ro":"Roumain","ru":"Russe","sm":"Samoan","sr":"Serbe","st":"Sesotho","sn":"Shona","sd":"Sindhî","sk":"Slovaque","sl":"Slovène","so":"Somali","su":"Soundanais","sv":"Suédois","sw":"Swahili","tg":"Tadjik","tl":"Tagalog","ta":"Tamoul","cs":"Tchèque","te":"Telugu","th":"Thaï","tr":"Turc","uk":"Ukrainien","ur":"Urdu","vi":"Vietnamien","xh":"Xhosa","yi":"Yiddish","yo":"Yorouba","zu":"Zoulou"},"tl":{"af":"Afrikaans","sq":"Albanais","de":"Allemand","am":"Amharique","en":"Anglais","ar":"Arabe","hy":"Arménien","az":"Azéri","eu":"Basque","bn":"Bengali","be":"Biélorusse","my":"Birman","bs":"Bosniaque","bg":"Bulgare","ca":"Catalan","ceb":"Cebuano","ny":"Chichewa","zh-CN":"Chinois (simplifié)","zh-TW":"Chinois (traditionnel)","si":"Cingalais","ko":"Coréen","co":"Corse","ht":"Créole haïtien","hr":"Croate","da":"Danois","es":"Espagnol","eo":"Espéranto","et":"Estonien","fi":"Finnois","fr":"Français","fy":"Frison","gd":"Gaélique (Écosse)","gl":"Galicien","cy":"Gallois","ka":"Géorgien","el":"Grec","gu":"Gujarati","ha":"Haoussa","haw":"Hawaïen","iw":"Hébreu","hi":"Hindi","hmn":"Hmong","hu":"Hongrois","ig":"Igbo","id":"Indonésien","ga":"Irlandais","is":"Islandais","it":"Italien","ja":"Japonais","jw":"Javanais","kn":"Kannada","kk":"Kazakh","km":"Khmer","ky":"Kirghiz","ku":"Kurde","lo":"Laotien","la":"Latin","lv":"Letton","lt":"Lituanien","lb":"Luxembourgeois","mk":"Macédonien","ms":"Malaisien","ml":"Malayalam","mg":"Malgache","mt":"Maltais","mi":"Maori","mr":"Marathi","mn":"Mongol","nl":"Néerlandais","ne":"Népalais","no":"Norvégien","uz":"Ouzbek","ps":"Pachtô","pa":"Panjabi","fa":"Persan","pl":"Polonais","pt":"Portugais","ro":"Roumain","ru":"Russe","sm":"Samoan","sr":"Serbe","st":"Sesotho","sn":"Shona","sd":"Sindhî","sk":"Slovaque","sl":"Slovène","so":"Somali","su":"Soundanais","sv":"Suédois","sw":"Swahili","tg":"Tadjik","tl":"Tagalog","ta":"Tamoul","cs":"Tchèque","te":"Telugu","th":"Thaï","tr":"Turc","uk":"Ukrainien","ur":"Urdu","vi":"Vietnamien","xh":"Xhosa","yi":"Yiddish","yo":"Yorouba","zu":"Zoulou"},"al":{}})
Works for years and on many hosts (Win/Mac/...). But for some days, I can't fully load Google Translate on some hosts (most works like always).
Seems not browser nor OS dependant.

I delete the cookie "cookie: NID=179=S.........." and then, Google Translate is back !

Related

IIS Node.js server download files relay error on Firefox and Chrome

I'm using IIS 10 server as a gateway for Node.js server.
When client calls download files such as zip file, IIS server download Node.js server internally with HTTP protocol, and then it pass to client with HTTPS.
But in Chrome web browser, It shows error
net::ERR_HTTP_1_1_REQUIRED with status 200, and when I try to download again it works well until I clear the caches.
In Firefox, it returns status 200 too, but nothing's happen.
In Microsoft Edge and IE11 works well too.
I've set enough timeout and buffer size in IIS.
May Chrome and Firefox go wrong at HTTPS - HTTP connection or something else?
There may be some extensions in your Firefox and Chrome that can cause this error. This error means a browser extension blocked the request. The most common culprit is an ad blocker like AdBlock Plus. In short your requests to server have been blocked by an extension. so you can try to disable these extensions and try again.
It seems that the .NET Core team found a related issue and provided a workaround.
Perhaps the same can be applied with other frameworks.
https://github.com/dotnet/aspnetcore/issues/4398
Apparently, when doing an ajax request from a browser, it will sometimes send an OPTIONS request before the real request with a 204 status code which causes the problem.
For me, it seems to have solved my problem to return the file with a response content-type of "text/plain" instead of "application/octet-stream"
I'm not really sure why it works, it just does.

How to determine exactly why chrome flags site as not secure

I just moved several interrelated sites from a server that does not support TLS 1.2 to one that does to specifically stop chrome's site is insecure message. There a 4 separate websites one of which has 2 pages Demo.aspx and Rater.aspx. All sites use https:// and the server supports TLS 1.2 and has a valid certificate chain. All sites load without any security warning, including Demo.aspx, but Rater.aspx does not (it is the only one).
Rater.aspx is a older and somewhat large one page asp site, so I figured there must be a http:// reference somewhere, and I found a few which I converted to https://.
I have gone over the site many time, and there is nothing I can see that should be causing the insecure flag.
Your Connection to this site is not secure.
Certificate (valid)
Cookies (1 in use)
Is there a tool that will tell me what chrome is picking up on so I can fix it?
If it would be helpful I can provide a link to the page, just did not want to do it here.
Thanks!
As #mason pointed out Chrome's Security Tab in developer tools provides information on what is causing the Not Secure message and ultimately led to the discovery of an unused iframe pointing to a less secure domain.
I found the offending domain name on the Application tab under Local and Session storage (no actual data was being stored). A project search for that name found the iframe.
Of note is that the insecure server was https:// and has a valid SSL certificate but it does not support TLS 1.2.

AMP HTML amp-ads - Blocked Frame, Protocols, domains, and ports must match

I'm attempting to resolve an error that is preventing me from showing google-adsense ads on an amp-html site that I built and am hosting on an nginx server. I have searched and read through quite a few similar questions on Stack Overflow, Google Adsense and Amp By Example documentations.
I placed an amp-ad, per Google's instructions. The page itself loads properly, but with for whitespace where the ad should be. In the console, I get this error (twice):
Blocked a frame with origin "https://d-1234567890.ampproject.net" from accessing a frame with origin "https://example.com". Protocols, domains, and ports must match.
I recently moved the Nameservers to a new server, which now supports https instead of http. The site appears to still be verified in Adsense, but is it trying to send the ads via the wrong protocol?
Protocols must match -- seems to be the case, as both sites are https.
Domains and ports must match -- ok, but how to verify these?
Beyond this, I'm not quite sure how to troubleshoot the issue, other than blindly turning off security measures. Should I be looking at my headers (X-Frame-Options, X-Content-Type-Options, etc.)? Or my Content-Security-Policy header? Or is Google Adsense still using the old http protocol?
FWIW, I am also getting these (related) warnings in the console:
[Warning] The resource https://3p.ampproject.net/234567890/f.js was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it wasn't preloaded for nothing.
[Warning] The resource https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it wasn't preloaded for nothing.
Thank you in advance for your help.

FF sporadic failure to load web font hosted on s3

We have a font hosted on S3 as a woff and referenced via CSS. The S3 bucket has CORS configured to allow cross-site access from anywhere. Normally, the font displays with no issues. Sometimes, however, Firefox fails to render the font and the error console reports "bad URI or cross-site access not allowed". I'm trying, without much success, to figure out exactly what sequence of HTTP calls FF uses to obtain the font resource from S3 so I can debug the situation with curl. Thus far, debugging with
curl -s -I -X OPTIONS --header "Origin: http://www.foo.com" --header "Access-Control-Request-Method: GET" s3.amazonaws.com/font.woff
has yielded only HTTP 200 responses, i.e. provides no information about what might be failing. I'm kind of at a loss as to how to figure out what's going on. I don't know whether S3 is sporadically returning spurious 403 responses to the OPTIONS requests, 403 responses to the requests for the resource itself, or our HTML/CSS is somehow subtly broken and/or exposing a bug in FF. Any suggestions?
This looks to be an intentional preventative measure against xss (cross site scripting) attacks that firefox has implemented.
Read about one possible solution here: Downloadable font on firefox: bad URI or cross-site access not allowed

"Method Not Implemented" error - Firefox 3

Getting sporadic errors from users of a CMS; Ajax requests sometimes result in a "501 Method not implemented" response from the server. Not all the time; usually works.
Application has been stable for months. Users seem to be getting it with Firefox 3. I've seen a couple references via Google to such problems being related to having "charset=UTF-8" in the Content-type header, but these may be spurious
Has anyone seen this error or have any ideas about what the cause could be?
Thanks
Ian
You may want to check the logs of the server to see what's causing the issue. For example, it might be that these requests are garbled, say, because of a flaw in the HTTP 1.1 persistent connection implementation.
Try this
Try clearing your cookies and your cache
Type about:config into the URL bar, list of configuration settings for Firefox
Locate the setting for 'network.automatic-ntlm-auth.trusted-uris'
Set the value of names of the servers to use NTLM with.
Locate the setting for 'network.negotiate-auth.trusted-uris'
Set the value of names of the servers to use NTLM with.
network.automatic-ntlm-auth.allow-proxies = True
Restart Firefox - Test URL to application
The problem occurs as your app is not running on the same domain as your service. You need to configure your Server to accept those calls by adding the 'Access-Control-Allow-Origin' Header.

Resources