This is the sure proof way to clear Chrome's sticky memory for redirects without clearing all your browsing data (method used by the current top answer):
Open the Developer Tools panel (optioncommandi on Mac, or ctrlshifti on Windows)
Click and hold the reload icon
A menu will open
Choose the 3rd option from this menu ("Empty Cache and Hard Reload&...
It's not a perfect solution, but I was able to prevent Chrome from using the cached redirect by passing a bogus query string, or adding a bogus parameter to the existing query string. For example, adding a simple ? to the end of a URL that didn't have q query string worked for me on Chrome 30 on Max OS X.
Ok, I figured it out:
I used command scutil --dns which returned current resolvers configuration
There was entry:
domain : dev
nameserver : 127.0.0.1
flags : Request A records, Request AAAA records
reach : 0x00030002 (Reachable,Local Address,Directly Reachable Address)
Then I went to the catalog /etc/resolver and I found ...
If you have the "Disable cache (while DevTools is open)" option enabled in the DevTools, then simply having the DevTools open is enough to bypass the redirect cache, without constantly throwing away your session.
Nowadays Chrome has an exclusion mechanism in its filter box:
This removes all console errors that block access to network resources. These errors are usually caused by ad blockers and similar scripts. But watch out, this can also be caused by service workers on your own site.
As a more thorough solution, you might want to ...
Mac Pro (Retina, 13-inch, Early 2013)
Chrome: 46.0.2490.71 (64-bit)
Open 'Console' and right click on the Error log you do not want to see.
Click on 'Filter'-> 'Hide message from xxx.js'
(Click image to enlarge)
Chrome caches HTTP redirects and stop checking with the site if the redirect has changed. This can be frustating, since the easiest way to fix (visiting the site and forcing a hard refresh) can't be used because the redirect will happen before you access the link. This is a won't fix issue.
To workaround this, you can clear your browsing data, as explained ...
Google's Keyboard Shortcuts Reference lists for "Pause / resume script execution":
F8 or Ctrl+\ (Windows)
F8 or Cmd+\ (Mac)
There are easier ways to inspect things in odd states like hover or active. First, find the DOM node in the Elements pane of Chrome Dev Tools. Now you can either right-click the node and look at the "Force Element State" in the ...
Go to chrome://net-internals and at the far right open the drop-down and choose "Clear Cache". As of version 48, this was the only thing that worked for me to clear a cached 301 (permanent redirect).
Update: Unfortunately, as of version 71 (Dec 2018) Google has removed the net-internals feature.
According to the Fiddler Wiki:
SAZ files are simply specially formatted .ZIP files. If you rename a
.SAZ file to .ZIP, you can open it for viewing using standard ZIP
Inside a SAZ file, you will find:
_index.htm - an optional file containing a human readable version of the Session List. This file is not processed when loading a ...
I would like to apply the same styles to SCSS files as I do CSS files.
This is done using the Style Configurator:
Menu > Settings > Style Configurator
Select "CSS" in the "Language" box
Add "scss" to the "User ext" field (you can add multiple extension separated by space)
Click "Save & Close"
How to get it:
Source Code on GitHub
Keep chrome developer tools open
Press pause/break on your keyboard
I recommend Quick Source Viewer.
It can show you the source of the current page formatted and colour coded.
It's pretty powerful, showing all 'sources' of the page, be it css, js or html. Even things like inline css/js can be viewed individually (with injected code highlighted). And the best part is it prettifies all of them, even the css (which chrome's ...
.dev domains are forced to use HTTPS on Chrome 63+
Since Chrome 63, out December 2017, all domains ending on .dev (and .foo) are forced to use HTTPS via a preloaded HTTP Strict Transport Security (HSTS) header.
More on it here: https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/
The instructions in the above answer work perfectly as of July 2017, however, if you wish to use PHP 7, you must add the following lines to C:\Apache24\conf\httpd.conf, instead of the ones in that answer (which work only for PHP 5) [Add the following after all the LoadModule lines]:
LoadModule php7_module C:/PHP/php7apache2_4.dll
As described here could be caused by HSTS
To get around this, I did the following.
In the Chrome address bar type "chrome://net-internals/#hsts" At the
very bottom of a page is QUERY domain textbox - verify that your site (localhost e.g.)
is known to the browser If it is, DELETE the localhost domain using
the textbox above Your site should now ...
In either Chrome or Firefox, you can refresh the redirect by typing "view-source:redirect.yoursite.com" and hitting enter. Then, refresh that page. Now, that should force Chrome or Firefox to refresh the redirect.
The best method is to change the PHP settings in
to reflect the new version of PHP you want to use
In my case I unpacked PHP5.4 to C:\XAMPPLITE\PHP5.4 and then updated key lines in this file such as:
SetEnv PHPRC "C:\\xampplite\\php5.4"
Type 'ipconfig' on your Windows command line. You will see information similar to what I see below:
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : localdomain
IPv6 Address. . . . . . . . . . . : fdb2:2c26:f4e4:0:a1e2:ed15:e43a:daf7
Temporary IPv6 Address. . . . . . : fdb2:2c26:f4e4:0:b5d9:4d70:47a:b0b0
I found that right-clicking on each message allows to hide it, but this doesn't work for scripts with autogenerated file names.
Edit: There is a "hide network messages" option now (the gods of Google Chrome answered our prayers :D):
Is there's a possibility to also see similar request logging for DNS resolution?
Not using the developer tools.
However, see later in this answer for instructions on how to enable HTTP logging (which includes DNS query logging).
The only information you can get from the developer tools is the "Time taken to resolve a host name." which is in the "Timings" ...
Since Google Chrome version 54, it now detects the DPI settings on the computer
and scales the web browser accordingly.
Previously, Google Chrome did not pay attention to the system’s DPI settings,
but now it does and that is the root cause of the large interface issue.
If the DPI is set to more than 100 percent in the system, this would give the effect of "...
The browser doesn't read the HOSTS file directly. The browser makes a DNS request to the OS and the OS returns a response (having checked the HOSTS file). So, it's the OS's DNS resolver you would need to override and I'm not aware of an easy override for that.
If manually editing the HOSTS file is too much work, then maybe some kind of script to ...