On 12-05-17 1:50 AM, Jean-Michel OLTRA wrote:


Le mercredi 16 mai 2012, Jean Raby a écrit...

Also, if you can reproduce the problem, can you post the apache logs
where apache returns 304 (Not Modified) responses? (which cause the
client to use its cached version)

Here is one of our customers who was not able to view mails after the
upgrade. Hope this helps!

xx.xx.xx.xx - - [16/May/2012:14:06:54 +0200] "GET
/SOGo.woa/WebServerResources/jquery-ui.js HTTP/1.1" 304 229
"Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20100101 Firefox/10.0.4

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?

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)

Reply via email to