I have a situation where my page loads some information from a database, which is then modified through AJAX.
I click a link to another page, then use the 'back' button to return to the original page.
The changes to the page through AJAX I made before don't appear, because the browser has the unchanged page stored in the cache.
Is there a way of fixing this without setting the page not to cache at all?
Thanks :)
Imagine that each request to the server for information, including the initial page load and each ajax request, are distinct entities. Each one may or may not be cached anywhere between the server and the browser.
You are modifying the initial page that was served to you (and cached by the browser, in most cases) with arbitrary requests to the server and dynamic DOM manipulation. The browser has to capacity to track these changed.
You will have to maintain state, maybe using a cookie, in order to reconstruct the page. In fact, it seems to me that a dynamically generated document that you may wish to move to and from should definitely have a workflow defined that persists and retrieves it's state.
Perhaps set a cookie for each manipulated element with the key that was sent to the server to get the data?
Related
Currently, I am facing an issue with HTML page. So here if a user visited the site then the browser is caching the entire HTML page. So when the user hits the URL again then the browser taking that HTML from the cache instead of calling/requesting to the server for HTML contents. Here our Team member forgot to add meta tags which would force the browser to take content from Server each time. Is there any way that we could resolve the issue? Since the page request itself not reaching the server so User will not see the refresh contents of the website. If user do Ctrl+F5 then they can see updated contents. I went through many sites and stack overflow questions but I did find a solution for forcing HTML page to load contents from server using meta tags.But existing users is there any resolution that we could apply?
Problem is here the page did not call server to get contents it just loads from cache.
There's nothing you can do.
You've previously instructed the browser to cache the file (presumably for a long time) and not check for updates (via ETags or If-Modified-Since) so it is going to use the cached version until its cache expires (from the user intervening or automatically (which might be sooner than your caching instructions said)).
There's no way to provide new caching instructions to the browser without it requesting them from the server (which it won't do because of the existing rules).
I've noticed that both Firefox and Chrome issue a new HTTP request when you view the source for a web page that you've already loaded. It's particularly annoying when the page itself is slow to load or if it won't load at all.
Why is that? Wouldn't they have the existing source for the originally received page cached already? Is it based on Cache-Control headers?
This has been on my mind for a while (usually, comes up when looking at what's behind slow web apps).
In the context of Chrome, according to this link it is indeed base on Cache-Control headers.
...view-source grabs the html source from the http cache
and pretty-prints it, but for the page NOT in http cache, it's 'forced to'
make a new request.
To me, this makes sense. You wouldn't want to use what is currently rendered as the source of truth as obviously the HTML can be manipulated dynamically. If you can't use this, then the http cache would be the next likely candidate for the source. If the source in unavailable from cahce, a subsequent GET of the source seems to be the only alternative.
This does, however, introduce another interesting delima raised here.
Requesting the URL again doesn't make sense as there is no guarantee that source received during the second request will match what was received during the first request.
I would imagine this was a conscious trade-off that was made to ensure that a view-source request is always satisfied in some form or another.
You need to do "Inspect Element" for the live web page. Show-code reloads the page to show the source code without modification.
I would like to know the mechanism behind reloading/ refreshing a Webpage. My questions are-
1. Does reloading/ refreshing a webpage that completely failed to load earlier always result in instant loading of the entire webpage correctly with all its contents?
2. Or does it result in delayed loading of the entire webpage?
3. Or does it result in delayed loading of the webpage with some contents (Ex. images) missing?
4. Or does it do nothing? ie., the page still fails to load because the server is down?
I know that all these scenarios are possible. But I would like to know what causes each of these above scenarios? (For Ex. is it the server being down or busy or the content not being available anymore?)
Also I would like to know what happens in these two cases-
->when content is fetched from a single server
->when content is fetched from multiple servers
Reloading does not always result in instant loading of the entire webpage correctly. There are many different reason a page may not load correctly, many of them simply reloading the page will not fix. There are so any reasons there really isn't time to explain here.
I should load with the same data it received before reloading the page. Unless something has changed in the interim.
If the server is down. Reloading the page will not result in the page loading correctly the second time.
When content is fetched from a single server the content comes from just that server. When content is served from multiple servers, say the images are being served from a CDN, they are loaded from those places.
Reloading a page does nothing different that when you first visit a page. Although in certain circumstances the local browser cache may be reset.
I see in Javascript; Sending user to another page and how to change page from within javascript references to using the window.location to switch to a new page. It is also possible to have a similar result by including a meta tag http-equiv with a refresh value.
While these work as advertised, I need something that will continue to retry in the event the host application is not available at the time the client starts up.
A cross-browser solution would be particularly appreciated.
Update:
My current solution does as suggested. Initial AJAX to verify connectivity, followed by an update of the window.location. My concern is exactly the one given - the status can change between getting the response and updating the page reference.
I could update a lower level element body.innerHtml, for example, in the page body, but prefer to change the top level element to cleanly switch over to the new page.
The purpose of the initial page is just to bootstrap a long running application that similarly uses an AJAX loop to fetch updates of both content and periodic page refreshes. The intent is to be able to drop off web display panels and have them automatically configure themselves when they are eventually connected to a network.
I have an appcache (with NETWORK *). So now I visit my page with <html manifest="/cache.appcache">. Then the page itself is cached as all the images are. But I want the page self to not be cached. How can I do this? I thought NETWORK * would do the trick.
Regards,
Kevin
The appcache manifest always caches the master page.
If you are using Chrome check the cached files for your page here: chrome://appcache-internals
A workaround could be to put a hidden iframe somewhere on your page, which contains the appcache file to cache offline content. (take a look at "Preventing the application cache from storing masters with an iframe" here: http://labs.ft.com/2012/11/using-an-iframe-to-stop-app-cache-storing-masters/ )
A better solution could be to write your page to fetch new content from your server when it is opened - if the server cannot be reached, it can serve the last known content from the HTML5 local storage.
I have tried the iframe work around, and find it ripe with errors. Most browsers cache the data for the iframe where the page cannot get it.
Instead make the page's content load via AJAX. Basically have a blank html page with the manifest and javascript which pulls and adds its content from the server. This way only the blank html is cached, and content is always updated from the server.
Converting a page to this method can be very difficult, but it works. Making sure the appropriate javascript gets run at the correct time, probably requires some detangling. Moving around server code which won't be called when pulling from cache to the new ajax method.
Note: no need to pull conditional content from the server if the condition is in the query string, different query strings make a separate cache