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

2012-05-24 Thread Jean Raby

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


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

2012-05-24 Thread Jean Raby

On 12-05-19 5:27 AM, Romain LE DISEZ wrote:

Hi all,

Le Vendredi 18 Mai 2012 18:40 CEST, Jean Rabyjr...@inverse.ca  a écrit:

However, if SOGo is _not_ restarted after the upgrade, the client will
see a mostly empty page.


sogod should be automatically restarted after an upgrade. That's how packages 
work in RHEL (eg: httpd, postgresql) and Debian.

A small patch is attached for RHEL. It is not tested, but it should work.


Thanks for the patch.
The daemon should now be restarted after an upgrade on rpm and deb 
platforms.

--
Romain LE DISEZ



--
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


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

2012-05-24 Thread Peter Peltonen
Hi,

On Thu, May 24, 2012 at 9:34 PM, Jean Raby jr...@inverse.ca wrote:
 We could finally reproduce the issue and it should now be fixed in the
 nightly builds (sope).

Will there be 1.3.15b or should one install 1.3.15a + updated sope
packages from nightly? And which of the sope packages should be
updated:

sope49-appserver
sope49-sbjson
sope49-xml
sope49-cards
sope49-gdl1-contentstore
sope49-gdl1-postgresql
sope49-gdl1
sope49-ldap
sope49-gdl1-mysql
sope49-core
sope49-mime

And is the nightly version 20120524 or 20120525 where this is fixed?


 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

And when updating should one add these changes to the Apache configs manually?

Regards,
Peter
-- 
users@sogo.nu
https://inverse.ca/sogo/lists

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

2012-05-24 Thread Jean Raby

On 12-05-24 3:06 PM, Peter Peltonen wrote:

Hi,

On Thu, May 24, 2012 at 9:34 PM, Jean Rabyjr...@inverse.ca  wrote:

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


Will there be 1.3.15b or should one install 1.3.15a + updated sope
packages from nightly? And which of the sope packages should be
updated:

sope49-appserver
The fix is in sope49-appserver, nothing changed in sogo regarding this 
issue.


And is the nightly version 20120524 or 20120525 where this is fixed?


It will be in 20120525 (tomorrow).



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


And when updating should one add these changes to the Apache configs manually?


Since this is a configuration file, yes, it should be changed manually.

Regards,
Peter



--
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


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

2012-05-19 Thread Romain LE DISEZ
Hi all,

Le Vendredi 18 Mai 2012 18:40 CEST, Jean Raby jr...@inverse.ca a écrit:
 However, if SOGo is _not_ restarted after the upgrade, the client will
 see a mostly empty page.

sogod should be automatically restarted after an upgrade. That's how packages 
work in RHEL (eg: httpd, postgresql) and Debian.

A small patch is attached for RHEL. It is not tested, but it should work.

--
Romain LE DISEZ
-- 
users@sogo.nu
https://inverse.ca/sogo/lists

patch-sogo_restart_after_upgrade.diff
Description: Binary data


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

2012-05-19 Thread Aaron C Johnson

Romain LE DISEZ wrote:

Hi all,

Le Vendredi 18 Mai 2012 18:40 CEST, Jean Rabyjr...@inverse.ca  a écrit:

However, if SOGo is _not_ restarted after the upgrade, the client will
see a mostly empty page.

sogod should be automatically restarted after an upgrade. That's how packages 
work in RHEL (eg: httpd, postgresql) and Debian.

About that... Both times that I did the upgrade, first to 1.3.15 and 
then to 1.3.15a on debian 6 64-bit, it reported that it restarted the 
service during the installation but it didn't actually kill the old 
sogod process...


I know this because I always tell daemons to restart after an upgrade 
whether apt-get says that they restarted or not (I don't trust it and 
for good reason).


Directly after telling sogod to restart after the upgrade it tells me 
that it's not running and that it is starting sogod. Then I do a 
/etc/init.d/sogod stop and a ps -A | grep sogod and I see that there is 
still a sogod process hanging around.


I have to do a killall -9 sogod to get rid of the stale process and then 
I can start and restart sogod without issue.


--
users@sogo.nu
https://inverse.ca/sogo/lists


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

2012-05-18 Thread Jean Raby

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


 Bonjour,


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
https://www.imereos.fr/SOGo/so/xxx...@x.fr/Mail/view;
Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20100101 Firefox/10.0.4
Iceweasel/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)

--
users@sogo.nu
https://inverse.ca/sogo/lists


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

2012-05-16 Thread Jean-Michel OLTRA

Bonjour,


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
https://www.imereos.fr/SOGo/so/xxx...@x.fr/Mail/view;
Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20100101 Firefox/10.0.4
Iceweasel/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.

-- 
jm

-- 
users@sogo.nu
https://inverse.ca/sogo/lists