General discussion on installation and configuration of SOGo

Text archives Help


Re: Browser cache and upgrades (Was: Re: [SOGo] ANN: SOGo v1.3.15)


Chronological Thread 
  • From: Jean Raby < >
  • To:
  • Subject: Re: Browser cache and upgrades (Was: Re: [SOGo] ANN: SOGo v1.3.15)
  • Date: Thu, 24 May 2012 14:34:40 -0400

On 12-05-19 4:48 AM, Jean-Michel OLTRA wrote:

Bonjour,


Le vendredi 18 mai 2012, Jean Raby a écrit...


After clearing the browser cache, all went well. I had a look to the
mtime timestamp of the files: it was the one of the upgrade.

I've been trying to reproduce this issue for a while, but it simply
doesn't happen on my setup...

At least, this sequence doesn't reproduce the problem:
1. Install 1.3.14
2. Login, check mail, logout
3. Install 1.3.15.
4. *Restart SOGo*
5. Login, check mail, logout

However, if SOGo is _not_ restarted after the upgrade, the client
will see a mostly empty page.
This is due to the fact that we moved from scriptaculous.js to
jquery.js between 1.3.14 and 1.3.15.
The running SOGo would send references to the non existing
scriptaculous.js and the client would get a 404.

Clearing the cache and doing anything on the client side can't fix
this, sogo has to be restarted.

Could this be the source of the problems you were facing?

Yes clearing the client cache fix it. I am sure of it, because I asked
the user to clear the cache, live during a jabber session!, and the
mails appeared just after (the user was complaining all day long about
its lost mails).

And I am mostly sure that I have restarted SOGo after its upgrade. I
_always_ restart SOGo after an upgrade. I double check my bash_history,
and can see the `/etc/init.d/sogo restart` after the
`aptitude safe-upgrade`, so I am now 100% sure of having restarted the SOGo
service!


We could finally reproduce the issue and it should now be fixed in the nightly builds (sope).

The problem was that apache wasn't returning any 'Expires' header in
its responses for static content.
This lead to browser specific behavior, where chrome and firefox would
cache the content for a certain time. The time is derived from the last-modified header and could be pretty long if sogo had not been updated for a while.

When a resource is cached like this, the browser does not even send a
GET request for it, it simply pulls it out of its cache. (which is fast)
However, clients would end up showing stale content (js, css, images, etc...)

To work around this issue, the filename of a resource will now change each time the underlying file is modified.
Basically, the resources now have their mtime appended to their name,
for example : /SOGo.woa/WebServerResources/jquery.js?lm=1337817165

Now that we have this fix, we can tell the browser to cache the resources for a long time.
The default apache configuration has been updated to allow the caching:

<Directory /usr/lib/GNUstep/SOGo/>
AllowOverride None
Order deny,allow
Allow from all

# Explicitly allow caching of static content to avoid browser specific behavior.
# A resource's URL MUST change in order to have the client load the new version.
<IfModule expires_module>
ExpiresActive On
ExpiresDefault "access plus 1 year"
</IfModule>
</Directory>

Hopefully this will be the end of this annoying behavior.

--
Jean Raby

:: +1.514.447.4918 (x120) :: www.inverse.ca
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org)



Archive powered by MHonArc 2.6.18.

Top of page