from Dive into HTML5: Cache Manifest: Fallback section
CACHE MANIFEST
FALLBACK:
/ /offline.html
NETWORK:
*
i dont understand from the URL given what this block of code exactly does. does the fallback section mean when anything is not found, show the offline.html page
then network: * all resources will be cached? it says also
It uses common CSS, JavaScript, and
images on each page. Each of these
resources would need to be listed
explicitly in the CACHE
this seems to conflict to network: * where it seems to say cache everything?
There are three types of headings in a cache manifest, CACHE, NETWORK and FALLBACK. Anything that is not under a heading is implicitly set under CACHE. An explanation of each section:
CACHE: Files under this heading will be cached.
NETWORK: Files under this heading require an internet connection and so will be NOT be cached.
FALLBACK: Files matched by patterns under this heading (Such as the pattern "/", which matches all files) and have not been cached, will have a fallback file shown instead.
With regards to the block of code from Dive into HTML 5, there is an explanation of the "NETWORK: *" part just under it:
It means that, while you’re browsing
this hypothetical offline-enabled
Wikipedia online, your browser will
fetch images and videos and other
embedded resources normally, even if
they are on a different domain. (This
is common in large websites, even if
they aren’t part of an offline web
application. HTML pages are generated
and served locally, while images and
videos are served from a CDN on
another domain.) Without this wildcard
flag, our hypothetical offline-enabled
Wikipedia would behave strangely when
you were online — specifically, it
wouldn’t load any externally-hosted
images or videos!
The following quote:
It uses common CSS, JavaScript, and
images on each page. Each of these
resources would need to be listed
explicitly in the CACHE
means that you must include all necessary CSS, Javascript and image files in the manifest under the CACHE heading. It does not conflict with 'NETWORK: *' because the NETWORK heading does NOT mean 'cache everything'. It actually means the opposite: that everything under the NETWORK heading requires an internet connection and should not be cached.
I have found out more useful stuff about FALLBACK:
After a bit of experimenting, I tried various things including whether files in FALLBACK: should appear in the CACHE or NETWORK sections at all. The answer seems to be no.
As an example...
FALLBACK:
sign-up-portrait.png offline-portrait-1.png
sign-up-landscape.png offline-landscape-1.png
I specified this in one of my micro sites recently. The intention is to show the sign-up- png files when online and the offline- png files when offline. This works well. In particular the files on the left side of each line are implicitly as if they were in the NETWORK section, the site will always try to get them online. They must not be added to the NETWORK section as well, otherwise it seems to override what's in FALLBACK.
Plus, happily, the files on the right are implicitly as if added in the CACHE: section so even if they are not used at first, they are cached on first load without having to explicitly add them to CACHE: although you can add them there too if you want. It makes no difference.
For this configuration, looking at the webserver logs, I see that each time the page is refreshed, apache logs a 304 against the manifest file and against the sign-up- png file that's required for that version of the page (there's a CSS media selector determining which, based on page size). So it's correctly always checking for the sign-up- png files as well as the usual manifest checking, which is exactly what I want.
For the sake of being thorough, I tried to see if the root file needs to be in the CACHE: section too. It turns out it doesn't! If your top level file is index.html and it has the manifest file specified in its html tag then the manifest file need not contain index.html anywhere, it's implicitly cached.
I am curious how far the app cache can extend. Can you include other html files that are linked to or in iframes? Or do those all need to have their own manifest files that are separate? Anyone care to comment?
A side comment about format, don't make the mistake I did, which is to put in...
NETWORK
file1.js
Missing the colon causes it to totally break, thinking that NETWORK is a resource in its own right.
It must be...
NETWORK:
file1.js
Related
I wanted to use file extensions within the question body to make it clear as possible but the system kept throwing code errors at me when I hadn't used anything like code.
I have numerous pages that comprise a section of my website. Let's, for example, call the main page:
http://www.articles.mysite.com/
With in that, let's say some of the html files are:
"10things"
"extras"
"t7n"
"i2""
Essentially, the file names tie into what they contain, but they don't all follow the same name pattern for whatever reason (some are just numbers, some are numbers and some are numbers and letters together, for instance).
What I want to do now is upgrade these files so I can use serverside includes (SSI's) as I do on other pages of my website. However, I'm running into a couple of issues.
The URLs aren't clean (they have file extensions) and the same is true of links I've posted to social media, for instance. I'd like the resultant URL the user sees to not show these file extensions, partly for SEO and partly just to make it look less cluttered.
When I've tried upgrading the files by just changing their names, the links on my end appeared to work, but when using one of the social media links, I kept getting 404 errors so I started from scratch and kept trying to resolve the issues on my own. Unfortunately this hasn't worked and I'm now back to square one, with the links currently working with standard files.
To reiterate, I'd like the following to occur:
User clicks a link, whether directly on my site or on a social media site that takes me to a page on my own website.
Even if the link is one of the old ones, the user is silently redirected to the new version of the page, with a clean URL that does not include any extension for better readability and SEO purposes.
All this should ideally be able to happen without me needing to change the index files that store the links, only renaming the html file extensions.
The only two pieces of information that might be of help if I can figure out how to combine them are as follows:
This introduction to redirects, which references mapping file types as part of redirect matching with the same path and filename:
Could this be modified, changing the extensions used, to map the requests to the new renamed files from the old extension?
This previous question from Stack Exchange about rewriting and redirecting at the same time which talks about cleaning up extensions:
Could this be combined with the redirection in the previous question to make a clean and easy method of redirecting the user, cleaning up the extension and making it look as if nothing's changed with a file name being all that's required other than the above code?
You can use this code to redirect your .html page to .shtml page without changing any line of code.
#redirect .html link to .shtml link
RewriteEngine On
RewriteRule ^(.*)\.html$ $1.shtml [L]
I apologize in advance for the generic examples of this since the issue is with a proprietary corporate system.
I support a web app that allows for edits to a secondary CSS file in order to style the page (within the limits of the application). I'm trying to apply a non-standard font that is used company wide but I do not have access to edit the HTML or header of the site, only the CSS. I tried declaring the font-family in the main CSS while referencing the actual font file URLs (since they are used on our corporate site) but they never actually loaded.
I then took the same font-family snippet and created a separate CSS file for just the font declaration and changed the URL to point to the actual files in the relative path (ex: url('fonts/DINWeb.woff') ). I moved this fonts.css file along with the reference font files (eot, ttf,and woff versions) to a public Dropbox folder for testing. I was able to get everything working by simply importing the fonts.css file using the line of code below (URL modified) at the top of my application's CSS.
#import url('https://dl.dropboxusercontent.com/.../fonts.css');
The problem is that the Dropbox solution was just for temporary testing purposes. Once I confirmed everything worked as expected, I moved the exact folder structure to an external hosting location that is approved for use. When I update my import code in the CSS to the new URL, the font does not load. I can access the CSS file and the font files from my browser without any issue so I don't understand why the web app fails to load it. I also have images hosted in this same hosting location that pull into the web app without an issue, it's only the font that has issues. The files work when hosted on Dropbox but not the other source. I've also double checked the references for the URL and they are still correct since the folder structure never changed.
Any suggestions would be GREATLY appreciated. Ideally I would like to just reference the corporate URLs directly in the web app's CSS like I initially tried. If that will not be possible, I need it to work with the externally hosted files since Dropbox cannot be used as the permanent solution.
Basically you cannot load from one domain resources hosted in other domain, unless the second host says that you can. See CORS
You can solve it by moving everything to the same domain (or forcing the user to be always in certain domain) or by adding the Access-Control-Allow-Origin header to the responses.
You can achieve this last thing if you can edit an .htaccess file in the server. Add:
Header set Access-Control-Allow-Origin "*"
Or replace the * with the domain from which you'll be making the requests.
Yes, a subdomain is a different domain (abc.com, www.abc.com and dl.abc.com are not the same).
I made some css changes to my custom css file and uploaded the css file. However the changes are not shown. I have tried all of following:
remove var/cache/*
flush js/css cache from magento admin
clear browser cache
flush siteground cache
I even tried removing the css file and then access it from url URL, the old file content still shows but the css effects were gone on front UI.
what could be wrong.....
It is likely that your browser is still caching your CSS files. One way to check if it is indeed the browser and not say accidentally editing the wrong CSS file is by enabling and disabling the CSS file merge. By doing so you are forcing the browser to fetch for a whole new file - essentially bypassing caching.
You may also want to take a look at our CSS/JS Versioning extension which includes automatic refresh of the file name hash based on CSS/JS file timestamps (sensitive to editing and changes) http://extensions.activo.com/css-and-javascript-versioning.html
For my mobile application I want to use pushState and AppCache, but this seems to be tricky.
To make pushState work, my web server redirects every url (except assets like the manifest file itself, images, css- and js files) to /index.html internally.
E.g. a request to /articles/123 will redirect to / respectively /index.html (so the originally requested URL is still visible in the browser).
This causes the request to the manifest.appcache to a wrong path, like /articles/123/manifest.appcache instead of /manifest.appcache, which leads us to the problem that the browser creates a new cache group for every directly accessed URL (e.g. by a Google search)
I redirect (.*)/manifest\\.appcache to /manifest.appcache and it is interpreted, so that should work as expected. I think the main issue is that the browser treats the manifest.appcache file on URL level instead of domain level.
So this leads me to the following questions:
Is this a practicable approach?
If yes, can I tell the browser to use the AppCache on domain level and how?
If no, what am I not thinking through?
When you put the manifest attribute on the <HTML> element just set the path properly to point to the root directory:
<html manifest="/appcache.manifest">
I am a beginner with node.js and am using express with the ejs layout, and I want to know how to get rid of the .html extension when putting up a page. For example if I go to my localhost:3000/about.html - that works but I want it to show up as just /about. Also, having trouble figuring out how to change the favicon if anyone knows how to quickly change that from the express default.
Any help would be great thanks.
(I realise this question is old, but it appears high in Google search results, and the accepted answer isn't the best solution.)
The best solution for serving up static content in express.js is express.static. To avoid having to specify file extensions in URLs you can configure it with a list of default file extensions that it will use when searching for static files:
app.use(express.static(pathToBaseFolderOfStaticContent, {
extensions: ['html', 'htm'],
... // Other options here
}));
This will serve up pathToBaseFolderOfStaticContent/somePage.html or pathToBaseFolderOfStaticContent/somePage.htm in response to a GET request to http://www.example.com/somePage, which is what you want. For example, if you visit https://arcade.ly/star-castle, the file it serves up is just a static file called star-castle.html. I haven't had to add any special routing for this, or any other static file - it's all just handled by express.static.
I only need to add specific routes for content that requires active work on the server to return. A big advantage here is that I can use a CDN to cache more of my content (or nginx if I were running an internal line of business app), thus reducing load on my server.
You can obviously configure as many default file extensions as you like, although I'd tend to keep the list short. I only use it for resources where the URL is likely to appear in the address bar, which generally means HTML files, although not always.
Have a look at the following documentation on serving static content with express.js:
http://expressjs.com/en/starter/static-files.html
http://expressjs.com/en/4x/api.html (the express.static documentation is at the top)
This is also answered at In express what is the common way to associate a default file extension with static content requests?.
The favicon.ico issue can be solved by dropping your favicon into the root folder from which you serve static content, as well as implementing +Costa's solution where you reference it using a <link> in the <head> of your documents.
In theory you shouldn't need to do put the favicon in the root folder but, in practice, some browsers will still ask for it from the site root even though it's referenced in the <head> of your document. This leads to a spurious 404 error that you'll be able to see in client side debugging tools (e.g., Chrome dev tools).
The Favicon issue is usually a caching problem. As long as you have this code in your base html layout:
<link rel="shortcut icon" type="image/x-icon" href="/images/favicon.ico">
Then just navigate to wherever that image is with your browser, and that should force your cache to update.
I figured it out. I looked at this post Render basic HTML view? which solved the problem I was having.
app.engine('html', require('ejs').renderFile);
app.get('/', function(req, res){
res.render("index.html");
});
And this all goes in the app.js or whatever file you are running.