I entered "s.amazon-adsystem.com" in Chrome's Network Request Blocking, but the requests go through anyway. There is really nothing more to add. Could some of you try adding that domain for yourself and seeing if Chrome will block it?
Edit: Blocking "*.amazon-adsystem.com" doesn't work either
Related
I see this key in requests occasionally when I have devtools open, but not always.
It's a header that Chrome devtools uses internally to let chrome know they're emulating a slow network/device. Chrome, in turn, should however not send this header in actual network requests. It appears this did happen in the past though (maybe even present).
See the bug here: https://bugs.chromium.org/p/chromium/issues/detail?id=395966
Click Me
This used to work as a valid href attribute but it seems in the past few months it now shows an error in the console (I'm using Chrome):
Not allowed to load local resource: view-source: http://stackoverflow.com
I found some links from 2013 where this was once a bug in Chrome but said it was fixed.
Could someone point me to an authoritative source that can explain why this no longer works? I assume that this is security by the browser and not an angular issue (since view-source is whitelisted and used to work)
Looks like Chrome and Firefox (at least) disabled this within the past year or so
I found this thread, and these release notes explaining why and provides a timeline as to when the change took place.
Related StackOverflow question: File URL "Not allowed to load local resource" in the Internet Browser
Chrome responds with the "Not allowed to load local resource:" as a security protocol. I'm not sure why this used to work, but not now, though there is no real way around this unless web-security is disabled. There may be a different outcome on other browsers, but ultimately you are correct in thinking that it's Chrome's security.
The reason is that Chrome tries to preload URLs in background, to speed up your browsing experience.
If you open the DevTools after loading the page, the content of the items listed on the Resources tab may not be populated. This is also true of network requests on the Network tab. To see the fully populated resources on the Resources tab, first open the DevTools, then refresh the page, or navigate to the desired page with the DevTools open. Now select the html resource and it should be populated.
I'm setting up a local development server on my Mac using nginx in place of Apache. I'm basically there, but having one issue.
I have multiple web apps, and each are set up using sites-available and sites-enabled - no issues here. The issue is that my browser of choice is chrome, and there's some weird caching going on that is causing the first-visited app to load each time. For example, I have:
site1.dev
site2.dev
If I load site1.dev, it loads without issue. If I load site2.dev, it's automatically redirected to site1.dev. I see this as a caching issue because if I use chrome's Incognito mode, I don't have the same issues (nor do I have them in Firefox).
Does anyone know what could be going on here? Or what the solution could be? Thanks in advance!
The solution is to open Chrome's Dev tools (right click, inspect element), click the network tab, and disable caching. Reload the first url, and try the second url. If there is no redirect, disable caching, and the issue is resolved.
Chrome only redirects from cache if the page was initially loaded with caching enabled.
My web page sometimes (rarely) shows "there are some insecure resources" warning icon (yellow lock) like in the screenshot below. However that occurs rarely and now I caught another one I don't want to miss it again so I can't risk losing the page.
The page is at the URL: https://eksisozluk.com/sedat-kapanoglu-ve-40-kisiye-hapis-talep-edilmesi--3960310 . You will probably not see the warning (unless it's Firefox) because I didn't in my consecutive tries on Chrome and I was logged in when I got the error. So let's assume you and I will never see that warning icon on Chrome again.
Devtools was not open when I was using the site, so "Network" tab is empty. That part won't work.
"Resources" shows all JS and CSS entries as https there is no single resource from http there.
The page has jQuery loaded so I tried queries $('*[href^="http:"]') and $('*[src^="http:"]') to no avail. The page contains some external http links (not resources, plain a href's) but that wouldn't trigger the alarm.
I'm using Kaspersky Anti-Virus and it uses a proxy to scan incoming/outgoing traffic. That could be causing some trouble although I haven't had any issues so far with other web sites.
I tried "view page source" and searching it for http resources but only tag with http resource link was:
<meta name="twitter:image" content="http://eksisozluk.com/content/img/ilogo120.png" />
which actually exists in the page when the icon is green too. So that cannot be the reason.
Isn't there a way to directly view the "insecure content" whatever that is in Chrome?
When I view the page in Firefox it says "partially encrypted" but it doesn't show what's not encrypted either. All the items in "Media" tab start with "https://".
Actually now I'm able to reproduce the issue continuously on Firefox. I looked at the network tab and "nothing" shows as http:// yet Firefox tells me "partially encrypted". I'm not sure if Firefox is saying that for the same reason Google does (because Firefox is consistent and insistent about it), but I'm providing both scenarios in case they belong to the same root cause.
I finally wrote this code in Chrome console to find the culprit:
$("*").each(function (index, elem) {
var attrs = elem.attributes;
for(var n = 0; n < attrs.length; n++) {
var attr = attrs[n];
if(attr.nodeValue.indexOf("http://") >= 0) {
console.log("FOUND: <" + elem.nodeName + " " + attr.nodeName + "='" + attr.nodeValue + "'>");
console.log($(elem));
}
}
});
The output shows no interesting stuff. Only <META content> for twitter reference, <A href>s and two <TD title="http://...">s that Mvc-Mini-Profiler inserted. None of them justify the warning of course. Here is the full output: http://pastebin.com/kgV8XHgN
So this looks really interesting. There is NOT a single element in DOM that contains an "HTTP" link yet Chrome warns about "insecure" content. I'm very troubled by it.
There are NO iframes on the page. ($("iframe") returns [])
EDIT: DAMN I lost the page :( (navigated to a link and back button turned to SSL icon to green). I knew it wouldn't last long. But I still appreciate any help since it wasn't the first time I saw that issue.
Just had this problem – if you check the Javascript Console in Chrome it will now tell you where the problem lies.
I had the same issue yesterday, and found http://www.whynopadlock.com/
It shows which elements are not secure, and it also verifies certificate chains.
Btw, if your site can be loaded both http and https, then omit http: from external urls.
Not:
src="http://external.dom/external.js" or "https://external.dom/external.js"
Just:
src="//external.dom/external.js"
Then the browser will use http or https depending on what the page is loaded as
I just spent an hour with a similar problem, I got the green ssl lock in Chrome and IE but not in Firefox (only after page reload).
First of all: To debug SSL issues, the httpfox plugin seems to be better than firebug's network tab. Firebug showed all sources as https, but looking at httpfox, I quickly found the culprit: Google Analytics was loading the ___utm.gif tracking pixel via http. This tracking pixel came from the previous page, where I was tracking a Google Analytics event which was attached to a button click.
This seems to be a bug in Firefox: When tracking a GA event from a http page to a https page (e.g. Proceed button click), FF will load the tracking pixel via http on the https page, causing the error.
I removed the event from the button and FF stopped complaining about the partially encrypted connection.
It sounds most likely that an AJAX resource was used with an http:// URL... you would most likely need the network panel or console to check that.
Firefox's built-in developer tools have them.
A quick solution is to add target="_blank" in each <a> element. It will open the link in new window. Working on all browsers.
When I inspect a web socket in Google Chrome Web Inspector, (see Chrome Web Inspector Web Socket Debugging), I have to keep clicking the socket on the left to refresh the messages on the right.
Is there any way to have this automatically refreshed each time a new message is sent/received? Or has this simply not been developed yet?
Unfortunately this is still the case even in dev channel (v27 atm) and looking at Chromium bugtracker it doesn't seem to be planned either.
Relevant issue here
You can vote on it, though I cannot say if that actually accomplishes anything.
I have tested with latest Chrome (32.0.1700), they still don't support automatically update of WebSocket frames. However you can use Fiddler (with FiddlerScript) to inspect WebSocket traffic in the same way you inspect HTTP traffic, and it supports auto refresh of frames.
Please refer to the article on CodeProject, which show you how to Debug/Inspect WebSocket traffic with Fiddler (with FiddlerScript). http://www.codeproject.com/Articles/718660/Debug-Inspect-WebSocket-traffic-with-Fiddler