Quoting Eric Rostetter <[email protected]>:
Quoting Michael M Slusarz <[email protected]>:
It appears a bunch of people are having the same issues on
upgrading, and in almost every case it is because they don't have
their server (either Horde or their HTTP server) correctly
configured regarding caching of javascript files.
I tried clearing the cache and disabling the JS caching in Horde, but
get the same errors (on screen at least).
If not already obvious in the configuration literature (maybe it
isn't... I don't have it in front of me right now), unless you
*really* know what you are doing, you should almost certainly be
using static files to deliver JS. This is the ONLY guaranteed way
to cache-bust across ALL browsers.
Obvious? Let's see, from the administration page:
Javascript caching packages all static javascript files used in a page into
more efficient chunks to send to the browser. It also allows
compression and
optimizations of this file to reduce the data size. Caching reduces server
load, speeds up the user's browsing experience, and is HIGHLY RECOMMENDED.
HIGHLY RECOMMENDED doesn't seem to make it clear that it shouldn't be used --
quite the opposite I would say...
Or do I have something wrong here
Yes, you are incorrect. The above *is* describing caching of javascript.
Realize there are 2 different caching schemes we are talking about
here. There's the server-side caching strategy, and the browser
caching. The above is describing javascript caching to the extent
that all files are packaged into a single file. This drastically
improves performance, since the latency of having to download a bunch
of separate files have been eliminated - especially since loading of
javascript files necessarily blocks processing of the rest of the
page. (It also used to be the case that browsers would only download
a max of 2 files at a time, although I believe this is no longer the
case with the newest batch of browsers.).
The above is "server-side" caching. On the browser side, we want to
make sure that we cache javascript files since we don't need the
browser to be downloading the same (large) files over and over again.
But this is problematic in an auto-update scenario since, if these
files are overwritten in-place, this will very likely result in the
unfortunate situation where the javascript file is not ordinarily
immediately visible to the browser as being changed. (Browsers are
notoriously clingy to their cached javascript files).
E.g. using NO Horde-defined browser caching strategy, a javascript
file is normally served directly as a regular file by the HTTP server.
However, there's a decent chance that the HTTP server is configured
to send a cache header for this file. Or, in the absence of cache
headers, the browser itself will internally cache the file.
The only 100% reliable way to bust this is by changing the URL of the
javascript files being served by the browser. And the only way to do
this 100% reliably is via static files. We give the option to serve
javascript via horde_cache, but my hunch is that this method is
completely outdated and is causing more problems than it is worth.
The problem is that we serve javascript files in this latter method
through a single static script - to a browser, this appears to be a
single file living on the server. We can try to do things like add
bogus random text to the query string, but browsers are smart and will
ignore this information (as they should, since the underlying page is
still the same). Thus, the browser will use the cached version until
it expires ON THE BROWSER SIDE before loading again from the
horde_cache javascript backend.
In short, if you are going to update your server on a production
system, you need to use static files to serve javascript. Period.
michael
___________________________________
Michael Slusarz [[email protected]]
--
IMP mailing list
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: [email protected]
