Originally Posted by Galatea
That is not correct. HTTP defines different types of caching, and different policies. What you described sounds like the policy is set to no-store, which specifies caching is allowed in ram, so long as it does not hit any sort of persistent store. That should give pretty good performance after the initial origin loads occur, and for most people would have basically as good interactive experience as caching to disk. It certainly seems weird to be used in this case, but just because you are not caching things to disk does not mean there is not caching going on. For all the details checkout RFC2616 section 14.9 (well, most of the details, there are some extensions like etags). Note that this does not mean the site performance is good, but rather that caching between sessions would only speed up the initial load, not subsequent browsing. |
I'm well aware how HTTP caching works, thank you for the RFC link anyways. Theory is one thing, real world is another.
What I'm saying is that the browsers I've tested are inconsistent in how they caches pages. In Firefox you can type about
:cache and see the contents of the disk cache, how long it's supposed to survive and how many times it's been used.
The armory images should get a 3-4 hour timeout on the disk cache, it's visible from the header data, but it's just not always happening. Now I don't particular care much to find out why, but considering it does it on several computers AND totally different browsers I'm guessing it's a feature from the armory server and not on my side.