Many browsers have one setting to discard cache records over a certain age, and another setting to discard cache records over a certain space limit. When I have checked them I like to set them to 1 week and 64MB.
On Sun, Apr 2, 2017 at 4:55 PM, Joel C. Ewing <jcew...@acm.org> wrote: > On 03/29/2017 09:04 AM, John Eells wrote: >> John Eells wrote: >>> R.S. wrote: >>>> Off-topic note: the document mention z/OS 2.2 can be ran on z9 machine, >>>> which is untrue. >>> >>> You are, of course, correct. The book has been updated but not the link >>> to the new level of it. Here is the new level of the book: >>> http://publibz.boulder.ibm.com/epubs/pdf/e0z3f113.pdf >> >> Talking with the person responsible for the book and the link, we >> found there is a bug in my browser. It's supposed to compare the page >> on the web to the cached one and refresh it if they differ when the >> tab is opened, but for some reason it did not. That is why I found >> the lower level of the book instead of the current one. Clearing the >> cache "fixed" it, and now the updated links are the ones I see on the >> page. I have never seen this failure before, so it was quite a surprise! >> >> Anyway, the book and the link to it are both current already. >> > That's not necessarily a "bug" in the browser. If the data served by a > website in response to a GET request doesn't explicitly give an > Expiration-Age and a Last-Modified time stamp for the data, a browser is > forced to use heuristics to determine a time after which a local cache > copy should be regarded as expired -- and different browsers may > determine different values for that expiration time in seconds. > > If the browser thinks the expiration-age of cached data has not yet been > reached, it will not even attempt to re-validate whether the cached copy > agrees with the current web site, but just assume it is OK to reuse. I > have no knowledge of design choices made for specific browsers, but I'm > guessing that unless there is a bug, most browsers would avoid assuming > overly long cache expiration times unless there was something explicit > in the served data that suggested that was appropriate. When the > browser sees by the expiration time that it needs to re-validate the > cached data, there are ways it can request a new download iff the server > version has a later modification time stamp than the cached data time > stamp, but for this to work correctly does presume that both the browser > and server are dealing with time stamps in a consistent manner. > > If you have reason to suspect the browser is showing an obsolete cached > copy for a web page, you can always force a re-validation and possible > new download by explicitly telling the browser to "reload" a web page. > If a web page is constructed from several "frame" pages, it might be > necessary to isolate a suspect frame into a separate tab by itself and > then force a reload on that one frame to get it to refresh. > > Clearing cache will certainly get rid of any obsolete cached data, but > that may be overkill. In many cases just a simple browser "reload" > operation on the web page will be sufficient. > Joel C. Ewing > > > -- > Joel C. Ewing, Bentonville, AR jcew...@acm.org > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
