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
jr...@inverse.ca :: +1.514.447.4918 (x120) :: www.inverse.ca
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)
--
users@sogo.nu
https://inverse.ca/sogo/lists
