[imp] Problem with H4 IMP Dynamic mode

[Michael M Slusarz]

Quoting Eric Rostetter <eric.rostetter at physics.utexas.edu>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> 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 [slusarz at horde.org]