FAQ of the Caching Mechanism in 331 Release

This document describes the caching mechanism in use the 331 release of the client source. If you still have a question that is not answered here, mail me and I will add it here along with its answer.

Q. 1. What gets cached?

A. Every successful return of a request that is of mime type image, text, message, and indexes of HTTP and java classes (including JAR files). (For HTTP this means 200, 203, 206, 300, 301, or 410 status response) Except ... (read the next answer)

Q. 2. What doesn't?

A. Secure documents, or documents specifically marked for "not caching" through-- "Pragma: no-cache" or a "Cache-control:" directive specified as an HTTP response header. Also see Q.4.

Q. 3. What about mail/news inline documents?

A. These are stored only in memory-cache.

Q. 4. Why are there two caches, disk and memory?

A. Security and performance- Certain HTTP documents are marked specifically not to be stored in local caches. These are listed above in Q2. However, to improve performance when reloaded only by the front end, they are stored in memory caches. In general, documents are stored preferentially in disk cache and not memory. Memory is used when disk is unavailable.

Q. 5. How are disk and memory caches used?

A. Depending upon the cache restrictions on the cache item, it will be added either to the disk or to the memory cache. If an item is marked as secure, and "dont cache SSL objects on disk" is set on or its a https: URL, then it will be stored in memory. All mail/news inlines are stored in memory. Only exception to this rule is when the object is set as a StreamAsFile for a plugin.

Q. 6. What is the image-cache for?

A. Certain images are transferred over the internet in a compressed manner. These are decompressed for faster layout and hence are stored in a decompressed cache held in memory. This cache is handled inside image lib (or ns/lib/libimg).

Q. 16. Why doesn't image-cache get cleared all the time, when we clear the memory-cache?

A. If you have some images that are currently being displayed in one of the windows of the browser and you clear your memory-cache, the images that are currently being drawn out by the layout engine are not removed from the image-cache.

Q. 7. How do I see what's in my cache?

A. Use the following reserved URLs-

Q. 8. What happens when I hit the Reload Button? And what happens when I hit Shift-Reload?

A. When you hit the Reload button, the browser checks to see if it has the document in its cache. If the document is present in the cache, It will then send an If-Modified-Since request to the server. Depending on whether the server sends a new response or a 304 (use local copy) the browser displays the corresponding document.

When you hit the Shift-Reload, it does a plain GET or an unconditional request and hence you never get anything from the cache.

Q. 9. How compliant are we with HTTP/1.1 caching?

A. Completely compliant. Also see HTTP/1.1 feature compliance.

Q. 10. What happens if memory or disk cache is set to zero?

A. There will be poor performance in reloads, or re-fetches. If only the disk cache is set to zero, the browser will tend to store all cachable documents in memory.

Q. 12. When does an item expire in cache?

A. Each cache item maintains an expires field which is filled from one of the following (in this preferred order)-

Q. 13. How does a cache clean up its files?

A. Oldest first. Evaluated from "Last accessed" and "Last modified." Preferentially the files that do not correspond to a "Last Modified" date, or are not from an HTTP URL get deleted first.

Q. 14. Does the caching mechanism support byte-ranges?

A. Yes.

Q. 15. What is item locking?

A. When a front-end or a cache consumer (like mail/news, plugins, etc.) uses a cache object, it locks the item for the session. This ensures that the object does not get deleted as a part of the expiration or cache cleaning process. This lock is only valid for the life of a session. FTP has an interesting mechanism- it locks the cachefile when a download is interrupted. This is because ftp restart is most interesting on huge files, but re-browsing to the ftp directory containing the file would usually otherwise flush that huge partial download. This was a hack. (Thanks Roeber)

Q. 16. So whats a session? Is that the same "session" in "Once per session"?

A. A new session starts when you initiate a new instance of Communicator. Yes that is the same as in "Once per session" in the preferences.

Q. 17. Is there ever a duplicate entry in memory for one in cache?

A. Never. An item will either be in memory cache or on disk.

Q.18. What does it mean when I see the cache cleaning up "x" many files? How is this number decided?

A. When the cache has been operational for a while, and the amount of available space for a new item becomes insufficient, the cache deletes approximately 10% of its size to make space for the item. Depending upon the average size of a file in the cache, a varying number of files may get cleaned up.

Q.19. Secure documents are not getting cached. Why and how do I change that behaviour?

A. From version 4.* onwards a design decision was made to remove the UI for "Disk caching SSL objects." This is still available as a preference and can be modified by editing your prefs.js file (Available under netscape/users/{your profile}/prefs.js. Note that standard disclaimer for preference-editing applies here. To allow disk caching of secure objects make sure the following line appears in your prefs.js file-

You will have to make this change after shutting down any running Navigator or Communicator. By default this value is false, and so no disk caching of SSL objects takes place.

Last modified on-