Another benefit of having a cache is, that after you have disconnected from the network, the pages remain on your computer. You can then browse through them again off-line.
Whenever you click a link (or type an URL), or an embedded image on a page is needed, AWeb first looks in its cache to see if it is already there. If the object is in memory, it is used immediately. If it is still on disk but not in memory, it is loaded back into memory. If it is not on disk, it is fetched over the network.
A reload of an object never uses the cached copy, but fetches the object from the original location again.
Static objects are simply items that don't change from moment to moment, although they may change over the long term as a website is updated. An image or standard HTML page is an example of this. Dynamic objects are those that are created "on the fly" or "on demand" by a server. That is, content differs each time it is downloaded. This is commonly performed via a PHP script, for example.
There is no standard defined way to determine whether an object may be considered static or dynamic, but usually static objects have the "Last-Modified" HTTP header defined, so AWeb uses this to differentiate.
If the original object has been updated since it was stored in the cache, the cache copy should be updated as well. Therefore, when AWeb uses a cached copy of an object, it also sends a verification request to the server, to see if the object was modified. If not, AWeb will use the cache copy, and if the object is modified, AWeb will fetch the new version.
You can control how often AWeb will check with the server:
When you browse off-line through cached pages with AWeb set to one of the other response modes, AWeb silently falls back to verify never mode. So it won't complain that it cannot connect to the server, and won't try to start your TCP stack just to verify cached objects. Of course it will do so when you try to fetch an object that is not in cache.
In most cases, the cached copy will still be valid. After all, that is one of the reasons for having a cache in the first place. So slow verification will let you wait many times totally unnecessary.
When using fast response mode, AWeb always uses the cached copy if one is available. The cached document or image is displayed immediately. In the same time that the object is displayed, AWeb connects to the server and verifies if the object is indeed not modified. In most cases the copy will still be up-to-date, and these connections disappear silently after a few seconds. This way you will gain a few seconds with every link you follow to a cached document.
In the few cases where the object was modified, you will first see the old version that was in cache. Then after a few seconds, when the server responds, the new updated version will be shown in the window, much like as if you had hit the reload button.
If this behaviour confuses you or annoys you, you should not use fast response mode.
The recommended setting is to verify "Always" without Fast response for Dynamic objects, and verify "Once per session" with Fast response for Static objects.
file://localhost
). Because these
objects already reside on your harddisk, there is no reason to store them
again in the cache.
Should your machine crash (or be turned off) while AWeb was still active, then the next time you start AWeb the cache will be recovered automatically.
AWeb stores its cache files in several subdirectories. That way the number of files in each directory is kept low, which will result in a much faster cache when used with certain file systems (like AFS).
Note that you should not use the cache directory for anything else. Also,
don't modify or delete any files.
If you accidentally deleted some files
from the cache, or if you suspect that it has become corrupt, you
should use the Cache / Fix cache...
menu item. It will
synchronize the internal registration with the files actually on disk.
NOTE: This function will delete any files from the cache
directory that are not belonging to AWebs cache.