Is there a <meta> header that I can add to not cache the index.html page itself but to allow caching for all other assets on that page (images/js/etc).
The reason I need to do this is because when I update my website with new javascript files that are named differently, sometimes when I bring up the updated site, the website tries to load the old files and I have to force refresh the page to update index.html.
(I'm sorry if this is answered before. After searching all stackoverflow posts seem to give great comments but to do not confirm or deny whether other assets on that page will be cached)
Related
I made a directory called downloads where I will have files that I want people to be able to access with the direct link on my Jekyll site, however I don't want them to be able to go to https://example.com/downloads and then see all of the downloads.
How can I turn off visitors from seeing the index page?
There are two approaches.
You can make an actual /downloads/index.html page that will be shown instead of the default directory-like page.
You can use the jekyll-redirect-from plugin and redirect the url /downloads/ to your 404 page, for example.
I am currently working on a site which is built in using a Custom Designed CMS (there are files with .asp extension). This site is really old and seems like running on IIS Server, which I don't have the access. User asked me to add few items. I made changes to index.html file and uploaded to the server, however, the changes don't seem to take in affect.
So my question to Pros, is, do i have to restart the IIS instance? I tried to change the index.html existing content such as Search Bar's placeholder text from Search to search, uploaded the page and nothing happened. Also added new p tags and no luck.
I have never dealt with IIS site. Any suggestions? One thing for sure I can see is that the Home Page in Custom backend is pointing to the index.html file (which I am altering).
Not at all. I does require a reload/refresh at the client-side though.
-Tango
For performance purposes, I want to have some of my web pages use resources that have been cached for offline use (images, CSS, etc.) but to not have the page itself cached as the content will be generated dynamically.
One way to do this would be to refactor my pages so that they load the dynamic content via AJAX or by looking things up in LocalStorage. Details may vary, but broadly speaking, something like that.
If it's possible, I'd prefer to find a way to simply instruct the browser to use cached resources (again, images, CSS, etc.) for the page but to not actually cache the (dynamically generated) HTML content itself.
Is there a way to do that with HTML5 offline appcache? I'm under the impression that the answer is "no" because:
Any page that includes the manifest will be cached so I can't specify the cached resources in the page itself.
There is no way to tell a previous page "use offline assets for this other page but don't actually cache the HTML on that page". You have to specify the page itself, which means the HTML will be cached.
Am I wrong about that? It seems like there is probably some tricky (or not-so-tricky) way around that. Now that I've typed it out, I wonder if including the page explicitly in the NETWORK section of the appcache manifest will do the trick.
My answer is "yes".
I have worked on a web-app where I listed all the necessary resources in the manifest, and set the NETWORK section to *.
The manifest is then included only on the main landing page. So all resources are cached the first time you visit the site and and it works a treat.
In short,
one of your pages must include the manifest and will therefore be cached.
maybe you can have the manifest loaded in a iframe and not have the whole page cached, just a thought.
list all your resources to be cached in the CACHE section
set the NETWORK section to *
I'm fairly certain that the answer to this is no.
If you use the Network section in Chrome, then it shows which resources are loaded from the cache and which are loaded from the server. I have attempted to set the appcache as described above and the resources are always loaded from the server.
Would I be correct in assuming that if the current page is not in the appcache then it wont bother to check in the appcache for any of the resources?
What I've found that is working is to list those files that you don't want cached in appcache in the NETWORK: section of the manifest. For me, that meant adding *.asp* to the network section. Now, none of the classic asp files, or aspx files are cached.
I'm trying to work out if something is possible with cache-manifest.
I have a mobile web app with about 5 pages. They all require connection to work in a meaningful way.
I'd like to handle gracefully the possibility that the user is offline.
So, would it be possible to use cache-manifest to replace every page on the site with another, "offline-only" page, while the user is offline?
I was hoping this was what the FALLBACK section of cache-manifest does, but it seems not.
It does work, your fallback section should look like this:
FALLBACK:
/ offline.html
If you reference that from a page in the root then any random string you type in will result in offline.html being loaded, including pages which don't exist, whether the server is online or not.
I'm guessing that the issue you're seeing is that any page which references the manifest is always cached. So if you've referenced the manifest file from each of your five pages then all of those pages will be in the Application Cache.
One approach which might work (I've not tried it): create a new page specifically to reference the manifest file and redirect your users to it when they first visit. You could put some content on the page like 'initializing application'. Verify the Application Cache has been loaded with JavaScript, then redirect back to the page they came from.
I have a web site with an index.html homepage that is updated from time to time. We sometimes add offers for our clients, special messages and so on, which have to be visible by next day for everyone.
If index.html is cached by browsers, many users will not notice that anything has changed, unless they explicitly refresh the contents of the page...
Which is the best way to be sure that 100% visitors have an up-to-date index.html page, without compromising cache performance?
My best answer would be to skip out on updating the index.html each time and go with a server-side programming language, like PHP. You can then set the headers for the page to not cache, and you can also set up an admin page that you can use to change the content. Or you could go with a browser-side script with JavaScript using AJAX. Then the page has an ability to update before the next loading of the site.