A validator such as an ETag or Last-Modified header must be present in the response.If the headers indicate that content should not be cached then it won't be. The response headers returned from the origin web server.The cache-ability of an item on the browser is determined by: Efficiently using the browser cache can improve end user response times and reduce bandwidth utilization. Press SHIFT+CTRL+J to open the Google Chrome’s console window.When a user visits a web page, the contents of that page can be stored in the browser's cache so it doesn't need to be re-requested and re-downloaded.Go to (or any other wesite with a non-restrictive CORS policy – read here if you don’t know what we’re talking about).Here’s a recent workaround that takes advantage to the Google Chrome fetch() API which has been discovered by one of our readers and definitely seems to work (thanks to Santiago for reporting it!): The only downside is that you won’t fix your 301 caching issues in the “main” browser: if you want to do that as well, use the above options instead. #3: Use the Chrome Incognito ModeĪlternatively, you can always use the Incognito Mode, which flushes its cache everytime the browser is closed.
It’s worth noting that the Developer Tools panel must remain open for the whole process, otherwise Chrome won’t let you to use Empty Cache and Hard Reload feature.
This will indeed fix your problem, yet it will also delete your cache data for any other site as well... kinda extreme, isn’t it? Ensure that “Cached images and files” is a checked option (the rest is optional, depending on what you want to clear).Menu > Settings > Show advanced settings > Privacy, then click on Clear browsing data.You can always fix this issue – together with all caching problems – by clearing all of your browser cache in the following way: However, such issue can often occur on a non-development browser as well, forcing you to take action in one of the following ways.
In my specific case it happens all the time, to the point that I always work with my development browsers cache disabled: if I need to test stuff with a non-development browser, I’m often using the Incognito Mode, which flushes its cache everytime the browser is closed. The only downside of that is that, whenever you’re testing or developing a web site (or a web server such as IIS or NGINX) and temporarily configure a HTTP 301 that you want to change later on, you could run into that redirect for a long period of time, thus being unable to access the previously-301 URL, page or resource. This is a perfectly fine behaviour, as it’s explicitly allowed by the RFC 7231 Section-6.4.2, which says the following:Ī 301 response is cacheable by default i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of ). As you most likely known since you found this post, Google Chrome – just like most other browsers – implements the 301 redirect caching, meaning that it will often locally cache the HTTP 301 redirects for a given amount of time without asking the server another HTTP response for that same URL.