What will happen if a html page has a prefetch link to a resource that has a no-cache pragma header?
but if it loads a resource without actually using it will it be discarded on subsequent request?
This is browser dependent. IE11 operates as follows:
Prerendered pages are not always displayed to the user. These conditions cause prerendered pages to be discarded from memory without being displayed:
The user doesn't open the target page within five minutes.
The user opens a different page.
The user switches to a different tab or browser instance.
A JavaScript process adds a new link element that requests a different webpage to prerender.
An error occurs while loading the target page, including HTTP error code 500 (server error), 404 (resource not found), or related errors (such as connection problems).
When a prerendered page is discarded and then requested later, it's loaded from the hosting server directly. If the page is still in browser cache, it might load more quickly; however, this is not guaranteed.
References
Prerender and prefetch support
All of the browsers (with prefetch support) will load the document in their idle time (with Pragma: no-cache or/and Cache-Control: no-cache) so we'd like to know whether they take it from cache or will they request it again when user actually "clicks" the link.
From the quick investigation I've done recently (browsers are of latest versions):
Chrome/Opera loads from cache
Firefox requests again
IE/Edge requests again
Safari doesn't support
So I'd suggest to set some cache period (e.g. 5-10 minutes) for the resource you want to prefetch if you want it to be taken from cache on browsers other than chromium based.
Related
We have a react front-end that is communicating with an ASP Core API.
Sometimes we detect there is something wrong with the front-end, including service workers, local cache, and that kind of stuff, so we want to tell the client to clean it up.
I've implemented the Clear-Site-Data (dev-moz) (w3c) as a response header, as "Clear-Site-Data": "cache", "cookies", "storage", "executionContexts"
When testing this out in Firefox, it works, and in the console I'm seeing:
Clear-Site-Data header found. Unknown value “"executionContexts"”. SignIn
Clear-Site-Data header forced the clean up of “cache” data. SignIn
Clear-Site-Data header forced the clean up of “cookies” data. SignIn
Clear-Site-Data header forced the clean up of “storage” data.
When doing the same in Chrome, it's not working, and I'm seeing the message
The request's credentials mode prohibits modifying cookies and other local data.
I'm trying to figure out what to do to fix it, but there are barely any any references. Just 7 results, mostly from browser integration test logs
All the documentation says that this should be implemented and working in Chrome... Any idea what's the problem?
Try manually reloading the page after the Clear-Site-Data has been received (so that the local data / cache is cleared and the header no longer contain Clear-Site-Data).
Both Firefox & Chrome don't appear to support executionContexts, which tells the browser to reload the original response.
If header contains executionContexts, then the browser should ignore it (as you see in Firefox console). However you can try wildcard mapping (*). (This will also add support for future properties).
Response.AppendHeader("Clear-Site-Data", "\"*\"");
Also Google reuse parts of their Chrome source code in their open source project Chromium. If you take a look at Chromium source code (https://doss-gitlab.eidos.ic.i.u-tokyo.ac.jp/sneeze/chromium/blob/9b22da4739ec7bf54fb8e730662e2ab7996532e0/content/browser/browsing_data/clear_site_data_handler.cc line 308). This implements the same exception The request's credentials mode prohibits modifying cookies. A flag LOAD_DO_NOT_SAVE_COOKIES is somehow being sent. The console error maybe an caused by an additional response header or a small chance theres a bug in Chrome.
Right now, my advice would be do not implement the Clear-Site-Data header at this time.
Despite the spec being widely available for some years, vendor support is still hit-and-miss and is now actually going in reverse.
As per the w3c github for this, there are a number of issues regarding executionContexts. The wildcard ('*') mentioned by Greg in their answer is not supported by Chrome, and Mozilla are about to remove the cache value as well.
All this points to a flawed standard which is likely to be removed at some point in the future.
When navigating my site, my browser is loading the JS files from cache, but not the CSS files. This happens both running a local server and on the live site (to me and apparently to other users, which is apparent since the logs show mostly .css files getting loaded).
I've tried the other solutions (example): I am clicking around on hyperlinks (not refreshing) and my Chrome Devtools do not have "Disable Cache" checked.
Here is the initial request (using CTRL+F5 for a hard refresh):
Then navigating back to that page creates another request:
(Note: there is no Cache-Control sent in the second request, proving that I indeed did not refresh)
As expected, the server responds with a 304 Not-Modified for the .css file, but I don't understand why it's making a trip to the server at all (notice below the .js file is retrieved without a server request).
I believe you can look at the issue first-hand on your own machine by going to https://up.codes. I'm using Chrome 71.0.
Why are the CSS files not being cached?
#Allen found the issue (Vary header included cookie and the cookie was changing between requests), but I'll show how to fix it for the case of Flask for posterity. You can use Flask's #app.after_request() hook to make sure Flask does not add cookie when it hits this line:
#app.after_request
def add_header(response):
url = request.url
if ('.css' in url or '.js' in url or '.svg' in url or '.png' in url or
'.gif' in url) :
# Flask adds to the header `Vary: cookie` meaning the client should
# re-download the asset if the cookie changed. If you look at the Flask
# source code that comes next after the below return, it will add
# `Vary: cookie` if and only if session.accessed is true.
session.accessed = False
return response
Your server responded with different session cookie when requesting these css files, and your header set with Vary: Cookie, which caused the browser to send request again because of the session cookie change.
Check out for your web.config's compilation attribute, if its:
<compilation debug=”true”/>
CSS will get continually downloaded by clients on each pageview request and not cached locally within the browser.
If its set to false, the resource is only downloaded once to the client and cached there.
Check out this post: Chrome will not cache CSS files. .js files work fine
Chrome uses multiple types of caches.
Blink (the rendering engine that Chrome uses) uses an in memory cache and a disk cache. It uses this cache for images, fonts and js files.
As long as a file of that type is still in the memory cache or the file cache it will be loaded from there and skip the WebRequest API, this means that no call is made to the server.
I don't know exactly why css files are not being cached by Blink, but this is the reason why you see an HTTP request for css files and not for js ones.
Note, that if, for some reason, the js file is evicted from the memory cache and the disk cache you will see an HTTP request for the js files also.
I have a page that is being cached, so when I log out it's reloaded from the disk cache without ever hitting the server. If I disable the cache via the browser's network inspector, it reloads the page correctly by requesting the page from the server, which then redirects to a login screen. That solution only works in development.
Is there a good way via either the web.xml or the weblogic.xml to disable caching of the html page itself?
I've looked at setting the resource-reload-check-secs value to 0
and 1 as suggested here, but this does not work for me since the
resources have not changed.
I've also seen Weblogic's cache filter, but it's deprecated.
I've got an odd question. Say I have two HTML pages index1.html and index2.html. In both the pages is some jpg image called "Hello". When I use the browser to point to say www.testing.com/index1.html the browser will load index1.html and the image Hello.
Now my question is when I go click on some link in index1.html that takes me to index2.html, will the browser look to go to back to the server to get image Hello or will it use the Hello image used in index1.html?
It depends on the caching headers the server sends out alongside the image.
There are several ways in which caching can be done.
When a resource is served with an expiry date in the future, the browser will use its cached copy until that date is reached (or the cache is emptied or a refresh forced.
Another way is for the server to listen to the If-modified-since request header. The server can then check whether the resource has been modified since that date. If it hasn't, it will return a 304 not modified status; otherwise, the updated resource.
The Apache Caching guide is a (lengthy) introduction to the subject.
To see in your browser what caching rules apply, open its developer tools and look for the "Net" tab. It's a list of all the requests that were made in connection with the current page. It'll tell you whether a resource was loaded from the server, or a cached copy used.
For example, this result on a Stack Overflow image from Chrome's developer tools:
suggests the image was cached. When I click that row, I can switch to the "header" view, where I can see the exact caching instructions the server sends:
It means that as long as the browser has a cached copy of the image, it will keep on using that without ever checking with the server until December 17, 2014.
Different browsers handle this differently. It can also depend on user settings. Users can set the browser to cache nothing if they so desire.
Opera keeps loading on my page, it shows something like 64/64 elements loaded or 44/44. How do I find out what makes it load so long? This problem only occurs in Opera, Chrome, Ie and FF just finish loading.
One easy way to see if it is indeed a pending network request (for an image resource, or css, etc) is to install Fiddler debugging proxy. After starting the Fiddler tool and navigating with your browser your website you'll see what network requests are issued and their respective status (pending, completed, error, etc)... Check for a "pending" network request...